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.
Cheers!
Arialdo Martini 
Nice post. I could be wrong but it sounds like the sprints are mini-waterfalls here? What have I missed?
Aren’t they?
The fact they are mini is the difference, to me.
If you fail to deliver, you’re limiting the damage. The gap between your promise and the moment you deliver cannot be greater than 5 days.
But this is the only element sprints have in common with waterfall: they both start with a promise to be kept. During the spring, you won’t organize your work in a waterfall style (design-develop-test-deploy), will you?
@pauliom
I found a very interesting (and long) article with some smart thoughts about agile and commitments.
http://yuvalyeret.com/2011/10/13/scrum-sprint-commitment-rant/
Hi Arialdo, nice post.
Talking about my graph:
1) it’s a mockup. There is no precise way to measure ignorance 🙂
2) deployment was never intended to be at the end. If so (old style waterfall) you might finish the project and still remain ignorant. Every project has it’s story but the more feedback you gather the more likely you are to re-think about what you’ve done. And deploying in production is a very effective way to gather feedback from real users.
Keep up the good work.
Got the point.
Ok, I probably tried to infer too much from a mockup graph, and I apologies: the post itself wan’t intended to be a criticism.
PS. “Deploying in production is a very effective way to gather feedback from real users” is amazing. I never saw “deploying” as a way for gathering information and decreasing ignorance. It’s brilliant. You’re right. As usual, after all 🙂