Techne

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.

 

Thumbnail

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?

 

Bookmark this page

Log in to add a bookmark

Gwydion Suilebhan discusses the impact of technology on theatre.

Techne

Interested in following this conversation in real time? Receive email alerting you to new threads and the continuation of current threads.

subscribe

Comments

3
Add Comment
Newest First

I may be quickly moving off topic but I am struck by how this kind of metaphor asks me to reimagine the role of an institution, as compared to a smaller creation-based group. I am thinking of how we could move toward a model of play development that would demand something different of an institution. Perhaps an institution could find roles for its staff that would also help move a project forward toward its potential level of excellence. I am thinking of how productive it was for me last week to bring in three staff members to a reading and then include them in the discussion afterward along with the other artists. While this is not a novel idea it did sensitize me to the potential of using people who are unfamiliar with the play, to serve as fabulously useful fresh voice partners commenting on the state of the story as they heard it.This is a small part of what I am thinking for the institution. For example, it is also conceivable that someone on staff who has a profound understanding of the folks who come to our theatre might be a useful partner during the development of the project. Or that the Production Manager could join the process earlier and contribute his creative ideas toward increasing the power of the staging of this story. My point being that we have all these talented people on staff and there may be a way to fold them into this kind of process so that they could bring in supplementary points of view at key moments in the development. So to bring it back to your language, it seems that there may be a place for some staff members to play a role within the "development team". And that idea is worth considering.

Oh, I love this. I do think that it makes sense, in some respects, to find more flexible ways to use staff members. After all, why shouldn't the entire institution be an art-making enterprise? Those are, I'm sure, some very well-informed audience members, too: an important cohort to investigate new work with for sure.

Gee, I'm only three years late to this discussion, but hope you don't mind me adding my two cents. I did a search on 'agile in theatre' or something like that and your site came up. Here's my scenario. I've been working on a musical for 10 years (music and lyrics) and my co-writer (she wrote the book) and I are going to be producing it this Spring - so we're very excited about it. Due to some casting challenges, she might be taking one of the supporting roles when she had been planning on directing. Now I'll likely be directing (we already have a music director). Pondering this possibility, I started to realize my long-standing experience in my 'day job' as a software product manager was going to come in quite handy! Why not apply Agile to the production process of our musical?! In software, we write 'user stories' - gee, this will fit nicely with the scenes that have been written. Next, we'll need to decide how many scenes in one 'sprint' can be 'release ready', i.e. ready for an audience. Over the last few years, conscious or not, we've used three readings for audience reaction and I really like your idea of bringing in outside folks/audience members for our 'sprints' to get early reaction and make any necessary changes. I had already been thinking of having a quick pre and post huddles with the cast with each rehearsal, and realized this is very similar to the 'daily stand up'. The actors do seem to line up with the 'development team', and I think as director/producer/writer, my role along with my writing partner, will be a bit of a mash up between scrum master and product owner. Thanks for the encouraging article! I'm really looking forward to our launch, erh ah, our production! Brenda Giordano - Bellevue, WA