Better collaboration: Agile and Improv
IMPROVISATION
Collaboration and creativity are vital for effective Agile Teams. If you’ve ever watched “Whose Line is it Anyway?” on the TV, you will have seen improvisation (“improv”) in action. It is all about people working together in a mutually trusting atmosphere to co-create something new and surprising: the sum of the collective imaginations of those involved and something which could not have been known beforehand.
This is why, last week, we hosted an Agile Connexions Meetup on Improvisation for Agile Teams with Paul Goddard, author of Improv-ing Agile Teams: Using Constraints to Unlock Creativity.
Paul started off by asking the group what they associated improv with and there were various responses such as “thinking on your feet”, “comedy”, “chaos”, “creativity”, “spontaneity”, “originality”. But we were quickly put straight on some of these things. For example, being funny may be incidental and originality occurs naturally as simple ideas become combined in various ways organically. As for chaos, this is not an inevitable outcome of improvisation. In summary:
You don’t have to be …
1. FUNNY
2. ORIGINAL
3. CHAOTIC
We got into groups and played a game involving passing an imaginary ball around. This got us thinking about the nature of collaboration. Which actions felt collaborative? Which ones felt obstructive? Which ones felt aggressive? Very quickly we got a more acute sense of collaborative versus non-collaborative behaviour and also what it felt like when it was safe to fail — if someone did something wrong, the whole team took responsibility, threw up our hands and said “start again!”
SAFETY
Safety is key.
Safety is important to foster creativity. If there is a fear of failure then you can expect no one to speak up about any idea. A good climate for safety is one in which:
- There is trust (otherwise we filter lots of ideas)
- It doesn’t matter if we win or lose
- We slow down
To demonstrate this point, we were invited to get into pairs to play a very simple game called “What’s in the box?”.
In each pair, one mimed holding a bag while the second person mimed pulling out an imaginary object. On pulling out the object from the bag, the second person had to decide what it was that had been pulled out and declare: “This is an [X]”
In response to this, the person holding the bag would confirm enthusiastically, “Yes, this is an [X]”, optionally including a description of [X], such as: “Yes, this is a beautiful [X]!”
The purpose of this game? To understand experientially what it is like emotionally and psychologically to have your idea acknowledged and validated. What happened was that this served to create a safe environment in which you did not feel the need to filter your thoughts. Imagine an alternative response from the bag holder, such as silence, frowning, tutting, shaking of the head or a blunt “No, it isn’t”.
MAKING AND ACCEPTING OFFERS
By adding an adjective in response to describe object [X]: “Yes, this is a beautiful [X]” the bag holder was following the important improvisational pattern: “Yes, and …”
Improvisation is all about putting forward an idea — this is called “making an offer” — and in response, the offer should normally be accepted and built upon.
Imagine the scene: improv theatre, two performers on stage and the audience decides that the scene is a hospital:
Performer A: “Good morning, Doctor”
Here Performer A is making an offer which proposes both the time of day (morning) and the role of Performer B (a doctor). Performer B accepts the offer as follows:
Performer B: “Good morning, Mr. Robinson, how is the knee?”
So Performer B has accepted the offer (s/he acknowledges that it is the morning, takes the role of doctor and proposes that Performer B is a patient (rather than, say, a fellow doctor, a receptionist, a policeman, etc) and proposes an ailment (a bad knee) thus developing the story further.
As well as accepting the offer, Performer B has also added to the offer — this is the “Yes, and …” pattern.
BLOCKING
Instead of accepting the offer, Performer B could have blocked:
Performer A: “Good morning, Doctor”
Performer B: “I’m not a doctor” (BLOCK!)
Such a blocking response is typically counter-productive to the creative process. Instead of building a creative flow, Performer B is blocking the flow and killing it dead.
It can be tempting to block: it looks clever, it gets a laugh, it is easy and it keeps you invulnerable at the expense of the other. However, it is not conducive to creative collaboration.
WHAT MIGHT THIS LOOK LIKE IN A TECH TEAM?
How might this look like in a tech environment? I had a think about it. What would this actually look like in a planning meeting, a retro, a management meeting … ? Here’s a blocking example which I came up with:
Team Member A: “I think we need to spend a bit more time writing automated tests.” (OFFER)
Team Member B: “Oh and how are we supposed to get that done as well as all the other stuff?!” (BLOCK!)
Instead, here is a “Yes, and …” response:
Team Member A: “I think we need to spend a bit more time writing automated tests.” (OFFER)
Team Member B: “Yes we definitely do. Perhaps we can find a way to address this without slipping behind schedule.” (YES, AND …)
Team Member C: “Yes, I think we could identify a small number of key tests to tackle which could actually save us time later on.” (YES, AND …)
Pure poetry!
That may have been a simple example. How about this one:
Team Member A: “I think we need to spend more time doing up-front planning.”
Team Member B: “But that’s going back to the bad old days of Waterfall!” (BLOCK!)
The reason for the block is clear to see — Team Member B is worried about practices which go against Agile principles which s/he presumably believes in strongly.
But instead of blocking, it is possible to accept even if you disagree with the premise. To do this, you have to try to understand where Team Member A is coming from:
Team Member A: “I think we need to spend more time doing up-front planning.” (OFFER)
Team Member B: “Is that so we can get a better understanding of whether we have enough info or not?” (YES, AND …)
Team Member A: “Yes, exactly — if we had done more up-front planning, we wouldn’t have wasted time trying to implement feature [X]” (YES, AND …)
Team Member B: “Yes, that was a real waste of time. Could we maybe look at if there are any other ways to avoid that scenario in future? Maybe running it by the stakeholder straight after the backlog refinement session last week would have sorted this straight away and we wouldn’t even need to spend more time on up-front planning.” (YES, AND …)
Pure poetry, once again! Team Member B also shows that there is a genuine benefit behind the Agile principle rather than just relying on Agile dogma.
OVER TO YOU
Perhaps you can think of some recent examples of discussions on process, planning or technical implementation and consider what kind of patterns of dialogue took place.
***
Haran Rasalingam is the Lean Agile Coach at Trainline.
You may also be interested in reading:
