Agile Melodies Part IV: Follow the Rhythm of Your Teammates


Agile Melodies Part IV: Follow the Rhythm of Your Teammates

A Little Impromptu Music

Jazz musicians who have never played together before are able to seamlessly create because of the genre’s universal set of rules and norms. Take a saxophonist from New York, a pianist from Tokyo, a bassist from Paris, and a drummer from Rio. If you call jazz standard (“Round Midnight, E-flat”), the four of them will play together as though they have rehearsed a thousand times, even though they have never met before and may not even speak the same language.

However, the rules and norms of jazz don’t insinuate that composition isn’t important. On the contrary, the structures and norms that guide jazz musicians allow individual personalities to come out.

Different Teams, Different Results, Same Great Music

See, for example, how three different groups approached the tune “Round Midnight” on several well-known recordings.

  • Miles Davis, from ‘Round About Midnight (1956)
  • Thelonious Monk, Mulligan Meets Monk (1957)
  • Joe Henderson, from Joe Henderson in Japan (1971)

Check out our Spotify playlist for these pieces, and other Jazz pieces to inspire your management hustle.

The Beauty of Variation

Each of these recordings use the same “sheet music” (i.e. lead sheet, see my explanation in Part II), but different teams produce different recordings – much more different, I would argue, than three different orchestras playing Beethoven’s Fifth would ever sound.

Joe Henderson’s recording illustrates this variance particularly well. Joe Henderson is the lead saxophonist playing with an all-Japanese rhythm section he had never met. By listening to each other, the tune spontaneously moves from a ballad feel to a hard swing over several choruses. The musicians may not share a commonly spoken language, but they’re clearly listening to each other musically.

Sacred Rule 3: Work With the Rhythm of Your Agile Team

It is no secret that with globalization and modern communication technologies, agile development teams are forming every day that are more diverse than at any other time in the history of software development. Within these teams, not only is it possible that you do not share a common first language, but you may be located on opposite sides of the globe, in different time zones, physical working environments, and cultural norms. Each member of this global team must constantly be in touch with the other members’ “playing style”, and be able to incorporate it into their own style to it ensure the team works as a harmonious whole.

Adapting to Team Dynamics

The following are examples of work styles you may find within a team that I recommend you listen for and learn how to adapt to.

Communication Medium

Does the team member like face-to-face chats? Will she read and follow a lengthy email, or is it better to give her a phone call? Use the method that your team member is most comfortable with for the best results. Also, if your team is having trouble keeping the facts straight, I highly recommend using written communication like IM or email for key messages so that a record is kept of the conversation.

Frequency of Interactions

In Agile methodologies, we like to say that the team is self-organizing, constantly collaborating, and co-located when possible. If we’re not careful, though, we risk organizing a team of scatterbrained chatterboxes, constantly talking and messaging but not able to get to the most important aspects of the work. The fact is that complex mental tasks like software development require uninterrupted concentration, and studies show that if a team member is distracted by an extra call or email, it may take 15 minutes or more of switching time to become completely engaged in the task again. Observe your team members and their productivity levels, but as a general rule try your best to group your questions together and discuss at appropriate times (right after daily stand-ups works great!)

Reasoning Style

Most people are either inductive or deductive thinkers. Those that reason inductively start by looking at specific data then pivot to broad conclusions, while deductive thinkers will take those conclusions and then apply them to specifics. How well your team member understands you depends on the order in which you present information – if your team member thinks inductively, you might make a list of facts and then end with a conclusion, while if your team member thinks deductively, start with a general statement and then talk about how it applies to different aspects of the situation.


Throughout the Agile Melodies series, we have looked at the largely “agile” nature of jazz music and how key tenets of that musical genre could be applied to project management, and give us insights into what might make for an agile software development team.

First, we looked at how improvisation and flexibility simultaneously demand an agreed upon set of rules and norms so that a team can stay together while undergoing constant change. However, we also emphasized that improvisation doesn’t mean you can do whatever you want.

Then, we talked about the importance of knowing your genre. In order to make the correct decisions in a flexible environment, even the “non-technical” ScrumMaster and Product Owner (or their functional equivalents in your own methodology) need to understand the basics of the technical work.

Finally, in this post, we looked at the importance of understanding the individual characteristics of your team members so you can align their working rhythm with yours and function as a harmonious team.

Practice Makes Perfect

To close it out, though, I will add one last tenet of succeeding as a jazz musician – the importance of practicing. Professional musicians may only play for two to three hours per evening, but in reality behind the scenes, they are practicing four, six, or even eight hours every single day to hone their craft. I’m glad you read this blog series because it demonstrates a willingness to practice your craft Just like a jazz musician would do by reading books on music theory.

However, at the end of the day, as a member of an agile team, you are not just a theoretician but a skilled worker making decisions in an environment where no amount of book knowledge can substitute for hands-on, real-world learning. So the best advice I could ever give someone with an interest in learning an agile methodology is just to get out there, get involved in an agile team, and start practicing – now go make some music!