<Adapted from my article in CM Crossroads article
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 the chance to do a solo, in which they improvise on the main theme, key off of past experiences and apply their musical knowledge. It's 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 software 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 who are experts in their domain. The teams only interact as they are passing work items from one to the other. When development is done, the teams hand off work 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 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, as it provides a rapid, tight feedback loop. Communication is instantaneous, allowing 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; 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's 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 development, 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
(which 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 acceptance criteria previously mentioned.
In Part 2
of this post, I'll talk about what other roles are integral to every agile development team and explain how keeping the teams small and cross/functional makes it easier to react to change.