Agile for PMs – are #noestimates really possible?

The “Agile for PMs” articles are written for experienced project managers who are interested in exploring how Agile development differs from classical project management.
In these articles, “Agile” is generally capitalised (and sometimes used as shorthand for “Agile development). The Agile Manifesto is described in more detail in other Plays on this site.

Can we avoid estimation entirely? It’s a topic which gets lively debate. To many people with a classical project management viewpoint, this seems like madness. To some agile developers, spending considerable time estimating and re-estimating, it may seem like heaven.

Where does the reality lie? I spent years leading classical program management teams before moving to leading agile development teams. I understand how this clashes with project management thinking. But maybe this isn’t as crazy as it looks.

Projects

Firstly let’s think about projects. As project managers can mostly recite (yes, I have my PMP), the Project Management Institute defines a project as:

A project is a temporary endeavor undertaken to create a unique product, service or result.  A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.

The Project Management Institute

However, this doesn’t apply to most software (product) development. There is no single key goal and no fixed scope end point.  More typically, there are fixed schedule points (releases, program increments etc). This is working within what is known as timeboxes – fixed periods of time. Software development has high levels of uncertainty. These are managed by adjusting the scope delivered in the timebox.

Lean

Lean thinking underpins a lot of Agile approaches. In Lean, any items which do not directly generate customer value are considered “waste” (muda).  Now this can be a misunderstood term. In Lean, waste should always be challenged and minimised. However, it may still prove to be necessary (at least at the present). There’s a famous example:

All planning, in this definition, is “waste”.  I know that may sound crazy, even insulting to project managers, but stick with this. It just means that the customer doesn’t directly use the plans. It doesn’t mean planning is pointless. We can’t make bananas without skins. It means that we should challenge how much we spend on it.

What is #noestimates?

#noestimates is intended to challenge the balance between time spent on planning and time spent on creating value. Do we have that balance right, or are we spending more time than needed on planning? If we rethought some fundamental ideas could we gain more time for creating value?

If we needed to have a precise prediction of the next release we would need a detailed plan. But do we need that precision? And is it even achievable? In complex environments, it’s been shown over and over that detailed planning does not hugely improve predictability because of emergent learning.

• Maybe we could work from an ordered list or backlog and create the key items first. 
• Maybe we could limit our commitments for the release and maintain a buffer.

The purpose of estimation is to balance the level of risk and commitment.  This guides the amount of investment you will need in estimation

The more flexibility we build in to the commitments, the less we need to invest in detailed planning.  At the limit, if we committed to nothing (effectively a 100% buffer) we would do the least planning and so maximise our effort for delivery. Alternatively if we broke down all the work to the next release into equal “rightsized” items we wouldn’t need to estimate item sizes.

How achievable are #noestimates?

Do I believe having completely no estimates is achievable? It seems unlikely to me that we can make no commitments. And rightsizing all the work for a release feels like classical “upfront” planning. It ignores the complex nature of agile work.

But I do see #noestimates as a valuable challenge to the way we think. It’s similar to #zerodefects which was a key way of thinking in my semiconductor days.

What I have found is that #noestimates has pushed me to avoid over-planning. Keep software planning at the “art of the possible” level.  Keep commitments low, do just enough planning to be confident in those, and then use the extra time in delivering as much more value as you can.

With an ordered backlog, the further down the backlog you go, the more uncertainty you introduce.  Future work is less well defined and more subject to change. 

The more you are able to deliver continuously and frequently, the less you will need to rely on estimation.  The more that you commit to what will be in a timebox, the more work must go into estimation to achieve that target and the less agile you are likely to become.