If you don't find an answer, please click here to post your question.
Engineering Blog

A Rock Band of Engineers

by Community Manager on ‎02-08-2017 11:00 AM (219 Views)

Written by Marcus Hamrin, published 7/12/16

Software Development

I’ve played music for about 25 years, which is most of my life. While playing some pretty obscure genres, I still consider myself musically agnostic; if it sounds good, it is good, regardless of genre. Period. When I’ve been part of creating music in a band, it has mostly been a very collaborative process. Depending on the people in the band, the process has been wildly different. Some groups of people prefer to have a starting point, a reference to guide them towards a finished song, a rough idea they can work on. Sometimes it ends up completely different than anticipated by the one providing the draft, but everyone has agreed it turned out to the better. Other groups go for complete collaborate improvisation; jamming all night until something sticks, and eventually there is a song that everybody considers complete. Yet another group of people goes for creating an entire set of songs, then rearrange them into new ones.

 

 

Any approach I’ve encountered share a few common traits:

 

  • It is highly collaborative (not cooperative)
  • It has no outspoken process
  • It continuously adapts to new discovery
  • It is iterative and fueled by feedback
  • It is driven by shared Vision

 

Let’s take a deeper look into these.

 

 

Collaborative

 

Each member contributes to the whole, making it into something unexpected and better than any one member could have achieved on their own. You try something new because you get an idea spawned by what someone else did because of the same reason. It’s very different from cooperation, where you simply decide who has what responsibility and then meet back at the rendez-vous. Collaborating in this way requires a tremendous amount of trust, tolerance and communication to work, but the results are truly astonishing (yet considered completely natural in the musical domain).

 

No Process

 

Every member trusts the others to be competent enough to fulfill their commitment to the group. The Shared Vision keeps everyone aligned on the sound, the structure, the “definition of done” and anything else required to go from a clean slate to a full album or a setlist. There is some kind of process going on, but it is not important. Sometimes you do things differently, guided by the Vision, not by the process, and you evaluate the results to see whether it made things better in any way or not. The process exists, changes, mutates and transforms all the time, but very little attention to it is required. The common strive toward the Shared Vision is the driver of communication, interaction and reflection. The “process” may be identified in retrospect, but paying attention to it in real time would be disruptive and wasteful.

 

 

Adapt to Discovery

 

Even though you might have an idea of where you are heading, things will change. Not only because you’re not in control of the universe, but because you want to change it yourself! If you get an opportunity to go in a new direction because you think it’s better than straight ahead, you do it and see what happens. If it's bad, you go back. If it’s great, you’ve just made the song better than it was. If you go the wrong way, you learned something that may apply in another song, another scenario or you learned you will never need to try that thing again because it didn’t match the Vision the way you thought. You’re not just open to discovering new things, you’re required to do it. Otherwise there is no progress – short or long term – and you will eventually become very uninteresting to your audience.

 

 

Iterative and fueled by feedback

 

There are several iterations going on in a band. Every rehearsal there are many iterations for each song. Every time the results are evaluated, tweaked and tried again. Sometimes whole songs, sometimes just a piece that needs special attention since it affects the impression of the whole song. Every time feedback is paramount, and this requires trust, tolerance, patience and many other qualities from the members. Gigs and shows are obviously opportunities for very concrete feedback, and spawns major discussions affecting the songs and the whole band. Albums and videos are obviously in the macro scale of the feedback loop, further providing invaluable information on how to move forward.

 

 

Shared Vision

 

The last point is by far the most important one. The Shared Vision is everything, and interestingly it’s usually kind of vague; “We’re gonna be rockstars!”, “We’re gonna go on World Tour!”, “We’re gonna be on TV!”. It’s a naive, energetic ambition, a bold vision of the future, shared by the entire band, and fueled by success however small, and even more by failure, however big. The Vision is untouchable, it’s almost sacred, yet still rarely outspoken as vision. It’s being upheld by the constant celebration of even the smallest success. The Vision is also something personal, a key driver for every member, slightly different but similar enough to be shared.

 

 

So, what about Software Engineering?

 

While my rock band analogy may differ from the software industry in context, there are apparent agile values and traits at play here. These are autonomy, trust, ownership, and a strong shared vision. Without any one of those things, a band would eventually break up. A software engineering team may not, but their ability and ambition to be a truly great team contributing to the business to their full potential will be very limited.

Enabling agility in a team requires enabling them to be autonomous, trusting them (and them trusting each other), establish team ownership, and co-creating a strong shared vision. These things are not easy to do, it’s a lot easier to just focus on standing up for 15 minutes a day, or what format to use for the retrospect. Or argue whether to estimate in points or days...

 

But when applying the music analogy to an agile software engineering team, this is what I get:

 

If the team has a strong enough vision, they will go for that vision, doing whatever they have to do to get there. The PO will need to share that vision too as part of the team, focusing on providing valuable information on how the terrain looks ahead. The engineers may diverge to follow an idea they believe in, which may trigger new ideas for the PO, shifting his/her focus toward new and uncharted lands. There will need to be constant and vibrant communication on what to do next, based on new discoveries, guided by the Shared Vision and the common goal.

For every success there is instant celebration, for every failure the Vision grows stronger and the bonds grow tighter. Nobody cares about process, there is no time and no need for that. The team know where they are and where they are going at any given time, even though they may never have travelled down that specific path before. They trust each other enough to fail, to be wrong, to improve and to speak their minds at all times. They are proactive and progressive, listening to their clients’ needs, understand them enough to find alternate ways of solving existing problems as well as solving problems they yet didn’t know they had.

 

 

This is an Agile Software Development Team.
A Rock Band of Engineers.


At Ooyala, I’ve been fortunate enough to work with several "Rock Bands". Moving forward, I hope to share more about how we work to increase collaboration, continuously improve and adapt, enable and utilize feedback, and making Ooyala an inspiring environment where people go from good to great.

 

Marcus Hamrin
Agile Evangelist at Ooyala