Staging a play the agile way

It’s been roughly two years since I wrote and staged my IT-comedy Fair Trade, which we performed on location for two teams of developers. Great fun it was, and it’s available here if you read Dutch. With all my years of experience in incremental product delivery I was wondering: could you produce a play in monthly sprints, sharing the incremental deliveries with an audience? Spoiler: no, you couldn’t. It’d be torture for everyone involved. It’s waterfall or nothing.

A stage play is conceived much like an animal – humans included: you start with an idea and a plot, and flesh them out with dialogue and characters. You don’t start with the feet and proceed with the legs; it grows organically. Once you have a first draft you keep revising and rewriting until you’re confident that it will work on stage. You do a big, up-front design. Suppose you show all these intermediate draft versions to a live audience. No fun to sit through for either party, I can promise you that. It would be terribly cruel on the actors too: every month they’d have to learn all new words and rehearse different scenes. It’s also extremely wasteful: you’re basically throwing away all your source code to replace it with a better version each sprint.

Okay, then why not make sure scene one is perfect, show it to an audience and then proceed to scene two, right till the end? That way the audience experiences your story as it would view episodes in a series, and we append new stuff to the tried and tested parts we already have. This is actually how Charles Dickens wrote his novels: in monthly instalments. Sounds like a lot less waste, doesn’t it? But I wouldn’t like it any better. It takes time for an actor to get into the skin of their character and for that they need the whole story, not just the first scene. Dickens didn’t wing it, by the way. He prepared his stories and characters meticulously. Before the first deployment he had his backlog of stories sorted out, with very little refinement required.

As software people we may be tempted to think that an agile, incremental way of working is the best solution for any creative endeavour. But that’s not how it works. In fact, I’d rather think that software is the odd man out. First, it is functionally very complex. We don’t know exactly what it’s supposed to do down to the details and even then it will have to prove its usefulness in the field. By comparison, the use case of a bridge is not complex at all – even though the design and implementation will be. Secondly, software is reasonably malleable (if you code cleanly) and luckily we can adjust the destination on the way, because we so often have to. Unlike a railway or a bridge.