Among all the interesting concepts he exposed, one struck me the most.
Talking about Deliberate Discovery Alberto used this graph:
It shows what happens when if you anticipate the breakthrough, that is the moment when you discover something new that decreases your ignorance about your project. Yes, that’s exactly what Dan North says: you should anticipate that moment, actively and deliberately looking for it.
Yet I think that this graph can be refined.
First, because the ignorance level at the deployment moment is not zero. You deploy something because you have reached the deadline, not because you finally know everything about it. Yes, to me Software Developing is a never-ending story of upgrading-and-delivering value, that never comes to a moment when your knowledge of the problem is really 100%.
Secondly, because Alberto (strangely) represented lower values before the breakthrough. I’m sure it’s just a typo.
I think a more correct diagram could be
Estimation != commitment
Anyway, what’s the big deal?
The problem, with Waterfall, is your PM. She asks for an estimation. And she asks for it before you start developing a solution. In other words, your PM, as Alberto notices, asks for estimation exactly when your ignorance level is at a maximum level.
That’s baloney. Ok, I can give you my best estimation, no problem. But let me suggest you, my dear PM: ask me for it again the next week, I will be much more accurate, because I’ll be knowing something more about the project. And in 2 weeks I’ll be even more accurate. Ask me for an updated estimation constantly: it will be each time more accurate.
The sad truth with Waterfall is: the first (and only) estimation will be used for budget estimation; then, a Gantt will be produced and communicated to the customer. And then the customer will read in the Gantt a deadline date. And, unluckily, a deadline date is a commitment.
That’s how your estimation will be misinterpreted as a promise.
Oh my gosh, my estimation is wrong!
Chances are you will deploy the system 2 weeks late: your PM will say you missed your estimation, or your estimation was wrong.
Yes, PM, face it: my estimations are always wrong. That’s why they are called estimations, not commitments. What if I deployed the project 2 weeks in advance? Would you be happy? Be equally disappointed, instead, because I gave you a wrong estimation.
Actually, an estimation cannot be true or false. It just can be increasingly refined.
With Agile you face this fact: each sprint, the team comes to an agreement with the customer for the next week. It’s not an estimation: it’s a real commitment, based on what the team and the customer currently know about the problem. Of course, a commitment based on an estimation. You consciously put yourself in a precise point on Alberto’s graph. The next sprint, the next week the team and the customer will know something more about the problem: their ignorance will be a bit lower.
With Waterfall, the moment the team emits the first and sole estimation, this is seen and treated as a commitment, and a lot of unpredictable events are deceivingly seen as predictable. That’s so wrong.
Waterfall fails in two things: it relies on forecasts made at the weakest moment, just when the ignorance is at highest level, and it treats estimations as if they are commitments, never worrying to update them.
Agile allows to increasingly estimate and constantly deliver. The only way you can take advantage of Deliberate Discovery.
I wrote about this topic also here: I made a wrong estimation. Help! I’m late. Cut features and stop waterfalling.