How to disappoint people, part 2

This is a multipart series.

• Part 1: an overview of a workshop
• This post: the kinds of disappointment I mean
• Part 3: some tools I’ve found useful.

This series of posts describes a workshop I’ve run a few times, both inside my workplaces and at external events. I’ve found it a useful way to share some things I’ve learned and things I’m still struggling with, and to get participants to share ideas from their own experience.

This post describes the kinds of disappointment I mean — it can be used as described in part 1, as a starter for discussion in a workshop, or it might be useful to just read through on its own and see if you can relate.

Disappointment

This is a topic I’ve been thinking about for a long time — I’ve worked on a lot of projects and products at a lot of companies over the last 14 years, and I’ve gradually noticed the same issues coming up again and again. I think this workshop title — “How to disappoint people” — sums up one of the key ideas for successful software delivery.

In this post, I’ll talk you through what I mean by that — the situations I’ve found are common, some things I’ve found really helpful, and some areas I’m still stuck on — and I’m really interested to hear back whether these are the same problems and solutions you’re all facing, whether you’re hearing anything new that could help you, and whether you’ve got other experience in the same area you can share.

For the first 10 minutes or so you get to just listen [read!] — let me explain what I mean by disappointing people.

There’s a quote I read years ago that seemed to sum up a big part of my job — something like:

“Every project comes with a fixed amount of disappointment, and it’s up to you to decide how to deal with that — either discuss it honestly, as it comes up and there’s still time to do something about it, or save it all up for the end.”

I’ve repeated it loads of times, but when I came to write this I realised I’ve got no idea where I got it from. Some internet digging lead to…

“On Disappointment

“The planning game is certain to give you information that makes you unhappy. You may feel tempted to blame the messenger and stop playing the planning game, or stop using XP altogether. That would be a mistake. As David Schmaltz of True North pgs says, every project has a fixed amount of disappointment associated with it. You can either use the planning game to dole out the disappointment in measured doses… or save it all up for the end.”

James Shore and Shane Warden’s excellent Agile Book, from 2007 — he was talking about the planning game from extreme programming (later borrowed by Scrum). But he mentions he heard it from someone else…

“Every project starts with a fixed amount of disappointment, all of which must be dispersed before the project can conclude. Finding the courage to talk about what “shouldn’t be talked about” and create shared meaning will disperse this disappointment one bitter, but digestible spoonful at a time. Conversely, keeping your own counsel will defer disbursement until the retained volume becomes the entire disgusting menu.”

David Schmaltz from a company called True North — writing about it a newsletter from 1998. The internet has everything!

Having the courage to speak up is an important first step, but it needs to be done in the right way if it’s going to be productive. Let’s talk about how disappointing people can go when it’s handled poorly. You might have experienced stakeholders who have a very clear idea of something magnificent they’re expecting to have made:

Isn’t it majestic? And look, it’s not just a unicorn, check out the rainbow.

Magical.

Now, the stakeholder might have had this idea for a very long time, discussed it with lots of people, and never had any hint that it might not be possible in the time they want — or even that it might not be possible at all. If your immediate response to hearing their beautiful vision is to start cutting it down to what’s feasible, their reaction might look like this:

Only way to get this done with what we have is to strip out the rainbow. Look, we can use matt white paint.

Just like that, the rainbow’s gone — and that’s not even nice paint! Are those cobwebs?

Before that’s even been discussed, the next blow comes: unicorns don’t exist.

Are you sawing off its horn?

It’s a horse now. We can get you a horse.

This exchange is not the way to start a productive relationship.

Another, wearing source of disappointment is the constant stripping back of scope. I’ve had experiences where people want an initial version of something out soon — like a few months — but their list of features for that version is more like a multi-year roadmap. “What can you drop?” is initially met with creativity and a willingness to compromise. But as the list comes back multiple times, each time to be met with “That’s great! What else can you drop?”, you can see the light dying in their eyes. This chipping away at what was already meant to be a minimum list is draining.

Sometimes, being clear on what isn’t possible makes you look like the problem — a strong feeling from lots of people involved that everyone else has a can-do attitude, if we all pull together we can make this work, and if you would just stop blocking everyone by insisting there’s a problem then we could all go and get on with making this brilliant thing happen. Why are you — you, personally — standing in the way of that?

Of course, we’re supposed to have a modern solution to the fixed-time-and-scope, must-have-all-this-in-by-launch problem: with agile, you get a really basic version done as quickly as you can, then see how much further you need to iterate before moving onto something else. It’s a different way of thinking than the upfront planning, where you need to know how long everything’s going to take at the start.

Agile works great, but if someone isn’t already bought into thinking about work in that way, I haven’t found it helpful to bring up. I have had no success, ever, in persuading people to try thinking differently, if the first time they’re getting asked to consider this is when they already have a big-bang release in mind and a looming deadline. The door needs to be partly open already before you can push it further.

And you have to be aware of what’s gone before — for example, what’s the definition of “MVP” in your organisation? In some places, when you say it, what stakeholders have learned is “the most stripped-down, disappointing, failure of a version of what you really want that I can persuade you to sign up to. We’ll release that and never come back to it again, leaving it to wither”.

Similar challenges can come up when you use other techniques — for example, MoSCoW prioritisation is meant to usefully agree the Musts, Shoulds, Coulds and Won’ts of various features. But for some people, based on bitter past experience, they understand different definitions:

“M”: “Everything I can have the slightest hope of getting. Near the end, we’ll argue about which of these get dropped”

“S”: “Things you won’t do, but don’t want to admit to just yet”

“C”: “Please stop wasting my time”

That’s the tour of disappointments. Sound familiar? You can go back to part 1 to see how this tour fits into the workshop, or on to part 3 to hopefully get some good ideas for tools you can use to deal with these disappointments better.