The underlying forces that break agile estimation | Jesse Fewell The underlying forces that break agile estimation – Jesse Fewell

The underlying forces that break agile estimation

By April 10, 2013Blog, Uncategorized

In my last post, I highlighted some of the common problems around estimating the size of upcoming projects. Today, I’m going to think through WHY we are facing these problems.

Over the last several months, I’ve been thinking more and more that THE underlying principle in all of management and leadership is “balance”. From Ken Blanchard’s “situational leadership” to Greenleaf’s “Servant Leadership”, I’m seeing a pattern that all-or-nothing positions are at the root of the most dangerous and impactful decisions made at work. Instead, the more sustainable position is one that strikes a balance between a spectrum of opposing positions.

I know it sounds rather nebulous, but it sets the tone for why I believe the idea of “balance” helps us navigate the awkwardness around “self-organized estimation”. Whether we are asked the question of “when will this work be done” or “how much work can we get done by the deadline”, your preferred approach to estimation  will be driven by how much influence you give to the team, versus how much you give to the customer or sponsor.

First, we define the spectrum of two opposites we’re working with. For self-organization, the spectrum moves from the extreme left of anarchy to the extreme right of fascism.


High Anarchy (“Estimation is Waste”): Believe it or not, there are experts out there who say you shouldn’t have to estimate your work at all. “The work will get done, when it gets done”. Let’s say the business comes to ask you, “We have shareholders to manage and analysts to satisfy. Our Marketing department needs to know when to have their campaign done. So, how much will this new upgrade cost and when will it be done?”. The anarchist approach is to say “no sir, you are asking the wrong question. You should only focus on the product, and none of the business considerations that surround the product.”  As you can imagine, this is simply not defensible, and most likely will be a career limiting conversation.

High Fascism (“Do exactly this by exactly this time”): Stop me if you’ve heard this one before: the boss comes into the office and says, “you 5 people need to build the entire product exactly as defined in the giant binder of specifications by the end of the month. We can’t leave out any features, we can’t slip the date, and you go no extra help.”  This is the textbook definition of a death march; there is no chance of success.

The anarchist wants to avoid the death march. The fascist wants to avoid randomness and variability. Both are willing to take the extreme position to get what they want and avoid what they don’t want.

Now, let’s get to some of the problematic techniques we see in large scale project estimation.

(Mild Anarchy) Every team does it their own way: Here, we place the expectation on our project teams that they have to have some kind of answer to the business question. However, we want to preserve some degree of self-organization, so we allow them to self-organize in opposite directions. Which gets in the way of the getting the answer we need.

(Mild Fascism) Every team must do it the same way: Here, we simplify the problem by demanding consistency across the teams. If everyone uses Ideal Days, we can add all the data together rather easily, but we sacrifice a lot of the self-organizing dynamic and the goodness that comes with it. Not as bad as before, but also not ideal.


You can see where this is going. The further you move away from an extreme position, the more defensible you position becomes. Or more to the point of this specific conversation

The more you rely only on self-organization or only on expert judgement, the less reliable your projects will be

Business who issue top-down mandates on projects and deadlines lose the benefit of the reality-on-the-ground. On the other hand, those who won’t even attempt to forecast their outputs risk becoming irrelevant to the business world.  So I’m looking for a holistic approach to estimating large projects that balances these two forces. My next post will propose a general framework for doing exactly that.

Meanwhile, what do you think? What does a balanced approach look like? How can we get multiple teams on a large program to answer the question, in a way that is both reliable AND self-organizing?