<Adapted from my article in CM Crossroads titled “Making Beautiful Music Together”>
Have you ever watched a jazz combo? The performance starts with the leader counting off the rhythm, then stepping away. Then the drummer begins to lay down a beat. Even at this stage, the audience can feel a groove hit the room. Soon, the piano joins and adds both melody and harmony to the piece. Energy is flowing from the chords as the team starts to see and feel the direction of the piece. Now it’s time for the other instruments to join in the fun. A typical combo will have a couple of different instruments maybe a sax and a trombone, or some other combination. Whoever starts off will state the melodic theme for the song, although sometimes the whole group does this together. After that, everyone gets a chance to do a solo, in which they improvise on the main theme, key off of past experiences, and apply their musical knowledge. It is not uncommon for jazz musicians to jibe each other, making jokes and comments while they are playing. The energy in the room builds and builds as the musicians play together, sometimes one at a time, sometimes in tandem. When you watch a jazz combo really swinging, it can be hard to tell who his having more fun, the audience or the musicians.
This metaphor works quite well to understand what makes a small team desirable, and how to be successful with such a team. In the agile community, we have asserted over and over again that we need small, cross-functional teams. And yet, what really is cross-functional? Can cross-functional really work? The more traditional view of software creation involves the need for separate, functionally focused teams that are experts at their domain. The teams only interact as they are passing work items from one to the other. When development is done, we hand off to test. Test will find defects and hand them back to development. And the dance continues in this light forever. The jazz model demonstrates that this can, in fact work.
In a jazz combo, each member of the team has a specialty. The members play individually, but often together they create a tapestry of music that becomes much greater than the sum of the individual contributions. A small development team works best this way. We have some set of programmers, testers, documentation specialists, and some representative of the business working together. Team members gain their energy from each other. They try new things and get feedback right away from anyone who wishes to listen and share.
The team members don’t need to just focus on their own areas either. A tester can veryeasily and effectively form a duet with a programmer. They will play off of each other with their ideas. The tester will write a test to express some piece of functionality that the software will have. Then the programmer will answer with the code that will cause the test to pass. So we write another test based on this back and forth interaction. In music this interaction is known as “call and answer,” and it is especially effective with the testing and programming cycle as it provides a rapid, tight feedback loop. Communication is instantaneous, and allows for more freedom of action. More often than not, a programmer will pair with another programmer. This duet is very effective and powerful as well. The programmers can build off of each other’s knowledge, and ideas that might “seem like a good idea at the time” are instantly reviewed by a peer. This type of pairing turns code review from an intermittent, reactive process into a continuous, proactive activity., and should be embraced as often as possible.
Let’s explore some of the roles that are important in a development team. Usually there is some sort of coach or leader. In the Scrum world, you might hear about the ScrumMaster. Each of these names is meant to describe someone who is both a part of, and to some extent outside of, the team itself; in a jazz combo, this is the director’s role. Not every combo has a director, but many do. Sometimes that director is part of the team, only directing long enough to initiate and introduce a number to the audience. In software development, the director represents the team to the stakeholders, and helps plan the meetings, stand-ups, and the like; essentially counting off the beat. If the rhythm seems to be getting lost, the director can help the team identify this fact and help with corrective actions.
A team also needs an individual who has the ability to identify what needs to be developed. In agile, this role belongs to the product owner. Now consider a jazz combo’s basic rhythm section: The drummer lays out the shape of what is to develop; the bass takes this one step further, presenting the progression of chords that identify the order in which the chordsthat make up the actual harmonies and melodies will be played. Lastly, the piano comes in with the rich, fully realized chords. Accordingly, the product owner has to play all three roles of the rhythm section, explicitly: identifying the work to be done or the shape of the upcoming work. Ordering the work in order of priority sets the rhythm. Elaborating the story in terms of acceptance criteria provides the chord structure, and lastly, the constant interaction with the team throughout the development cycle provides the fulfillment of the intention as laid down by the aforementioned acceptance criteria
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 that she specializes in 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 bandsrequire 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 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. 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? How about what 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 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 the depth of description and acceptance tests that 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 its appreciation for another fantastic performance. Now we can chill for a little while, enjoy our success, and look forward to the next gig.