Goodbye Waterfall, Hello Agile
We often consider technology an imposition on both our craft and our business: social media putting pressure on everything from marketing to performance, for example, or IT budgets draining resources from “more important” work. But the etymological root of technology is techne: the Greek word for art. To paraphrase cartoonist Walt Kelly, we have met the enemy, and it is us. Every month, this column will investigate the ways in which technology can inspire us, transform us, and help us chart a new course in the 21st century. Thanks for—to use a radio metaphor—tuning in.
How often do you stop to think about the metaphors that govern the way we make theater and run theater institutions? The “hidden patterns” we follow, often subconsciously, as we structure our work? There are two such hidden patterns that I think we really need to pay attention to. I’m going to call them waterfall and agile, for reasons that may be obvious to anyone with software development experience… because that’s the milieu they come from.
In waterfall software development, a project moves through a sequential series of phases: roughly speaking, definition, design, development, testing, and maintenance. The basic idea is that the thing being built, whatever it is, “pours over a waterfall” from phase to phase. When the product has been defined, design can begin; when the designs are approved, programmers begin development: you get the drift. The whole effort moves in one irreversible direction. You never turn back.
Waterfall is a clear tried-and-true methodology, with its origins in the American manufacturing industry…but it comes with significant limitations. The big one: linearity. If you happen to have an insight about how a piece of software ought to have been designed, for example, when you get to the testing phase, you can’t make changes—not without running through most of the process again. The product you get at the end of a waterfall process, therefore, is almost always exactly what you set out to create at the beginning…but by the time you’re done making it, you often want something else instead.
This is, I think, how we make a great deal of our theater. A playwright writes a play, then she hands it off to other artists to design and build; the plays gets tested in front of preview audiences, then launched to the world on opening night, then maintained until the run is over. I’m (obviously) simplifying, but the waterfall parallel is still (I think) sound.
This is also, in many ways, how we run our theatrical institutions. We conceive of an entire season, then we implement that season, then we launch it and see how it does. We develop waterfall marketing campaigns, we sell waterfall tickets (bought far in advance of the intended date…by which time a theatergoer might not feel like attending any more) and we staff our organizations to support the waterfall methodology. We are governed, in the main, by the waterfall metaphor.
But waterfall isn’t our only option. We could make agile theater instead.
It’s time to start paying a bit more attention to those entrenched patterns we’re relying on…and deciding more overtly which might be serving our sector the best.
In agile software development, a product is built in a succession of slightly-improved drafts, rather than in carefully aligned phases. You make a rough version of what you want to build, then you show it to some of the people who might use it and gather feedback, and then you use that feedback to make the next version. Lather, rinse, repeat. There isn’t one big ejaculatory launch at the end of development; there’s a series of smaller rolling launches, each slightly more robust than the one before it.
Perhaps more importantly, in agile development a product is built by a self-organizing, cross-disciplinary team working in parallel, rather than by a series of expert solo practitioners each doing their jobs largely by themselves and then handing their work off to the next expert in line. Every team member contributes his or her own expertise to the general effort, but nobody’s perspective is sacred; everybody works in service to a product’s users. To rely on a sports metaphor, if waterfall development is like a relay race, then agile is more like a rugby scrum.
The primary benefit of agile development? Adaptability. If something isn’t working, you find out right away and adjust before it’s too late. The difficult notion for some people to come to grips with? That you don’t have a product entirely planned out, down to the last detail, before you start working. When you set out to make a piece of software, you never know precisely what you’re going to end up with—a feature that might seem obvious or essential at the outset of a project might not “test” particularly well with your intended users—but do you know people are much more likely to love it.
Increasingly, we are making agile plays, too. The obvious example: the work of devising ensembles: interdisciplinary groups of theater artists working collaboratively to create plays. (Look for a future column about agile and devised theater.) But I think it’s also worth asking what an agile theatrical organization might look like, too. A few thoughts:
- An agile theater wouldn’t have seasons; they’d just develop plays and release them when they were done.
- Speaking of which: an agile theater would ONLY do new work. (Waterfall is much more suited to well-traveled plays.)
- At an agile theater, rehearsals would be open to audience members on a semi-regular basis. (How else to get their feedback?)
- At an agile theater, audiences would be deeply invested in the work that ends up on stage, having played a real role in its creation.
- Agile theaters wouldn’t sell subscriptions. A subscription is just a kind of “theater attendance blueprint” to be slavishly followed. They might, however, develop loyalty programs to reward recurring attendance… and tickets would always be exchangeable.
- Agile theaters wouldn’t necessarily be run by artistic directors; they’d be more likely to function as collectives.
- If an artistic director did run an agile theater, her job would be to select devised projects, rather than plays.
The implications are wide-ranging and significant.
And all of this is happening, right now, throughout the American theater. With the rise in devising ensembles, the emphasis on audience integration, and the decline of season subscriptions in some quarters, we are arguably at the beginning of an agile theater movement. A significant percentage of the small independent theaters in my own city, DC, would definitely fit the agile description—Rorschach, for one, has abandoned the notion of a “season” entirely; dog & pony, for another, has been bringing audiences into its devising process earlier and earlier—and I suspect the same is true elsewhere as well. So I think it’s time to start paying a bit more attention to those entrenched patterns we’re relying on…and deciding more overtly which might be serving our sector the best.