Improvisational Theatre and Project Management - what have they got in common?
- the need to make it up as you go along - Part 3
Yes and. Yes AND?
Not knowing is the nearest approximation to the truth - (Zen Buddhist saying)
Some people would say that this is the most important concept in improvisation. Yes and. The idea is that when you're performing with another improviser, you don't say "No" to them. Actually - in improvisation terms, it's not so much that you don't actually say "No", it's that you don't say no to their ideas. So for example if a conversation goes like this:
Actor 1: Happy birthday! I bought you a cake! Actor 2: That's not a cake, it's a cauliflower!
That's what's called blocking in improv. It's a desperate attempt by one improviser to wrest control of the scene.
As with so many things when you're advocating change, you need to be careful to understand the difference between what you say and what people hear. What I'm not saying here is that you should say "Yes" to everything. What I'm saying is that you should say "Yes and," to everything - or, because I'm very uncomfortable (always uncomfortable?) with the universal quantifier, maybe we should say:
Say "Yes and" whenever you think you can manage it.
I think in project management the "Yes and" principle (let's call it) applies in two different ways. One is in saying "Yes and" to bosses and single stakeholders. And the other is in - I know this sounds a bit weird, but it's very true. In saying "Yes and" to reality.
"Yes and" Senior Stakeholders
In a way, the saying "Yes and" to bosses and senior stakeholders, is the easier of the two. It's just important to understand that "Yes and" isn't just "Yes." For example, in an Agile approach to managing projects, one of the wonders of having a product backlog is that you can agree to add anything to it - and then you can see how much it costs and how it needs to be prioritised relative to everything else in the project.
What I'm thinking about now - the "Yes but," that's coming up in my head, is how can you apply this approach if you have some "hero manager" who's asking your team to work 19 hours every day "19x7" as they love to call it, or even "24x7"? Oh and if this manager also insists on hourly "war room" meetings to update senior management on progress, in this case I'd be very tempted to say "no". But also, possibly if you are going to say yes (and people do). I'd also be tempted to "and" it in several ways.
...and of course because such an approach is hugely expensive (hopefully you're sticking the client with the cost of such folly), we'll want to keep a very close eye on whether it's working and whether our progress is actually improved by everyone giving up sleep.
...and of course, because we're making these special efforts to finish the project on time, you'll also be doing something to address the fundamental organisational and infrastructural problems that are actually slowing down the project.
...and of course, you'll be getting our bill.
...and even though we've agreed to this crazy working pattern, we'll be making sure our team works reasonable hours - even if they are working shifts.
This is certainly not for the faint-hearted. And not all improvisers - even those who specialise in these techniques in business settings agree on trying this "Yes and" approach in hostile settings. To quote Paul Z. Jackson - a leading advocate of the use of improv in business settings:
I know some improvisers who stretch the application to its utmost and test their every response in life against the principle. Others - and I'm among them - prefer to look for contexts in which "Yes... And..." has a relatively obvious and direct application.
There's another thing to mention here - another crucial improv principle.
Have lots of goes.
And of course the corollary to that is:
If a scene (or a project) is totally fucked up, then stop it (or leave).
Have another go somewhere else. Practice makes perfect. It is crucial to understand in real life, rather than improv, what your BATNA is - your Best Alternative to a Negotiated Agreement. And in almost situations, you have the option of walking away rather than perpetuating such craziness as 24x7 working. You can stay and fight, but you can also run.
"Yes and" Reality
The world is everything that is the case - Ludwig Wittgenstein.
It may be that sometimes you can safely reject malicious suggestions from senior management or other people who, in your judgement are trying to wreck your project or just send it in a wrong direction. However, it's almost never a good idea to refuse to accept reality, no matter how surprising, upsetting or downright wrong, you find it. Refusing to "Yes and" (i.e. accept and re-plan accordingly) cruel realities as they present themselves during a project is one of the main causes of project failure.
Whatever it is that's causing you the problems, poor communication within the team, poor communication with the client, farcical requirements, ropey hardware, flaky software or creaky architecture, you need to accept what the problems are before you can decide what to do about fixing them - or before you can help someone else to decide to do something about fixing them.
BTW - I'm reading this amazing book at the moment well worth a read.