How might the techniques of improvisation be used in software teams?
In Blink, Malcolm Gladwell, author of the best-seller The Tipping Point, examines the structure of spontaneity. Gladwell observes that one of the critical rules of comedic improvisation is that the characters in skit accept everything that happens to them. He refers to this as the rule of steadfast acceptance.
Improvisation and Acceptance
Gladwell illustrates the role of positive acceptance with two improvisational comedy skits using the same comedic actors playing a doctor and a patient. The initial setup for the skit is that the patient's leg is in pain. The first skit has a funny line, but quickly stalls out:
Patient: I'm having trouble with my leg.Both actors become frustrated because the improvisation stalls abruptly. Why? Because the doctor offers a suggestion, "I'll have to amputate", but the patient rebuffs the suggestion, saying "You can't do that, Doctor"
Doctor: I'm afraid I'll have to amputate.
Patient: You can't do that, Doctor.
Doctor: Why not?
Patient: Because I'm rather attached to it.
Doctor: (losing heart) Come on, man.
Patient: I've got this growth on my arm too, Doctor.
The following skit that Gladwell uses is more sustainable because the comedic actors agree beforehand to accept rather than negate any turn of events:
Patient: It's my leg, Doctor.The first skit peters out to a pre-mature end. The second skit opens up with possibility.
Doctor: This looks nasty. I shall have to amputate.
Patient: It's the one you amputated last time, Doctor.
Doctor: You mean you've got a pain in your wooden leg?
Patient: Yes Doctor.
Doctor: You know what this means?
Patient: Not woodworm, Doctor!
Doctor: Yes. We'll have to remove it before it spreads
(Patient's chair collapses.)
Doctor: My god! It's spreading to the furniture!
How might our software teams apply Steadfast Acceptance to paired programming, architectural decision-making, or iteration planning?
Listen to - and carefully consider - your teammate's suggestionsHas your suggestion been rebuffed while pairing on a programming task, or while a participant in a decision-making meeting, or while participating in planning an iteration? It's a mojo-killer. Many people squash ideas with uncanny regularity. It's destructive.
Should we consider taking our cue from actors trained in comedic improvisation who
accept all offersto move the skit forward? Should we accept that none of us are truly smart enough to anticipate where our software skits will go?
Unilateralism is the bane of teamwork. I once worked with a talented programmer who consistently countered any suggestion or observation I made. It was baffling. To break the logjam I tried magnanimity. I enthusiastically agreed to his assertions, even when I thought my suggestions, or the ideas of others, had promise. It became poisonously unproductive. I resented his autocracy. I resented his lack of respect for alternatives. It clouded my acceptance of his best ideas.
Comedic improvisation teaches us to
- Open ourselves to occasionally ego-compromising risks
- Adapt to the immediacy of change with mindfulness
- Improve our concentration skills
- Improve our listening skills
- Examine our responses to suggestions
- Recognize that rebuffing suggestions is a mojo-killer
- Consider steadfast acceptance as a practice (i.e., accept rather than negate a suggestion or a turn of events)