Traditionally, the planning fallacy states that when an individual is estimating a task, which is similar to another task they did in the past, they tend to be optimistic and underestimate the effort required. It also states that whilst the effort is often understated the potential benefits are overstated.  Scale this up and the results are project over runs and benefits short falls.

Let’s set out to overcome the planning fallacy – lets simply not plan and that will make us Agile in the process!

Joking aside, some attempts at Agile delivery start out like this and tend to end badly for all involved. There is no stability, no predictably and ultimately no happy customer. After all, we are doing this to make a customer somewhere happy. We are not doing this to be a zealot.

Agile software development emerged from more structured approaches because many projects delivered this way failed, many because the plans were too big, too detailed and importantly, they lacked flexibility. Our customers want predictability in one form or another so what do we do? How do we overcome the Agile No Planning Fallacy?

In “Why Plans Fail: Cognitive Bias, Decision Making, and Your Business”, Jim Benson covers the following areas that can lead to the Planning Fallacy

  • Precision Bias
  • Discounting Variation
  • Best Case Scenarios and the Mythical Man Month
  • Overwork leads to Under-memorisation
  • Context Switching
  • Alleged Anomalies
  • Good Will / Rosy Retrospective Syndrome
  • Politics

I wanted to touch on a few of these

Precision bias, Discounting variation & Best case scenarios

This means assuming that estimates are precise and accurate and only considering the best-case scenario. As stated in the first paragraph an individual estimate is more likely to be too optimistic and it is personal so it doesn’t scale to another person let alone to members of other teams. We are often asked to estimate for best case scenarios. When have we ever had a situation where nothing goes wrong?

Context Switching

I’m unlikely to be convinced by someone that says that they are a good context switcher. In fact, I need to write that down because that is a blog post in itself…

20 mins has passed between that last sentence and this one. I started making a note for another post, then a notification went off on my phone, which I started to read and now I’m back here. What was I saying again?

Stop telling me you are good at context switching. You are just better at coping than others. That doesn’t mean context switching is good. Even if you are the best I don’t want you doing it. I want you to focus and get on with the task in hand. Just stop it.

Addressing the Planning Fallacy

There are a couple of other things that help to reduce the planning fallacy. The first is sizing relatively, but what does that mean? An absolute estimate might be 2 hrs or 3 days. Often when people hear these estimates they immediately starting thinking about the end of the effort rather than the effort itself. They might get into mythical month territory if they don’t like the sound of the end date. “3 days you say, so it will be done by the end of tomorrow if 3 of you work on it!”.

Relative sizing approaches this differently. Firstly, there is no time connotation. This aims to terminate the behaviour of trying to map the work to a calendar. The size of the work is only measured relative to each other. T-Shirt sizing is good for this and so is using a clear, none time related unit such as “baguettes”. “This piece of work is 2 baguettes but that one is 10 baguettes”. (Baguettes was really the unit we used on my first Agile project.) Time is not the only dimension removed from a relative effort. Relative estimates do not imply how the team will organise itself to deliver the work. A “large” is still a “large” if one or five people are doing the work.

The second is group estimating. This is eliminating some of the bias by depersonalising the process. In my experience, it often spurs debate means the work is sized for the more realised scenario rather than the best case. Not only is about discussing how to approach the work as a team and discussing alternatives – it demonstrates the wisdom of the crowds.

Planning works best when it is done little and often. It is a continuous process and not something you do at the start. Remember why you a planning. You are trying to understand what is the next most important thing and understand what your team can do in the next increment. Relative sizing and evidence of the rate at which the team works is enough to do that. Using Ideal days gives the team the flexibility to deal with variations and anomalies and the capacity to do value added activities when things are going well.

Planning is not about precision nor it is able create something that can be executed without thinking. It is not about “no planning” – instead it is about “smart planning”.


One thought on “No planning fallacy – Agile Anti Patterns

  1. All good stuff. But each is a “symptom,” fixed by identifying it’a root cause and removing that root cause. The plethora of books and papers are available for correcting each Bias


Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s