When the features are good, we can watch our audience in real time use our software for real work. And if the feature is no good, we can find that out immediately and tune our approach for the next performance.
We can write about a manufacturing process or an engineering process quite precisely, and we can use those descriptions to help us build factories and bridges that do exactly what they are supposed to do. And yet for all the writing on agile software development, we still hear more stories of mini-waterfalls and technical debt and perversions of the Agile Manifesto than we hear stories about successful agile software efforts. This suggests strongly that agile software development, whatever it is, is not very similar to manufacturing or engineering.
The Standing Ovation
In 1992 I played bass for an obscure singer/songwriter/guitar player named Gerard McHugh, and that summer for a few weeks we had a 20-minute set opening for the Indigo Girls/Matthew Sweet tour through the Midwest leg of the tour, about 14 shows playing for audiences of 8,000-12,000 at each show. For about half of those shows we got standing ovations. It was an amazing experience, both good and bad. The shows were wonderful. Being three unsupported guys in a small Toyota van with two guitars, an upright acoustic bass, and a drum kit for three weeks was hard.
Which suggests an interesting question: how does one get a spontaneous standing ovation from 10,000 people who don’t know who you are? I could write and write and write for years and never explain how we did it. There is no universal process to be described. It takes talent and discipline and dedication and really, really good songs to make that happen. And every case is different. It is not manufacturing, it is not engineering. And yet it happens all the time.
Agile is Art
In various ways and in various forums I have been saying for some time now that agile software development is a species of the performing arts. Agile software development has all the hallmarks of an artistic performance like those of music, theater, or dance. It requires practice; it requires rehearsal; it requires a team to be constantly negotiating their own personal and professional relationships among themselves. And at the end of every iteration, an agile team releases a set of well-executed features to a group of users who come together to appreciate those features, just exactly the way a performance happens at a specific time and place for an audience.
I was not the first to notice this. Rob Austin and Lee Devin, professors of theater and computer science at Harvard, wrote a book in 2003 called Artful Making that demonstrates the close parallels between theater performance and agile software development. But Artful Making is a book for managers trying to understand what agile software development looks like from the outside. In my review of the book on my blog, I said, “This is a book for executives who wander by the agile team room and wonder why it’s so noisy and the floor is covered with index cards and there is a box of Lucky Charms on the table and the scrum master is wearing a Viking hat. It does not tell you how to do artful making, it only tells you what artful making looks like.”
Tools for the Writer
Describing a high-functioning agile team from the inside is hard work. It is exactly the same problem as describing how to get a standing ovation from 10,000 strangers, because it is the same sort of work done in the same sort of way.
One approach is to borrow the language of other disciplines, particularly from the liberal arts. Literary criticism, psychology, history, philosophy, economics all have rich traditions and sophisticated intellectual frameworks to describe the interactions among human beings in complex circumstances. I see the world as a musician and as a performer, so that language comes naturally to me, and applying those intellectual frameworks is productive for me. For another example, explore the Wikipedia page for “audience theory.” Dick Gabriel and Brian Marick have both done work along these lines, but I think we as writers have barely begun to explore what is possible.
Another approach is to use biography and autobiography. Nothing beats an experience report. Those who have worked on high-performing agile teams have a wealth of stories and anecdotes, but far too few are ever written down. Given a large enough pool of accounts of individual experience, both first-person and third-person, those interested may be able to tease out the common threads that make such teams so successful. As the agile movement gains more influence, this becomes more possible. My own feeling is that there is too much noise here in the agile community in late 2010 to isolate the real signal. This article is part of that work.
Another approach that I am finding appealing is to put ourselves in the position of the users of our software, and then to describe what it is like to be a user of software developed by a high-functioning agile team. A few examples exist today: in particular, I am thinking of the idea of “opinionated software” originated by those at 37signals, and of the “software craftsmanship” movement, who have an enormous amount of sympathy for the users of software. Today both of these approaches are overly simple, but I think they also both have a future. I think both movements require more sophistication and discipline, such as is shown by the “audience theory” example I mentioned above, but both have promise. In another article I called this “The Audience Experience,” as distinguished from User Experience (UX), which typically deals with the behavior of individuals. We in software lack an understanding of how we ourselves and our work influence the behavior of large groups of users.
Abstraction, not Analogy
I object to analogy when writing about the work of software development. Agile software development is not like working on a railroad, or like working in a fast food store, or like performing music. If agile software development is merely like an artistic performance, then the intellectual tools available to analyze artistic performance are not available. I assert that agile software development is artistic performance, and I back that assertion with my own knowledge and experience, gained from years in academia, years as a professional musician, and years working on agile teams. This identity makes it possible to bring to bear an enormous number of sophisticated theoretical tools. We must be able to describe our work directly, without analogy.
Much of the agile experiential training I have experienced seems to be constructed far removed from the actual work. Having finished the training, there is nothing useful to apply to the actual work. There is a place for experiential training in agile software development, but it has to be based in abstraction, not analogy. In May 2009 I organized the first Writing About Testing conference in Durango, CO, where the problem of analogy was a constant theme. There I had a number of conversations with Elisabeth Hendrickson, who has an exercise she calls “Wordcount.” It is an experiential training program with no programming or computers involved, but instead of being like working on an agile team, it is working on an agile team. Elisabeth has spent thousands of hours working on high-performing agile software teams, and she distilled that experience into an exercise that exposes the best of such work. This is not analogy, this is abstraction. Elisabeth’s example is worth emulating.
Feedback, Feedback, Feedback
There is a well-known acoustic music club in Nashville called The Bluebird Cafe. For decades now there has been a house rule at The Bluebird: no talking during the performance. I often used to play a well-known club in Atlanta called Eddie’s Attic that once considered instituting a similar rule. I was dead against it. As a professional musician, it is my job to command the stage, and to make the audience pay attention to the performance by sheer talent alone. If the audience is chattering during my performance, then I know that my performance is not good enough. The no-talking rule eliminates a critical feedback channel for the performers.
Today it is a fairly trivial matter to analyze server logs in real time. At the end of every iteration we can release new features and in those logs we can watch our audience view pages and click links and invoke those features. I have done this work, and I consider this a form of applause. When the features are good, we can watch our audience in real time use our software for real work. And if the feature is no good, we can find that out immediately and tune our approach for the next performance.
Agile is Ongoing Interaction
Specifying a software system precisely is fundamentally impossible, because the activity of software development, and the interaction of users with the software, is by its nature not subject to rigorous specification.
Instead, what we have is an ongoing interaction. The relationship of agile software development, the software itself, and the users of that software is exactly the same relationship as that of performers, the performance, and the audience.
We agile software people put on a show; the audience either buys tickets every two weeks or else they leave. Everything else is irrelevant. The trick is to put on a good show. The trick for us as writers about software is to show others the way to get that standing ovation.
Chris McMahon is a software tester and former professional bass player. His background in software testing is both deep and wide, having tested systems from mainframes to web apps, from the deepest telecom layers and life-critical software to the frothiest eye candy. Chris has been part of the greater public software testing community since about 2004, both writing about the industry and contributing to open source projects like Watir, Selenium, and FreeBSD. His recent work has been to start the process of prying software development from the cold, dead hands of manufacturing and engineering into the warm light of artistic performance. A dedicated agile telecommuter on distributed teams, Chris lives deep in the remote Four Corners area of the U.S. Luckily, he has email: email@example.com.