I work as a software consultant at a company that does almost 100% pair programming. I have also performed improv comedy, in classes and onstage. I’ve realized that the skills needed to improvise with other people can also help us pair program better with pairs of all kinds.
Here in Chicago, Second City is famous for its comedy theater and its school of improvisation. However, the business also consults for Fortune 500 companies on developing better teamwork. Two of its executives, Kelly Leonard and Tom Yorton, have published a book on the subject: Yes, And: How Improvisation Reverses “No, But” Thinking and Improves Creativity and Collaboration–Lessons from The Second City. The book discusses the business value of improvisational skills, and it also prescribes exercises to develop those skills.
From this book I’ve identified some relevant improv tenets for pair programming and some improv exercises that might make us better at pairing.
1. Bring a brick, not a cathedral.
When a player steps onstage to perform improvisational comedy, they face the risk that something might not go as planned. In fact, they face the inevitability that something might not go as planned, because most of the show…isn’t planned.
In real life, we tend to mitigate this risk by making plans as to what we think should happen, and then trying to get those plans executed. This makes sense when, say, we are trying to figure out what direction our personal lives are going. But onstage, when performing with an ensemble, we hurt the performance by trying to push our plans, our stories, our fully formed ideas onto the other players. The point of improv is, instead, to see what a group of people can create together in the moment. Players don’t need to bring fully-formed ideas to the table. Instead, they can bring their half-baked ideas and trust their fellow cast members to support them to create something far more interesting than any one person could have created alone.
We see parallels to this in a team of developers. One person might have a grand vision for what the app should look like, how it should be structured, which tools we should use, and so on—and that developer will try to push those ideas onto the rest of the team. However, that approach wastes the skills and talents of the other developers. Grand Vision Developer kills the conversations that lead to software innovation.
So how do we get better at learning to approach a programming task with our pair by bringing just a brick?
Exercise: One Word Story
In this improv game, everyone stands in a circle and one person begins to tell a story—with just one word. The next person provides the next word, and so on and so forth, all the way around the circle.
That’s just a cute game, you argue. It would be much easier to just bring a brick to the conversation if I knew that my pair and my team members would support me. But I can’t trust them to support me—we’ve got too many Grand Vision Developers.
This is understandable. It’s not uncommon for teams of developers to poo-poo one another’s ideas out of hand and to focus on their own ideas. In improv, we have a word for a team that masters the art of supporting one another.
2. Ensemble
‘Ensemble’ describes the type of group dynamic that works well for improv work. The members of an ensemble need not all be the same, or all have the same skill level: they need only be willing to listen to each other and build on each other’s ideas. An ensemble does not have some dictator leader: it might have a director, but that director serves mostly as a facilitator, to help others contribute their ideas as opposed to contributing his or her own ideas. Rather than shooting down someone’s idea because it’s “bad,” ensemble members will try that idea out together, and let the results speak for themselves if the idea truly is bad. The better an ensemble gets at building on each other’s work and trying things out together, the less they have to worry about whether their material is ‘funny’—their interactions produce quality theatre with increasing frequency and consistency.
Wouldn’t it be nice if our development teams worked like this? The biggest barrier to turning software teams into ensembles comes from software developers’ overwhelming tendency to shoot down one another’s ideas and then belittle one another as people for having had those ideas. Improv development does not mix with an environment in which people have reason to fear sharing their ideas.
It’s not that developers are purposely evil and mean to each other. They’re just often extremely inwardly focused, and their primary stressor is taking what they have inside and trying to get other people on the outside to see their thoughts on how to do things. The struggle to get their own thoughts heard is often so difficult, that listening to what anyone else has to say falls completely by the wayside. Then, of course, everyone else has a difficult struggle to get their ideas heard, and the downward spiral continues. Members of software teams must learn to give focus to other people—stress free—with the knowledge that, when they have something to add, they can take that focus back and trust that others will listen to them.
Exercise: Give and Take Game
Everyone stands onstage (or just in a clear space). The game begins with one person having the focus of the group. That person can then give that focus to someone else—by nodding at them, pointing at them, touching them, or some other symbol. The group passes this focus around among them for a while.
Then the game is played with taking focus: one person has focus until someone else takes it by using some physical cue. At this point, you can try starting with multiple people having focus.
After this, the group can try both giving and taking focus among themselves at the same time. To do it, team members must be paying attention to one another, and they must recognize when they have focus and when they do not. The game reinforces the idea of ensemble—of working as a group and sharing focus to build on one another’s ideas.
Of course, even if everyone gets to express their ideas, those ideas cannot take unless others listen to them.
3. Listen
Leaders and workplace personalities of all kinds are notorious for being bad at listening. Developers might be especially bad at it—again, because it can become their sole focus to execute the stressful and effort-sapping task of getting themselves heard. That said, it takes a great deal of practice to listen—to really listen—to one’s teammates, even if one wants to listen. Most people must break themselves of the habit of listening to respond—listening only long enough to figure out what they will say in reaction—in favor of listening to understand.
So for this one, instead of just one exercise, we have four that progress in difficulty.
Exercise: String of Pearls
Everyone stands in a line, side by side. The person at the start of the line gets a sentence to say, like “The other day, I found the Stanley Cup lying in the road.” The person at the end of the line gets another sentnce, like “And that’s how I ended up on the moon.” So the starting person says their sentence, and the story moves down the line with each person making up a sentence that moves the story towards its ending point. Each participant must listen closely to what the previous person has said and think about how to make it easier for the next person in line to connect his or her portion of the story to the ending sentence.
Exercise: Thank You
Participants split into pairs, and each pair has a normal conversation. The difference is that, when one person finishes speaking, the other one says ‘thank you’ before responding.
The exercise reminds us to recognize other people’s words as gifts. When another person speaks to us, they spend time and attention on us that they could have spent elsewhere. This exercise serves as a reminder of that.
Exercise: Last Word First Word
Participants again split into pairs, and each pair has a conversation. This time, each person must begin their thought with the last word that the other person said.
Example:
Person 1: I went home sick yesterday from work.
Person 2: Work has consumed most of my time this summer.
Person 1: Summer makes me want to spend time outside.
The exercise forces participants to listen all the way up to the very last word their partner says, instead of shutting off in the middle to prepare their own response. You would be amazed how often we do this.
Exercise: Gibberish Game
This game is about reading tone and body language, rather than just hearing the words people say. For this one you need three volunteers to play in front of the rest of the group. Two of them will have a conversation in total gibberish. The third person will translate their conversation for everyone else, using tone and facial/body cues to discern what is being said.
People can have fun with this one. Second City executives have seen employees at client companies imitate specific coworkers in this exercise. That use of the exercise allowed the players to provide lighthearted feedback to their peers. However, because it was also public feedback that resonated with the whole crowd, the recipient realized how important it was to listen, pay attention, and respond. In this case, an improv exercise gave a work team the freedom to show irreverence. So they managed to point out something that really needed to change for the team to succeed.
Those opportunities present themselves more and more often as team members learn to work as an ensemble, and to trust that their coworkers want to support them. The fear of not being heard falls away. The fear of change falls away. Instead, team members can build on one another’s strengths and contributions to create something innovative. That kind of team is so much fun to be a part of, and that kind of product gives all of the team members something to be proud of.