In Part 1 of this post I explained why it’s important for agile development teams to have distinct specialties – very similar to the way a jazz combo works together to create beautiful music. In this post I’ll continue my parallel and explain the value of maintaining these specialized roles within a small, cross-functional framework:

Continued from Part 1

And, of course, we also have the rest of the musicians who are like the testers and programmers in that they all have some specialization, perhaps the instrument they play, or the particular way in which they play.  For instance, in the Duke Ellington Orchestra, not only was Cat Anderson known for being a great trumpet player, but he was also known as a high-note specialist. If applied to the agile software development environment, not only are there specializations like programmer and tester, but there are also some folks who are best at User Interface, or at database work. There was never a rule that only Cat Anderson could play the high notes, or that he could only play certain notes. And there should never be a rule that only your “UI guy” can work in the UI. That would lead to a very thin team.  There would be no ability to build a depth of knowledge throughout the team.  Should a particular team member be unavailable, and the skill in which she specializes is required, the team is now hostage to her schedule.

There are many reasons why small groups are desirable. Members of a small combo are best able to work together and play off of each other’s strengths and weaknesses. They can react to changes that might come from the stage dynamics. Whereas many large bands require a hefty amount of coordination and very little room for improvisation, the small combo thrives on improvisation. Everyone adds what fits best, and the feedback from the audience is immediate. The energy builds – not just from each contribution, but also from the cumulative effect. The band doesn’t stop and argue when someone makes a change during a jam session. Band members pick up the new tempo and use this change to make the music better than ever before; the same thing happens in agile software. The team is able to communicate and work together. The different players are not going through some intermediary, but directly to each other. The energy, the pace and the quality of the product all come out through this tight, frequent interaction.

I’d like to take the next few weeks or even months to explore further how we can apply the lessons of our jazz brethren to the world of software development.  We can talk about ideas like how to be successful with duets (pair programming), or perhaps how to conduct a jam session.  Hopefully, this will spark some ideas that can build a strong understanding of how to work in our agile teams.  What other comparisons can we make?  What do we do when a small combo begins to grow into a large orchestra?  What might that mean to us?  The possibilities are endless.

So now picture this: The agile development team comes together for a planning meeting. The director establishes the tempo by identifying, with the help of the team, the velocity for the upcoming work. The product owner then lays down a groove, describing the melody and harmony of the iteration.  She does this by providing a depth of description and acceptance tests, which show not just what we will be doing, but how each story interacts with the others. Now the rest of the team picks up the melody as shown by how the programmers and testers pair up and work on stories together. The team’s energy builds as the code is tossed back and forth in short phrases. Each member employs his strengths, but helps to contribute to the overall outcome wherever he can. At the end of the iteration, the audience expresses their appreciation for another fantastic performance.  Now we can chill for a little while, enjoy our success and look forward to the next gig.

Do you enjoy Steve’s posts? Check out more on his personal blog:

Join the Discussion

    • Daniel Tanner

      The link to Part 1 does not resolve. Should be:

      Great writeup and you’d be amazed at how timely this is. Thanks.

    • Steve Ropa

      Hi Daniel,

      I’m so sorry I didn’t see this post earlier. Thanks for the compliment, and I’m dying to know why it is so timely.

    • Brian O. Ackles

      Hey Steve,

      Enjoyed the blog. I teach vocal music in Central New York. I learned about Agile Development from my son in law and have adapted the philosophy for use in the vocal music classroom. The results have been outstanding. Thanks for the great music analogies – keep them coming!


      • Steve Ropa

        Thanks Brian! I would love to hear more about how you adapted that to the classroom. Unfortunately, the music analogy didn’t resonate very well for many, so I had not dug much deeper. Maybe I’ll add to it in the coming year. Is there anything that strikes you?

    • Brian

      Hi Steve,

      I have adapted the Agile Framework for learning a new song for the choir. We follow the basic structure – I put it into three sections: planning (creating backloglist, etc), Performing (Sprints on specific sections of a song), and Testing (assessment of skills acquired). We make adjustments when needed, and off we go on another sprint. As far as responses to your music analogy – maybe there are few computer programers who are musicians?

      • Steve Ropa

        Hi Brian, thats awesome! I’m looking forward to hearing more about how this progresses. The world of Agile is moving beyond Software Development into many arenas, and education is a great direction.

        Believe it or not, there is a disproportionately large number of musicians in the software development community. Lets keep that conversation going!

    − 1 = 1