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.

What in the world does this have to do with software? Actually, quite a bit. Let's look at how small teams work and interact, from within this metaphor. 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.

In a jazz combo, or any other small musical group, each member of the team has a specialty. As 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 very easily 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. More often than not, a programmer will pair with another programmer. This duet is very effective and powerful as well, 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 chords that 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.

And, of course, we also have the rest of the musicians who are like the testers and programmers who have some specialization. In most bands, there are not only specialists as far as the instrument they play, but how they play it. In the Duke Ellington band, 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 UI 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 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 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.

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.