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.
Practice
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.
Tools
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. Snacks.
Before you write a line of code, what else do you need? A good source code repository. A unit test scheme that everyone can use. Dev environments. Test environments. Test automation tools. Communication tools and management tools like wikis, email, and messaging systems.
Now you can write some good code! You'll need a continuous integration system that lets everyone know when the build is broken. You'll need a way to know when the UI-level automation fails. You'll need to be able to see the rest of your team's status so no one falls behind.
While it is certainly possible to perform jazz standards on a $25 ukulele, no one is going to pay good money to hear the result. Having excellent tools in the hands of expert users makes the work go much more smoothly and efficiently.
Team
At the concert, did you hear any bad notes? Did you notice any mistakes? Probably not. They were there, you just didn't notice them. The band and the crew are so good at what they do that they adjust instantly to make the mistake a part of the performance or to help out by changing how they usually perform.
This is a hard concept for a lot of teams starting agile. It really is the whole team working together that puts the whole project across. If stories are stalled, devs and testers help write them. If testing falls behind, devs and product owners test. If development is lagging, testers and designers jump in and pair program.
Consistency
The tour is over now, and your manager calls you to tell you that you're going into the studio to make an album. You'll need some more experts, but it's just another aspect of being a performer.
Once you have had the experience of working on a high-performing agile team, you can bring that experience to bear in different situations. You might work with a different programming language or a different test automation tool or in a different industry, but you keep the ability to perform.
A concert performance is a shared experience that ends, but a recording is an artifact of such performance. As a performer on an agile team, your running tested features are the evidence of your ability to perform consistently well.
Now, go put on a show.
