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: http://bit.ly/yOBqBn