Throughout my teenage years I played the guitar and sang in a few different bands, and I even tried my hand at being a singer/songwriter. Reflecting on those experiences now as a Product Manager, I can see many similarities in the way Agile product and software development teams work compared to a rock band.

Prototype and test first

Recording a demo and creating a prototype are arguably very comparable. It is the rough and ready approach that makes them very similar. Demos are sent to venue owners or booking agents in order to get gigs. If they like what they hear, then a band is likely to get booked for more gigs. If they don’t like it, then it is back to the rehearsal room to create something better.

Product prototypes must also be tested on users to validate assumptions and gain feedback. This insight can then be used to iterate and refine the design.

Music demos, much like prototypes, can be created quickly and cheaply. In the bands I played in this simply involved using an old computer and a microphone placed in the middle of the rehearsal room to record the sound. In the case of prototyping for product development, this might involve drawing user interfaces on paper, and using a tool such as Marvel of InVision to make them clickable.

Collaborate

Everyone knows that band members need to collaborate to be successful, or else you might end up splitting and not speaking to each other just like Oasis or Fleetwood Mac where the band members can’t work together.

Each band member has their own instrument, but by using their collective talent and creativity they create rock music that is bigger and heavier than that of a solo instrument.

Similarly, collaboration between designers, product managers, and developers is key for the success of a software product. Each team member has a part to play in the creation of products, from deciding what the business builds, to testing the user experience, to discussing the technicalities of how it will be built.

By bringing together their individual expertise, an Agile team can make better decisions and ensure they all share the same vision. Without that collaboration, the resulting product might be something that the customer or the company doesn’t even need.

Stay in sync through informal communication

During a performance, a band stays in sync by being aware of what each member is doing while playing a song. It is this informal communication, that allows each member to understand what they are doing collectively. Through this synergy, a band can also adjust to how the crowd is reacting to their music.

For development teams working in Agile it is important to be responsive to change. By having daily standups the team is able to communicate how their work is progressing and whether they have any issues. If any problems do occur, they can be dealt with through informal meetings so the progress of the sprint or project is not held up.

Involve stakeholders (that includes customers and the audience)

Bands play gigs to see how new songs are received by their audience. This is a great chance for them to gauge the reaction to this material and allows them to test out different versions of the tune to see which gets the best feedback. More experienced bands will have a repertoire to choose from and can adjust their set list based on audience sentiment during a gig.

In a related way, there needs to be continual validation and testing of ideas and assumptions during the product development process. By showing incremental changes to stakeholders and customers, product development teams are able to continually gain feedback and insight into the direction the product should take. This also saves time and money in creating products and features that don’t solve user issues, add no value, or never get used.

Have autonomy over what is being created

Most bands are formed autonomously, often out of shared love for similar music. A band chooses its own direction and their own way of creating the music. On top of this, they are the ones who go out and seek gigs, and organise band practices all off their own back. It is this sense of ownership over what they are creating that drives them.

In a similar way, when deciding how to build a feature, a development team should have the autonomy to choose the best skill sets to solve the problem, and when to involve others in technical discussions. Having autonomy in the Agile development process also breeds ownership of the solution. This is important because previously unforeseen problems can often occur in development. When the team hit a technical brick wall, ownership and autonomy provide the drive and know-how to pull together relevant resources to help solve the issue.

Maintain a rhythm of delivery

You often see a pattern in the way rock bands release new music and albums to their fans every so often. They often drip-feed new material, which will help them assess what the overall impact of a full album release will be.

In software development, releasing small changes at a time helps teams to ensure that what they are creating works and continues to provide value for the user. Agile development teams must maintain a consistent rhythm in their delivery of releases to ensure the business provides value continuously for clients and users.

Agile is an iterative process, and involves regular rhythms of work. By measuring the impact of their changes, product development teams can learn more about their users, which will inform the direction the product should take.

Celebrate hard work (party like a rockstar)

Rockstars are renowned for enjoying a party, but although celebrating a release may be slightly more low key for product development teams, it is still important. Acknowledging the team effort through social gatherings can enhance the cohesiveness of the team. This will in turn improve communication and appetite for collaboration. After all, work should also be fun, right?

I would like to credit Matt Walton’s article Be in a Band, Not an Orchestra: How to grow and Agile Product Team as the inspiration for this piece of writing. 

http://www.mindtheproduct.com/2017/04/band-not-orchestra-grow-agile-product-team/