Sometimes, it's helpful to explore how people in other occupations create their products in order for us to better our own. In addition to being an experienced software tester, Chris McMahon has spent time on the road and in the studio as a professional musician. In this article, Chris takes a look at some of the things that make for a successful live concert and compares them to what it takes for an agile team to build software successfully.
Suppose for a moment that you are not working on a software development team, but instead you are a famous musician. Your manager has informed you that you and your band are starting a long, worldwide tour. On this tour, you and the band will get up on stage under the lights and perform songs for thousands of people who paid good money for tickets to your performance.
This tour is unusual. You go on stage every two weeks.
The best agile teams deliver running, tested features every iteration. Just like performing for an audience, your users should get a valuable new experience every time they use the new features. Your team should be getting good feedback from your users, too-maybe not a standing ovation, but successful agile teams have happy users.
The following are some things to consider as you prepare to get on that stage for your agile performance.
When you go to a concert, one thing you might notice is that musicians are all really good. But think about the last concert you went to. How did you like the lighting? What about the sound system? Did you notice the guy handing new instruments to the guitarist?
Everyone involved in a major stage production is an expert. From the guitar tech to the people running sound and lights, it takes a big team of experts to put on a great show.
Agile teams are like that, too. If you are a developer, you have to be good enough to pair program with other people on your team without slowing them down. This means you must not only be a good programmer but also master the editor and be a fast typist. As a tester, you not only have to be good at finding bugs, you also have to be able to write concise, exact bug reports to prevent wasting other people's time. If you are making stories, those stories have to be written so that they can be coded and tested without too much ambiguity.
For every role on the team, there is a set of skills to be mastered. But, while you master the skills appropriate to your own role, you should have some knowledge of the skills of the other roles as well. The drummer certainly knows a great saxophone player when he hears one. The bass player can certainly suggest chords for the guitarist to play.
For example, as a tester or a product owner, it's probably a good idea to be able to tell good code from bad code. Your job is directly affected by the quality of the code, so it behooves you to understand what makes code good or bad.
As a developer, it is very helpful to understand some principles of project management and of good design. The difference between good management and design and bad management and design is the difference between efficient iterations and a death march.
Again, think about the last concert you went to. Did you notice that everyone-performers and crew alike-was listening intently to everything that was going on, making small adjustments minute to minute or even second to second? Everyone on the stage was an expert.
No serious musician plays a poor instrument. Successful agile teams pay attention and get the appropriate tools for the job.
Before we even take a look at software tools and management tools, consider your surroundings. Have comfortable chairs. Have screens and keyboards for pair programming. Have computers powerful enough that you don't have to fuss with them to get them to work. Whiteboards and index cards.