What do you do with the blockers you can’t remove (and the ones you don’t even know about)?
In Scrum, you’re supposed to use the iterative process to identify blockers and impediments — things that are stopping the development team from doing what they’re being asked to do.
There’s a meeting every day — the stand-up — where these can be raised. And there’s a longer meeting every fortnight — the retrospective where bigger things can get raised and looked at in more detail.
This sounds great. The team rolls up their sleeves, identifies the issues that are stopping them from making progress and fixes them.
But of course, this presents an obvious question, that I haven’t heard anybody discuss.
What do you do about the blockers that you can’t solve?
Well? What do you do about them?
What sort of blockers might these be? They are often what I call “bricks without straw” blockers. For example terrible internet access. This is a bit of a classic that I’ve had to deal a couple of times.
Why would a client ask you to do a huge complicated piece of software development, insist that you do it in an office building provided by them, and then refuse to provide any better than you’re nan’s wifi?
One way of seeing these blockers is that they are the real challenge of the project. Understanding and addressing these resistant, if not immoveble blockers is the challenge that you unknowling accepted when you tried to deliver the project.
But unfortunately, that’s only part of the story with identifying blockers. Beyond this there is another question.
What do you do about the blockers that you don’t know about?
Possibly you don’t know about them because they are being deliberately hidden from you.
Yes, that’s right. The client may well be hiding from you powerful reasons why the project may never succeed.
You might ask, why on earth would they do that? And often the answer is that you don’t know.
What sorts of things might your client be hiding from you?
Here are some real examples.
1. A contractual dispute between the client and one of it’s suppliers which means that the servers you’re being provided with are being deliver by the supplier on a “work to rule” basis — i.e. based on an old specification in an old contract. The customer knows that they won’t work. The supplier knows that they won’t work. They’re both leaving you as the development partner to work it out. Oh, and here’s the kicker. Even if you do work it out, they’ll neigher confirm or deny it, because they claim it’s an official secret.
2. A request for a marketing project for a bank, which the customer knows will get utterly crushed under the requirements of the financial regulatory authorities at some point during its development (this has actually happened to me twice).
3. An e-commerce site which sells widgets, in which the customer is constantly pushing for the developing to go faster and faster so that it can be ready for ad campaign and marketing deadline. The customer has no widgets to sell.
This is what project management is actually about.
