8 rules for being successful even when forced to use Waterfall (with a pretty good estimation)

Waterfall can work

No it cannot.
I mean: actually, it does, but adopting new and modern methodologies, you can dramatically improve your team productivity.
Yet, I believe most teams are using a mix of Agile and Waterfall. The reason is Waterfall is the sole methodology able to give the only information your manager needs to know: how much the project will cost and what’s the delivery date. About this, read the excellent post by Christopher Goldsbury Why Agile Adoption Fails in Some Organizations

Estimation is the key

Among all the endeavors a developer is called to accomplish, estimation is the hardest one. It’s about predicting the future, while requisites are changing and while the company is pushing new tasks. A very hard job.

Agile has a very smart solution: don’t estimate at all. Do an estimation just for the next iteration/sprint (a week). That’s smart!

Yes, it’s smart. But it’s a very dirty trick.
Should you company like to accept it, and indiscriminately fund the project, you’re lucky: you work in a Really Agile Company.
Most of the time, though, your Company has budget to take care of. And deadlines to observe.

Very often, unfortunately, you must mix some Waterfall with your beloved Agile Methodology. Face it, you have to produce an estimation.

Even if you work in a Pure Agile Team, you need to estimate your stories.

Estimation is about control. Without estimates, you have no tools to measure productivity, because you cannot compare achieved results with expected results. With no estimation there’s no expectation; without expectation there’s no commitment.

Agile response to estimation is a bit presumptuous. “We are developers, we are doing the hardest job in the world. Software is just too much complicated to ask us for an estimation.”

Calm down: software developing is surely hard. But you should admit it: unless you are working in Google or Facebook, you aren’t doing magic things. Probably, you’re developing an ERP or just a corporate tool. What’s really hard, in your job, is that you have to handle very legacy and wrong systems, and very complicated workflows.

Now, stop for a while and compare your job with a surgeon’s one. Do you think a human body is less complicated and less fragile than a corporate software system? Is it less tricky and delicate?

When a surgeon needs to operate on a human (live) brain or heart, he needs to produce an exact estimation, since general anaesthetic is a very dangerous tool.

Why are surgeons perfectly able to produce an exact estimations before operating on a live brain and we developers are not? Or, worst: why we developers have totally dropped the ability to estimate, with Agile? Are we sure we’re not exaggerating?

Do use range estimates

In his really good post Stop Using Single Point Estimates Wyatt Greene proposes to use range estimates rather than single point estimates. Read it, it’s really interesting.
He writes:

Estimating how long it will take to develop software is difficult. Fortunately, as an industry we’ve moved away from big-planning-up-front, exhaustive Gantt charts and toward a more agile approach. Unfortunately, we’ve stuck with single point estimates which have some significant disadvantages when compared to range estimates.

He also proposes an algorithm, which I summarize as following:

  1. Select stories for the next iterations
  2. Breakdown stories into tasks
  3. Give an optimistic estimation
  4. Give a pessimistic estimation
  5. Calculate the total optimistic estimation
  6. Calculate the total pessimistic estimation
  7. Calculate the average estimation

I completely agree range estimates are way better that single point ones. I don’t agree on his algorithm, though.

The first doubt is: how could he achieve the first step “Select stories for the next iterations” since he needs to fill up the iteration with all stories whose story points, summed up, fit the next iteration, if he still doesn’t know their story points? I think he should first estimate the stories, then select which of them can fit the iteration. No problem, though: I’m pretty sure it’s just a typo. Or maybe he meant he would drop not fitting stories. Anyway, this is not the point.

What I found completely unsharable is the calculation of the “average estimation“.
It’s a non sense, to me. Never, ever calculate average on estimates. It will hide the real problem.

If you wonder why, it’s all about what I learnt from my Waterfall experience. Since I think, as an Agile Developer, I have something to learn from Waterfall (see Why you should learn some Waterfall as well) , I will try to explain how I think estimation should be done, both in Waterfall and in Scrummerfall teams.

An estimate is not a promise

I believe an estimation cannot be true or false. It just can be increasingly refined. An estimation is a reasonable prediction of the future. Since the future is unpredictable, while estimating you are having a bet. You might be lucky or unfortunate. All you can do is refining your bet in the future, before the deadline and rejecting the idea of communicating a single date, communicating a range, instead.

That’s why I believe in Agile and I think Wyatt Greene is right.
To me, what’s missing in Wyatt Greene’s analysis is the concept of bet. Let me give an example.

My boss and my grandmother

My boss is great. I never known a less agile person.
Some days ago he called me for a meeting, with 12 other developers. He told us that our Company had a Very Important And Complicated Task to deliver. He spent 5 minutes (5 minutes) talking about it. Naturally, since it was about a Very Complicated Workflow, involving Very Legacy Tools, we didn’t understand too much.

After the 5 minute overview, he told us: “I will ask each of us How Much Time We Will Need To Product The Thing. Naturally, I will calculate the average, and communicate it to Our Managers“.

Uhm, I thought. I could invite my grandmother, too. Since what’s important, here, is the number of people doing an estimation, not their knowledge of the problem, another person doing an estimation could be useful.

Do you think I’m too evil? I don’t think so. I’m a developer, my grandmother is not. But my knowledge about the problem is not that different. On the contrary: as a developer, I’m very biased; since I know nothing about the Very Legacy Tool, I might be tempted to base my estimation on my previous experience, which may be very different from what will be needed in this case. In the best case, my grandmother would have the courage to cry “Hey, I can’t reply! I know nothing about this, I can’t judge“.

Actually, that’s exactly what I replied. That, made my boss very upset. Yet, it was the truth.

The fact is: you can ask me for an estimation only if you give me the opportunity to study the problem.

Collecting 10, 50 or 100 people who know nothing about a problem doesn’t give you a better estimation. Even if you calculate the average.

Estimating means drawing the future from what’s known.

See Part II: 8 Practical Rules For Producing Decent Estimates

4 thoughts on “8 rules for being successful even when forced to use Waterfall (with a pretty good estimation)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s