Agile Theater Makers
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.
A few columns ago, I discussed the two dominant models of software development—waterfall and agile—and started to explore what the latter might have to teach us about theater. (See Goodbye Waterfall, Hello Agile for the full column, but here’s a quick recap. Waterfall theater resembles a traditional manufacturing process; we design/write a play, then build/produce it, then hand it off relatively untested to an audience. In agile theater, by contrast, we design a play AND test it with audience members AS we build it.) I’ve been thinking about that column quite a bit. I believe there may still be more we can learn from agile development: specifically, about the roles and job descriptions we commonly use in the theater.
The common roles played by the members of a waterfall software development team correspond somewhat straightforwardly to roles played by those of us working in the theater:
An account director provides strategic vision and stewardship of a project, much like a director.
A project manager makes sure everyone working on a project communicates effectively, stays on task, and hits deadlines, much like a stage manager.
A user experience professional creates the blueprints for the product that’s going to be built, much like a playwright when writing a script.
A designer determines what a product is going to look like, much like designers in the theater.
A programmer actually builds the product, making it real for people, much like actors.
I am, admittedly, simplifying in a few cases, but you get my drift.
On an agile software team, by contrast, there are only three roles: product owner, scrum master, and development team member. Agile teams are often talked about in automotive terms. The product owner is the driver, setting the course and steering the journey; the scrum master is the mechanic, keeping the car well-tuned and functional; and the development team is, of course, the car itself. Let’s look at each role separately, comparing product development on the one hand with a theatrical production on the other, and try to find—or, rather, create—theatrical equivalents:
In agile development, a product owner is responsible for having and communicating a vision of the product that’s going to be built, prioritizing the features laid out in that vision, and making sure that the needs of a product’s users are represented during development. With regard to laying out the broad strokes of what a product might look like—without actually building anything, mind you—a product owner sounds a bit like a playwright who stops working immediately after writing the play’s synopsis and outline. With regard to understanding users, however, a product owner seems a bit like an artistic director, who should (at least in theory) have some in-depth knowledge about a theater’s audience members and the stories or subjects that might engage them. So perhaps it’s a bit of a hodge-podge role: one not currently in use in the theater.
In agile development, a scrum master is focused on serving the needs of the remainder of the development team: sheltering them from distractions, facilitating conversations about the ongoing work, and eliminating any obstacles. To the extent that a scrum master has to keep people on task and on deadline, the role that comes most quickly to mind is stage manager. And yet… the scrum master is also a facilitator-of-creativity, a supportive leader, and a resource for helping team members get creatively unblocked. That sounds like a director to me, too, at least in part. Another hodge-podge.
And finally, the members of an agile development team build the product laid out by the product owner’s vision. Although they may all come from different disciplines, there’s an expectation that team members will often work outside their typical areas of focus as well; the team collaborates in whatever ways it sees fit to make sure the necessary tasks are completed. The correlations here are a bit more straightforward. Designers and actors make sense, obviously, as do playwrights again. But the beauty of agile development, as I’ve mentioned, is that team members are expected to work outside “their” disciplines. So the theatrical equivalent of an agile development team might really be a collection of “slash” artists—you know, designer/actors and actor/writers and writer/directors and so on. Sort of a third kind of hodge-podge, in other words.
So let’s put that all together and imagine what a group of agile theater makers might look like. You’d have one person familiar with a theater’s audience establishing a clear vision for a production. Then you’d have a different person facilitating the work of several others in making that vision manifest. Does that sound like a devising ensemble to you? It does to me, at least in part… but not wholly.
In my experience as a member of two devising ensembles, what I struggled with most significantly—and what I’ve sensed others struggling with as well—is an understanding of the role I was intended to play as a “slash” artist. As a person who has most often identified as a playwright (though I do perform as well)—and who has thus become accustomed to the (entirely illusory) belief that at some level, a play is “mine”—I have had to learn to let go of some of the privileges I’ve been given by the “waterfall theater” world. That isn’t easy. Conversely, I’ve seen so many people who typically identify as actors or designers struggle to take on the responsibility of writing lines. A truly agile theater would demand that we stretch and expand our self-definitions.
Perhaps the biggest stretch, to my mind, is that members of an agile theater team would need to direct themselves. (Agile software teams organize their own work and share the burden of figuring out how to respond to the requirements laid out by the product owner.) Does that strike you as difficult? We are so accustomed to having a centralized authority figure make decisions in the theater—even with a light hand and a facilitative mindset—that we struggle not only to assume the mantle of authority, but also then to share it with others.
I think an agile theater would probably teach us all quite a bit about relinquishing creative control.
Speaking of centralized authority figures: we are also so accustomed to having the “initial creative impulse” of a play come from a playwright that I’m guessing many people reading this column glossed over the fact that I immediately put a writer into the product owner role a few paragraphs ago. But given the core task of the role—establishing the high-level vision for a production—is there any reason why, say, a designer or actor couldn’t serve as a product owner? I mean… why should playwrights be the only theater artists who get to sit in the “big vision” chair? In an agile theater world, they wouldn’t.
And that leads me to one final thought about agile theater. Working as the product owner in an agile software project means you get to define what ought to be built… but that you don’t get to do the building. There’s no micromanagement of a development team member’s work, either. You say “People want to have this kind of experience,” then your team builds that kind of experience. It’s sort of like commissioning a play about a particular subject in a particular genre, but having little influence over the details of the resulting work. I think an agile theater would probably teach us all quite a bit about relinquishing creative control.
What do you think? Is the theater you make agile in any way? Do you see yourself playing any of the roles I’ve outlined? Would your work as an artist differ in any way? What challenges might you have in an agile theatrical world? What opportunities? Is the metaphor even useful at all? Why or why not?