The Essence Of Improv
I once took a 10-week class in improv theatre, from a true virtuoso, Ed Reggi.
It was quite a departure for me, and one of those classes that had an impact far beyond the duration and cost of the class. Now, it seems like it was 4 months of fun.
Here's some things I learned about improv, as they relate to programming and IT.
It's Ok To Fail: Just Fail Fast
The whole point of improvisation is to act on the fly, on the edge of failure. If you don't fail once in a while, then something isn't right.
In fact, there are games that improv performers play before practicing/learning that are intended to promote failure. Once you screw up, you're less likely to worry about it later. One game is "swish-bonk", where a group stands in a circle: someone shouts "swish" with an arm movement to the right. The recipient can swish to the right or "bonk" it back to the left. Variations, hijinx, and failure ensue.
Later, in an actual improv setting, a failed idea is ok: performers don't dwell on it. They keep things moving with a new idea.
This is reminiscent of two things:
- The entrepreneurial spirit of IT, where failed ventures can be a badge of honour
- The XP approach to design software, where we "embrace change". That is, we don't expect ideas to be correct, but we do want to correct them ASAP.
The essence of improv is 2 or more performers on a stage. No props. Just a sense of location and occupation, then: go. (e.g. A doctor and a lawyer wait for a bus.)
But there has to be at least 2 people. Yes, Robin Williams is fantastic on his own, but real improv, from what I can tell, is like dancing: it works best with two people, and gets more complicated with more.
Just like pair programming. The doubling factor of creativity and focus is the magic. Is it any wonder that the best music composers of the 20th century were a pair of complementary song-writers?
Yes, And...
The golden rule in improv is that one never says no. If you and I are waiting for a bus, and you say "hey did you break your leg?", the only legitimate reply is "yes, and....".
"No" is cheating. One has to go with it and riff from it.
This is a stretch for IT, but I once met a pleasant, effective sys admin, who told me that his policy for admin requests was:
My default answer is 'yes', unless there is a reason against doing it. Too many people have a default answer of 'no'.
That's something to consider for all corporate interactions, I suspect.
Watch A Virtuoso
Reggi, the instructor, never really did a full performance for the class. But he would do these 10-15 second riffs that had the essence of what he wanted to convey. For example, to illustrate some point, he would say "oh I don't know", pause, and then pretend he was in a supermarket and the lights go out.
And, it was magic. For that brief flash of time, he was in a supermarket and the lights did go out.
It was like watching a virtuoso guitar player dash off a fast, melodic lick that seems impossible.
We all need to find the code virtuosos and pay attention. There's a lot to learn.
Yes, and..... standup meetings are a lot more fun.
1 comment:
I used to be frustrated when working for a startup and sales/field guys would ask to do the craziest stuff. I finally realized my job was to say yes to as many of these as possible and find creative ways to make that happen within constrained resources. Way more fun that way.
Post a Comment