Improv meets Software Engineering, what might the intersection look like?
When I first discovered improv, I enjoyed the creative play and sheer freedom it offered me. The basic tenets of improv gave me a safe place to unleash my creativity. The right side of my brain finally had an outlet. (I couldn’t draw or play an instrument. I did enjoy singing, but I knew not to do that in a public setting!) I enjoyed every improv exercise that was introduced to me. Finally, I had an outlet to be creative and to play.
For the longest time, I didn’t see how this could apply to software development. Deep down, I knew there must be a connection, but how could doing quick, fun exercises relate to software?
I did see how improv was affecting me and my style. My public speaking confidence was increasing. I was faster with responses to tough questions. My eye contact with others was on the rise. While I’ve been an active listener, I noticed areas that I could grow. I saw how those skills translated directly to my work. Brainstorming was more effective when we bypass the critical analytical components of the brain. Teams could be more effective if they could more readily accept ideas from teammates. (If we don’t agree with an idea, we tend not to accept it. However we can accept an offer from someone else without agreeing with it. Even with a ridiculous suggestion, good ideas can emerge.)
In preparing for the Applied Improvisors Network (AIN) conference of 2011, I reflected on software development and its intersection with improv. I came to a new realization, are not the agile methods aligned with the notions of improv? Let’s look at ideas from improv and see how they map into modern software development.
The whole improve troop owns the show. If a performer steps out on stage, they are committing to the team that they have five seconds worth of an idea and trusts that the rest of the team will help them the rest. Agile methods encourage “whole team” where the entire team responsible for ownership of software development and management. This encourage collective owning of the source code repository where any member of the team can make changes as well as the notion that the team can manage itself. Improvisators set out to make their partner look good. Scene work happens when the entire troupe is helping and working together. This includes knowing when to go on stage in order to further a scene along and knowing when not to go on stage because everything is going to work out fine.Software developers want their team to look good.
Change: Improv thrives in chaotic situations. Improvisers are trained to deal with change. When improvisers are operating at the speed of thought on stage, anything can happen, and improvers try to make sense of it all. Agile methods are more ideal than traditional methods in environments where the requirements are changing. Even Extreme Programming’s slogan is “embrace change”
Improvisers learn to be loose with their own ideas. In the dynamic environment of the stage, they need to be present in the moment, dealing with what is going on. If they are thinking too much about where they want the scene to head, they will miss out on where the scene is actually going. You can observe this when a performer says something that sounds like they weren’t listening to what was just said. The performer was “in their head” trying to plan ahead and missed the last offer from their peer. We see this flexibility in the agile principals. With Test Driven Development, software developers hold the code loosely. Code written yesterday might be refactored and improved today. There isn’t this notion of ideal or prefect software that never changes. As the situation changes, so does the code.
Improvisers work on actively listening. Extreme Programming’s on site customer provides a direct customer voice into the software development process. As the engineer understands in real time the requirements from the customer, software is developed and refined in quick coding cycles.
Improvisers have techniques to celebrate failure. This is imperative because improvisers will fail. In warm up games, improvisers that aren’t failing aren’t playing them too safely. Agile methods have quick iterations and rapid software prototyping that allows for (in a software sense) for features to be explored and “fail.” If something isn’t working right it is tweaked in the next iteration. Albeit the timeframe is different. Obviously improvisers fail numerous times during a warm up and might make unusual choices on stage, where as the timeframe on requirements churn might be the next iteration typically one week to four weeks. In a paired programming setting, ideas can be tried and experimented upon. Failure in this context may happen routinely during a coding session. Coder 1: Should this be a new class or should we modify an existing class? Coder 2: I don’t know, let’s try option 1. After a few minutes if option 1 isn’t working out, they can quickly switch to option 2.
Interestingly, the improv game “word at a time” maps into paired programming. In “word at a time” a group tells a story with each person saying only one word. This exercise teaches shared ownership and the frustration of planning ahead. Variants of the game include “one sentence at a time” or “1, 2, 3, 4, 3, 2, 1 words at a time.” In paired programming, developers work on the same code at the same time. Typically the code is shown on one monitor but there are two keyboards and two mice so that at any point in time, either developer can start typing what they are thinking. There are many benefits to paired programming including high quality product with less defects, a product that is ready to be shipped sooner, team ownership of the entire code based (as opposed to code silos owned by a single programmer), shared understanding of the code base (every line of code was written by two people, if one leaves the company someone else knows what that code was doing). Often in pair programming, developers may take turns. I’ll write a test case and my partner will make the code work. They will then write a test case, and I’ll then get it to work. This practice is called ping-pong paired programming. This is much like “A paragraph at a time” The emphasis is on the dialogue between the two engineers and the code is the artifact of the conversation that happened.
Today, I see many similarities between improv and software development. I suspect that there are new concepts in software development that might be explored given insights in improv. That is a topic of more future research.
