It’s never nice being the people who tell stakeholders No, and we IT people certainly have a long history of that. But even with more collaborative ways of working we can find ourselves in a delivery team where everyone else is waiting for us, and the only question anyone asks is “Are they going fast enough?”
Ideally we would avoid binary outcomes, but it’s not always possible. For example, if our product relies on data going from one place to another then every step in the chain has to be in place or we don’t have anything useful. Or if our application needs to be deployed to a particular environment or device then again having that is an essential step before we can say we’ve delivered any real value. The spotlight is pointing at us, and everyone is waiting.
In these kinds of situations it can be useful to split our product backlog into showstoppers and improvements. Showstoppers are any deliverables that have to be produced without which it is impossible to deliver our product. And this does mean “impossible”—not “inconvenient” or “highly undesirable”, but actually, physically impossible, regardless of how much money we might theoretically throw at it, or any inconvenience we may unhappily endure. Anything that isn’t a showstopper we label as something else—“improvements” perhaps.
Then when it comes to prioritising our work we tackle the showstoppers first. As long as we are able to deal with another showstopper we shouldn’t be picking up any of the other work; after all it’s the showstoppers which are stopping us.
And then once we’ve dealt with the showstoppers we are no longer the people who say No. Now we can enter into a dialogue about “how much” as we work through the rest of the backlog—the improvements. Immediately after the showstoppers we may have product which is incredibly inconvenient to use, and it may require lots of workarounds, but at least we can start to talk about how much imperfection is tolerable. As time goes on we reduce the imperfections and the spotlight starts to swing the other way. Our stakeholders can start asking themselves how they balance time and cost on the one hand, and overall quality on the other. It opens to the door to a much collaborative relationship; we become the enablers.
Of course, that “showstoppers” phase really needs to be as short as possible, which is why the ideal way to structure a project is to get a basic product out the door as soon as possible. But if we do find ourselves in a situation where there really is a minimum, without which we really have nothing of value, then a ruthless search to find the smallest showstopper list, and tackling that first, can help a great deal.
3 thoughts on “Deal with the showstoppers first”
When it seems an impossible task to find an MVP that isn’t actually just ‘everything’, this looks like a really good way to go. I’ll certainly try to use it next time when forming an MVP – all I need now is for the Product Owner not to call everything showstoppers…
Isn’t this just a different way of saying MVP?
Hi @Brunns. I don’t think this (the article) is another way of saying MVP. As @Gary suggests, MVP is a very abused term. If we’re taking it from Lean Startup, then I interpret MVP as being the smallest possible thing you can get out the door that validates some fundamental assumptions about your venture.
Using the showstoppers/improvements split might apply to any stage of a product or project. Even in the middle of a project the next stage might require key elements to be in place if it’s to have any value at all.
But I agree the principle of delivering a minimal product (without the Lean Startup definition) does eliminate a lot of the potential pain of such a situation.
Comments are closed.