That Sinking Feeling
When a project starts to go wrong, you know it well before you admit it to yourself or your customer. You know that feeling when you start to realize you don’t have enough budget, time, or the scope is unachievable?
Long after we first get that sinking feeling, we may delay the difficult conversations with our customer, because we fear the pain it will cause. Despite our intention to be Agile, we may even fall into Death March project patterns, where we keep pretending that we are almost done and everything is going to be okay.
We start to dread communicating with our customers, and we give up hope of collaboration. The relationship deteriorates, and so by the time we can no longer ignore “the elephant in the room”, there is no trust remaining and we end up in conflict with our customer over how to try and rescue the project.
Avoiding the Death March
At the beginning of the project, if we had been more careful in our application of Agile principles, as well as carried through additional communication and estimation techniques, we could have avoided the death march. Or at least, we could have had the painful conversation earlier, when we could still do something about it.
But once we get going on our death march, out of fear of failure, we put off the difficult conversations until it is too late. This virtually guarantees failure of the project.
The Chopping Block Paradox
I call this behavior “the Chopping Block Paradox.” We know the project is on a path to failure, and we feel that our head is on the chopping block. If we could just change our practices and lift our head up, we could possibly get our head off the chopping block.
But often we don’t change our practices. We don’t attempt to change the project, and we are too afraid to let the customer know just how bad things are going. We keep our head on the chopping block, and we pray that if we don’t move, perhaps the customer will show pity and not lower the axe.
Instead of leaving our head on the chopping block, acting helpless, and just hoping things will turn out okay despite all the evidence to the contrary … we have to lift our head up. If we lift our head up early enough, we might avoid the chopping block altogether by strong communication and better practices.
Agile practices force Communication while there is still time
One of my favorite things about Scrum and Agile is that if I am following the practices correctly, I don’t have to deliver the bad news because the customer already knows.
They already know because they were there in the standups, and they heard the team continue to raise obstacles, or report minimal progress, or lots of “found” tasks that have to be done but weren’t in the sprint plan.
The customer already knows because they are watching the burndown at the same time I am, and they are seeing that it is not going down nearly enough to make the sprint commitments.
The customer already knows the project is unlikely to meet target release dates, because I’m sharing the burnup chart, and they can see that the iterations are not knocking enough items off the backlog.
And if things are really bad, they know that things aren’t on track because they can see in the demos that the features being delivered are not of high enough quality to release to the customer.
You can’t hide the truth – that’s a good thing!
It feels awful to have any of the symptoms of a project gone bad. And if I were on a traditional project, where I control what I tell the customer in “status reports”, then I might be inclined to cover up the truth, and hope things will get better.
But Agile keeps me honest, because I can’t hide it from the customer. I can’t cover it up in the vain hope that “we’ll make up the lost ground in the next sprint.”
No matter how much I may be inclined to leave my head on the chopping block and pray things will get better, Agile forces me to raise my head before it’s too late.
And talking to the customer before the situation is too dire is the only hope of salvaging a troubled project from failure.
