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.