I won’t be able to deliver on time. My estimation was too optimistic. What can I do now?
If you can’t deliver on time, don’t. Simple, isn’t it?
I believe the best strategy is cutting features and start both constantly refining your estimation and doing Deliberate Discovery. In other words, I believe the question was somehow misplaced.
Reading Introducing Deliberate Discovery by Dan North I came to the conclusion that placing the estimation effort in the inception phase equals to make a prediction exactly when your ignorance of the problem and the domain is at a maximun level. Face it, you cannot predict what’s uncertain, especially if it’s (yet) mostly unknown. If you do, be prepared to fail (and to be forced to cut features).
One should never promise to be on time for the deadline. Always expect the worst. Murphy was the greatest engineer ever. Ok, I’m provokingly kidding.
Agile methodologies solve this problem breaking the project’s life span into several pieces (sprints in Scrum, iterations in XP), and repeating the estimation (sizing stories) each week. Each week, what you know about the problem is refined, and so is the estimation.
What do do: cut features
The best you can do when you are late is to cut features so you can ship on time. Cutting features means resizing the project scope, at least for this deadline.
If you think that it’s a dirty trick: yes, it is. It’s the only smart thing to do, to me.
And it’s really dirty: that’s why it’s the topic of this amazing podcast episode, hosted by Quick and Dirty Tips by Stever Robbins, the Get It Done Guy. Listen it, it’s very inspiring. And it’s not specific to software developing.
When you are late (and also when you “risk to deliver in advance”, because the problem is the same: you have estimated badly) do escalation and raise the fact to the customer as soon as possible. “As soon as possible” is simple, in Scrum: a sprint is just a week long. Scrum and Agile in general are about micro-predictability.
It’s called risk management. The sooner you give a feedback, the more effective the counter-measure will be.
And yes, usually the counter-measure will be cutting features. If you have evidences you cannot deliver everything, you should talk to your customer, tell her you can deliver only the 70% of the commitment and let her decide what’s has more business value for her and should deployed first.
Or add more developers to the project team. But keep it secret and never tell it to Frederik Brooks. He won’t agree.
Do Deliberate Discovery
Coming back to Dan North’s article, you could reformulate the original question this way:
My estimation was too optimistic. Now, no more waterfall and cut-features. But, what should I have done?
Now, why was your expectation too optimistic? Because, when you formulated it you didn’t know that something bad and unpredictable would have happened.
Dan North says
Several (pick a number) Unpredictable Bad Things will happen during your project.
You cannot know in advance what those Bad Things will be. That’s what Unpredictable means.
The Bad Things will materially impact delivery. That’s what Bad means.
The Bad Unpredictable events were the pessimistic part that your estimation lacked. Your estimation was optimistic because you were not ignorant of being ignorant. You didn’t believe in Murphy’s Law.
Dan Norths’s gives us a precious suggestion: assume things will go bad. Never be optimistic. However, Dan is not Murphy. He goes further. He says: do not be passive either. Face the fact that something bad will happen, and that it will impact delivery, and also that you have no idea of the nature and the size of the problem. If you admit your ignorance is a second-order ignorance you can use all the efforts to investigate about all the things you don’t know yet.
You are used to make an estimation based of what you know. But it’s what you do not know yet the most decisive element for the deadline.
Be pessimistic, then investigate on your weakness, especially weakness you don’t know you have.
A famous Italian politician once said
Thinking bad of others is a sin, but often it allows you to guess right
To paraphrase him, I would change others with story sizes
The next week I’ll write some (humble) posts about what to do to do Deliberate Discovery in practice, from a developer’s point of view. Yes, I’ll write about code.
On the same topic, What’s the biggest difference between Waterfall and Agile