No, that’s not a typo in the title. This is an article about how Improv techniques share much in common with Agile Programming methods, and how to take advantage of them. To get started, I’m going to need a few things from you: I need a place name, a famous politician, and a phobia.
That’s the kind of thing most people think of when they hear Improv, but there is much more to improvisational theater than short comedy games. If you go to an Improv show expecting a bunch of laughs, it can be weirdly disappointing at times. A big cultural expectation around Improv comes from the relatively common knowledge that legendary TV shows like Saturday Night Live and Second City Television primarily stocked their core talent from Improv theater groups. However, those shows are scripted and while the acting skills the cast demonstrate were developed in Improv and some of the famous characters used in sketches were also developed in Improv, the core of Improv techniques are far removed from scripted sketch comedy.
Let’s put aside the idea of funny and look at the mechanics of Improv. There is no script. The players are defining the rules collaboratively and reactively in real time. What keeps this from being a constant train wreck is that this shared creative work operates within the constraints of a set of rules. In either short-form or long-form Improv, there are guidelines and rules that define what the scope of the story allows. As long as the players work within those guidelines and within the core rules of Improv, the scene can be successful.
Core rules? Yes, and there are several.
While there is no universally accepted Bible of Improv, you can find the basic core rules in a variety of places. If you have 8 mins to spare, this video compiles quite a few of them.
For the purposes of this article, I’m going to refer to the work of comedy researcher Tina Fey and her book Bossy Pants. She devotes a section of that text to the ground rules of Improv. I’m going to list them, and then talk about how they are relevant to Agile Development practices.¹
Agree
“Always agree and SAY YES. When you’re improvising, this means you are required to agree with whatever your partner has created.”
Yes, and…
“You are supposed to agree and then add something of your own.”
Make Statements
“This is a positive way of saying ‘Don’t ask questions all the time.’”
There are No Mistakes, Only Opportunities
“In Improv there are no mistakes, only beautiful happy accidents. And many of the world’s greatest discoveries have been by accident.”
Although listing these rules without the insightful, illuminating text through which she explains them renders them somewhat less impactful, these rules still operate as the core groundwork upon which successful Improv scenes are built. And I see strong parallels between these rules and the rules at play in a successful Agile Development project.
Agree
The idea behind the idea of Agree is that saying “no” ends the collaboration. Saying “yes” keeps things moving. Saying “yes” can be the scariest thing about a project because it means agreeing to try something new, to accepting collaboration with people and ideas outside your comfort zone, and leaving the comfort of the status quo. But without that “yes” there is no project.
In Improv and in Agile, this is not an agreement to literally say “yes” to everything. That would not work on stage and it won’t work in real life — but the goal here is to use the common assent of moving forward as the basis for developing something together.
Yes, and…
This rule is so important. It’s the true basis of Improv collaboration. You listen to the other player and elaborate on their ideas without destroying the flow. Really, this is key to any good teamwork. The collaborative process involves validating and encouraging contributions from everyone. This isn’t a hippy-dippy endorsement of “everyone is right” but it’s about finding the useful parts of what others have to say and using those to prompt innovation.
In Improv, this can mean running the same game will always get you a different outcome because the innovations and collaborations are driven by the almost unconscious imaginative impulses of the creative brain. Together, the players use honesty and adherence to these core rules to craft a scene that is honest and functional within the rules of the game. Similarly, in an Agile project, the developers use the feedback from the clients to drive the development of tools that work within the rules and limits of the development framework. (And within the rules and framework of the infrastructure and administration of the client’s business.)
The Yes, and… mentality also encourages everyone to share their ideas. Nothing stifles innovation quite as much as fear of speaking out. Everyone has to be able to share their ideas because whether they’re the piece that solves a portion of the puzzle or not, nobody would ever know if they aren’t put out for everyone to consider. Improv doesn’t work in a culture of fear, and neither does Agile.
Make Statements
This is about not being afraid to say something. Questions can be critical to Agile, but somebody has to be making definitive statements or nobody will be able to build the needed solution. In Improv, with a few exceptions, it is critical that people be bold and make statements. Open questions can kill the scene, or throw all the work onto less fearful players. In Agile, this is also true. Don’t let fear control you.
Innovation incubators make much of the philosophy of fail fast, fail often. On stage that must be a terrifying prospect since the audience feedback (or lack thereof) can be immediate. But fear cripples comedy and software development, and practice at making bold choices is the best remedy for debilitating timidity.
There are no Mistakes
Of course, there are mistakes. This isn’t about pretending there are no mistakes, it’s about having a philosophy about how to handle mistakes: You roll with them, you work around them, you turn them into surprising learning opportunities, you do anything but let them stop you.
When I took on this topic, I didn’t think there was as much overlap with Improv and Agile. But I wanted to explore it, and the more that I looked at it the more it made sense to me that so many companies use Improv classes as team building exercises. This isn’t a way to prove that your employees are hilariously talented. It’s a way to show your employees that they can work as a team and be fearless and creative. The public might think that the only successful Improv show is one where the audience laughs uproariously but for the players, success is about being honest and sharing and boldly moving forward in creative ways within the constraints of the rules. How is that not like Agile Development?
¹This is a well-known blogging technique where one attempts to associate a fun thing with something perceived as un-fun. Or fun, but with a silent “f.” If used successfully, this can provide insight and make a mundane topic seem shiny and interesting. Alternatively, it can be like stepping on freshly chewed gum on a summer sidewalk. It sticks — but not in a way you’d like. Hopefully, the former is achieved herein.
