By Paul Goddard
I am always on the look out for new and interesting metaphors for the use and benefits of Scrum specifically and an agile approach to delivery in general. As a keen and almost-able musician myself, the title of Mike Cohn’s recent article, “Leader of the Band,” got me thinking more about the parallels between agile and music: both in its composition and its performance.
Creation
I do not profess to be skilled in composition or arrangement of music. I can, however, imagine how a composer visualizes a piece of music before it has been completed. Before he has written a single note, a music composer must have an idea of the style, structure and mood of the piece he is about to create. He starts with that vision. So, too, must a Scrum project begin with a theme or picture of what ultimately will be delivered.
In music, this vision comes from many different sources. Compositions can be written to mark a specific event, reflect a particular emotion or experience, or to convey a particular mood in a play or movie. Historically, many classical compositions have been written to mark specific events. For example, Piotr Ilyitch Tchaikovsky’s 1812 Overture (1880) was composed to commemorate the unsuccessful French invasion of Russia in 1812, a major turning point in the Napoleonic Wars. Tchaikovsky’s clearly had the intention of building a classical masterpiece that portrayed the increasing magnitude and frenzy involved in the final stages of battle. Other pieces of classical music have been written to encapsulate a composer’s own thoughts, experiences or emotional state. The Symphony No. 9, From the New World, popularly known as the New World Symphony, was composed by Antonín Dvořák in 1893 during his visit to the United States from 1892 to 1895. In an article published in the New York Herald (December 15th, 1893) Dvořák explained how Native American music had been an influence on his vision for this symphony:
"I have not actually used any of the [Native American] melodies. I have simply written original themes embodying the peculiarities of the Indian music, and, using these themes as subjects, have developed them with all the resources of modern rhythms, counterpoint, and orchestral colour."
- Antonín Dvořák
In some cases, composers are asked to write a movie soundtrack that encapsulates the themes of the motion picture. Good examples are the iconic works of John Williams (Star Wars, Jaws, Superman) and the more sedate film scores of James Horner (Titanic, Braveheart, Apollo 13). In these cases, the film director has a great deal of input as to which parts of the soundtrack are added to the film structure to improve the final product. He must work closely with the composer to ensure that his own vision is realized, in most cases working with only the movie’s script, rather than the visual elements of the motion picture. In all of these instances, a clear project vision gives structure to what the composer will create. The project has a purpose: deliver something that will make people feel, remember or understand a particular mood, experience or event.
In software development, the vision usually comes to the team from someone like a film director: a product owner. The product owner gives a clear picture of his goals and writes, or helps to write, stories that describe the things he’d like to have in the final product. Working collaboratively with the team throughout the project, he guides the team toward the creation of a product that fits his, or the organization’s, needs.
Playback
I also see the emergence and development of musical piece as a distinctly agile practice. Picture a composer sitting at a piano, armed only with blank manuscript and a vision. The ideas in the composer’s head are translated into sound using the piano. The sound provides instant feedback as to which melodies, harmonies and chords combine effectively; in other words, the composer is testing and integrating while the piece develops. In most cases, a musical creation starts small: a simple melody or sequence or chords from which the composer can choose to overlay harmonies and counter melodies. Through simple playback and constant rehearsal the composer can quickly identify problems or imperfections in the product. Working with this integrated product allows the composer to add depth to the music against a solid, tested foundation.
These simple common sense practices translate directly to the quality engineering practices that underpin a Scrum development project. A test-first approach always minimizes the risk that our software “music” will not integrate at the end of a sprint.
Reducing Risk
“To achieve great things, two things are needed; a plan, and not quite enough time.”
– Leonard Bernstein
Scrum allows us to reduce the risk of undelivered projects through iterative delivery and striving for a potentially shippable product increment at the end of every sprint. I found many examples from music that characterize a similar low-risk approach to composing. This is best seen from composers who repeat a simple melody throughout the piece, then add substance to the music by changing the mix of instruments or by increasing the volume or tempo. These changes move the one simple melody towards a dramatic crescendo.
This is most noticeable in pieces such as Pachelbel’s Canon in D Major (1680), Dukas’ Sorcerer’s Apprentice (1897) and Grieg’s In the Hall of the Mountain King (1876). It is also evident in more modern music, where artists build on a simple theme with instruments and vocals, while the original melody still remains identifiable. This is a relatively safe way of adding depth to music, one instrument or rhythm at a time. This can be recognised in the Rolling Stones’ "Sympathy for the Devil" (1968) and more recently in the dance anthem "Sunchyme" by Dario G (1997). When listening to these pieces, clear sections are audible where the composer has modified the melody only slightly while still adding value. Each section is its own marketable product, which could be released if necessary even if the entire piece has not been written. The risk in not having a completed composition has been greatly reduced.
In the same way, adding functionality to a software project in small chunks adds to its depth and usability, but at the end of any iteration, you are still left with a potentially shippable product, greatly reducing the risk that your software project will fail to deliver.
Continuous Integration
Modern music recording in studios allows musicians to record iteratively and constantly check the quality of the outcome. Components of the song or music are usually recorded in isolation, but need to be integrated effectively to form a quality final product. Digital recording now allows musicians to playback drums, bass or treble to allow vocals to be added and tested against each other. This kind of dedication to testing and feedback continuously throughout production ensures the product achieves the artist’s goals. The same can be said of a Scrum project.
Self-management
As a former member of a brass band, I can certainly relate to Mike Cohn’s observations on the close similarity between a ScrumMaster and a band/orchestral conductor. The conductor (or musical director) maximizes the performance by ensuring the musicians carry out the composer’s vision when playing the piece. Some conductors can become quite animated as a means of injecting passion into their ensemble. However, a conductor does not have the capacity, or in most cases the technical proficiency, to take the place of a team member.
A good conductor cannot make a poor band play great music. But a good conductor can point out and help bands tackle some of their biggest problems. He can work with the band to improve those aspects that can be improved and can find ways to maximize that which they do well. In the same way, Scrum teams benefit from a ScrumMaster who can keep them moving toward a project vision, removing impediments and emphasizing team strengths.
Ultimately, though, it is the band that makes the music and the software development team that creates the product. When I hear a band play great music, I am not applauding the conductor’s baton but the combined unity of the musicians making such a pleasant sound. In the same vein, when a band under performs, the audience regard it as a poor performance regardless of the conductor’s efforts to maximize the quality the band provides. Similarly, when a team delivers a great product (or a sub-par one), people notice the product, not the ScrumMaster.
“Life is a lot like jazz... its best when you improvise.”
– George Gerschwin
Although the conductor keeps the team on the straight and narrow, I have seen first hand how a band of musicians can continue to work effectively and still deliver in the absence of a conductor. If a conductor ceases to conduct, the music will continue, but there is more responsibility for musicians to listen to the person sitting next to them. Listening is one of the keys to self-management.
Similarly, for Scrum teams developing software, listening is a fundamental part of teamwork. During the daily scrum, we should spend about one minute talking and up to fourteen minutes listening. Teams who don’t listen to each other are going to struggle to work effectively as one team.
Another important factor for self-management is team size. In large bands or orchestras, instruments generally split into sections which have to function as a section to add value to the overall sound of the musical arrangement. In most cases, section leaders help lead these smaller groups if only to ensure the sections begin and end their parts in a smooth and together fashion. This is particularly necessary in a larger orchestra when the conductor may be addressing a different section of the ensemble. In these large musical arrangements, sections also need to be more aware of other sections sounds in order to maintain the quality of the overall piece. My former musical director would often shout, “If you can’t hear the trombones, you’re playing too loud”.
The same principles should apply in large scale scrum project, especially where multiple Scrum teams are involved. Experience working with Scrum teams tells us that teams between five and nine in size are most effective. Each small team needs to be fully aware of what the other teams are contributing to minimize the risk of delivering a poor quality product, or possibly no product at all. Teams who are functioning well, but playing too loudly, could even be sub-optimizing the system as a whole.
In summary
The Scrum framework helps teams to achieve excellence in delivering products by suggesting very few rules backed by simple and common sense principles. These common sense principles apply to many things we see or hear in our everyday lives. Music is an art we have encountered and enjoyed all our lives, yet the time, effort and dedication to composing, writing, performing and recording is something we probably have little experience in or have paid little attention to. The principles and practices involved in making music are not that different from those we use to deliver Scrum projects. Clear product visioning helps define and drive a delivery while regular feedback and continuous testing and integration reduce the risk of un-deployable products. When I played the cornet in a brass band, I felt part of a team. The team struggled if certain players failed to turn up for practice. The team would have to self-organize to fill the gap. Effective teams are born of constant listening and reflection. This becomes even more important in larger teams, or teams-of-teams. Similar to a large orchestra playing a symphony, each section of a large software project will need to understand the role of other sections as well as their own to ensure the composer’s (or, in this case, the product owner’s) vision is achieved.
