In the first post of this series, we discussed how a “traditional” symphony orchestra fell apart when asked to deviate from the original score, while an “agile” jazz combo followed right along as a saxophonist continued on his improvised solo for extra bars.
I gravitated away from grade school band class and towards jazz combos because I loved the freedom of being able to play “whatever you want.” This is probably why I was running “agile” software products before I knew what the word “agile” meant. I also realized that unless you are going for something akin to this musical mess below, successfully playing “whatever you want” does have a few requirements.
Let’s start with the story of Miles Davis’s Kind of Blue, recorded in 1959 and considered by many to be the greatest jazz album of all time. The most fascinating aspect of the album (in relation to this article) is how it came about. In short, Miles Davis called seven musicians (who had all played together in different combinations) into the studio for a one-day session without providing any indication of what they were going to record.
Davis wrote the songs hours before the session and shared them with the group just minutes before the mics went on. He only provided a basic melody and an underlying set of chord changes. This is the “plan” for Blue in Green (written down only much later), the third song on the album:
After taking a few minutes to memorize the melody and changes, the band members picked up their instruments and turned a few notes and 12 measures of chord changes into this.
Four of the five songs on Kind of Blue are first-time recordings from the musicians (including Davis). And yet, the album consistently shows up at the tops of lists like this, this, this, or this. How is this possible?
“Responding to change over following a plan” does not mean responding in any way to any change. The software industry is full of competing Agile development methodologies, but I have yet to come across one that does not follow this basic rule.
Agile Scrum requires the team to define a set length of the Sprint – say, two to eight weeks depending on the project. At the end of the Sprint, the Sprint Review and Sprint Retrospective meetings help the team (and the customer) identify changes to the developed product and the work product, which can then be incorporated into changes during the next Sprint Planning meeting (the beginning of the subsequent Sprint). During the Sprint, however, the team does NOT change either the requirements or the approach to work. If in our musical example above, one of the musicians tried to end a solo in the middle of the 12-measure progression, the whole performance would have derailed.
Scrum also defines individual roles: The Product Owner is the voice of the customer, and is given the authority to define and prioritize the requirements so that the team stays oriented towards the vision and business needs. The Scrum Master meanwhile guides the team towards following Scrum techniques.
In a jazz combo, the Product Owner is the bassist responsible for playing the “root” of the chord (e.g. the “G” in a “G minor”) while the Scrum Master is the drummer who sets the tempo. If either of these two musicians strays from their responsibilities for too long, the group is well on its way to falling apart.
Even for the best team setup, communication is critical throughout the entire collaborative exercise. Communication is so important that in our next post, I’ll go deeper into how communication is required for a successful performance, whether you’re working with a trumpet or a copy of Visual Studio.
Principal Systems Engineer
Never miss a thing by signing up for our newsletter. We periodically send out important news, blogs, and other announcements. Don’t worry, we promise not to spam you.