Effective teams: Free Jazz

This is the first post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal.

In free jazz, improvisation is an important part. But the musicians don’t just play whatever they like. If the Saxophonist takes over from the Trumpeter, he (normally) takes over a little part of the melody and then starts to modify it.

We should build software the same way in our team. We should build upon what is already there.

Rework

Unfortunately, we tend to do a lot of rework:

• One developer throws away the code his peer programmed yesterday because he doesn’t like the different coding style.
• The team members have different goals and therefore adapt the code to their goal and not a common team goal.
• The team suffers from the “not-invented-here” syndrome and works on things that are already solved by third-party commercial or open source libraries.

Free Jazz

Therefore, we need more Free Jazz in our teams.

We need a mutual goal and understanding. Everybody in the team needs to know and act according to the team (or project, product) goal. We need to have a team understanding how we build code. This ranges from coding styles (hey, just use StyleCop for .Net or Checkstyle for Java) over design style to architectural decisions.

The team needs to find its way to build software by always moving forward. Lots of teams are caught in a cycle of moving one step forward and one step back again. The team needs to learn to add functionality to the software based upon existing solutions. Either internal solutions found in the code you already coded, or external solutions found in third-party commercial or open source libraries.

How to learn Free Jazz

Establishing a free jazz spirit in your team needs practice.

Your team should practice pair programming. See also Why Pair Programming Works,  Different Flavours of Pair Programming, Pair Programming Stereotypes.

The two pair programming developers take different roles. The driver is the one typing and taking care of all the detail stuff (semicolons, variable names, …), whereas the navigator is responsible to make sure, the pair is on the right track, solving the right problem. When developing software with Test Driven Development, the navigator thinks about the next test to write, too.

When pair programming, the two developers learn to build a solution together. To build upon each others ideas and to combine them into a single solution.

In Coding Dojos, the whole development team sits together in a meeting room, two of the team practice pair programming on a laptop connected to a projector. They solve a little training exercise (see Kata Catalogue) together. Every 10 minutes, the driver leaves the coding pair, the navigator takes over the role of the driver and a developer from the audience gets into the navigator’s seat. When all tests are green (yes, you do this with Test Driven Development of course), the audience can criticize the current solution. While a test is red (yes, there should be only one red test at a time), the audience has to remain silent. This is a great exercise for a team to learn to build a solution together, always moving forward (with the exception in the rare situation when they maneuvered themselves into a blind alley) and to build upon what is already there.