• Agile & Scrum Basics

Scrum rocks! Scrum by the ins and outs of a rock band

Early 90s. I, I’m still alive pretty much pops through the speakers of every attic room. Including mine. Maybe Pearl Jam is even one of the reasons I started making music at 15. At the time, I had (like lead singer Eddie Vedder, of course) long hair and a pointed electric guitar. Those wild hairs have since disappeared and the electric guitar gave way to a fine acoustic one. But what has remained is the love of playing live music. On that note: I’m still alive. What does that have to do with Scrum?

To understand Scrum, people often refer to the Scrum Guide. Logical. Yet the workings of Scrum still remain too abstract for some readers. That does not really sound like music to your ears. Therefore, I have made Scrum tangible, audible and alive through the functioning of my tape. Discover Scrum in 5 minutes on the basis of an acoustic rock band.

Scrum Roles

Turning the venue upside down is what our four-piece band does it all for! And it will not surprise you that there is more to it than getting on stage and producing decibels. Bob plays drums, sings, arranges the logistics and does the sound. Alex plays bass, sings and is the musical conscience of the band. Frank plays guitar, adds new songs to the set and handles finances. I take care of vocals, guitar, bookings and marketing. So the band has all the skills to take care of a performance from A to Z. In Scrum, this is called the Development Team. We have no external dependencies with sound companies, guest singers or other disciplines. That keeps us wonderfully lean and super agile.

Frank, in this case, is the Product Owner in the band. He guards the concept and always suggests musical innovation. This is how we continue to stand out from other bands. The role of Scrum Master is here for myself. I provide oil between the wheels, among other things by collecting and sharing feedback. This is how we continue to improve (each other) as a scrum team. The Stakeholders are the bookers, organizers and, of course, the visitors. After all, those swinging visitors and singing along are our end users.

From concept to workable lists

What preceded our band’s very first opening chord? We put our heads together and came up with a concept. In Scrum, that concept is the Product Vision. The key for this Product Vision was conceived by the Product Owner and then worked out with the entire scrum team. This resulted in the following musical promise: our band brings hits of today in a solid and energetic acoustic jacket. The effect on visitors to our gigs should be: ” Hey how cool, I know the songs from the radio. Surprising choices, recent and different from other bands that play a lot of hits from the 70s.”

Next, we also determine what a good performance must meet. Our quality list. This lists things like: the new songs on the set list are recent hits, all the instruments are in blood form, we dress cool, and the gig invoice is in the bag. In Scrum, we call this list the Definition of Done.

The sprint

Over the years, we have collected more than 100 songs to play. Call it our ever-growing Product Backlog. Those 100-plus songs are about 70 too many to play in one evening (our setlists consist of about 30 songs). So we need to prioritize. This is done using a Sprintgoal. What do we want to achieve together? Do we make stakeholders happy with a listening performance or do we score points if we get things dancing? Based on the Sprint Goal, we put together the Sprint Backlog : a set list that we expect to do its job. Still, anything can happen during the course of the performance. Frank may decide to put in a long solo, we may skip a song because it doesn’t add value in the moment, or strings may break so we have to adjust the whole thing.

The events

Our process also starts with sprint planning. For this we prefer to sit together, but in practice we often choose to set this up remotely. Where someone makes a proposal for the set list and we shoot it together briefly.

The daily scrum is at the gig itself. As soon as we meet, we update each other. How are we in the race? Are all signs on green or do we have to help each other to make the gig a success? Is everything working in the short sound check? We repeat this at intermission. Should we have one.

A small review follows at the end of each song. The applause and comments from the audience are the most direct form of feedback. At the end of the set there is a more extensive sprint review. We go into the hall and ask the visitors (end users) and the customers (the ones who booked us) how they liked the performance. Then we also do a short sprint retrospective: How do we play together? What works and what doesn’t? Do we have a good sound? Are we hearing each other well? Are we listening to each other? Points of improvement we take directly to set two. If everything turns out wonderfully, of course we pop out a few encores after the total sprint of about 2 hours. Celebrate your success!

In conclusion

Of course, this is a simplified representation of Scrum, but our way of working incorporates a lot of Agile and Scrum. We do that as a band, by the way, not because I’m a fan of Agile and Scrum. No, we do it because Scrum is actually very logical and it feels very natural to organize yourself that way. It keeps you alive as a person, a band and an organization. LIVE.

Want to read more about a the ins and outs of an Agile team using a rock band as an example? Discover a super cool article about an agile team in the form of a rock band. Oh, wait… and here’s part 2 right away.