Several leaders in their fields have been giving a great deal of thought lately to the state of planning and estimation, and how it relates to agile and lean projects.
Alistair Cockburn said:
The purpose of planning to be able to answer the question “With what we NOW know, what will the most useful system we can create look like on THAT date?”
Glen Alleman said:
The primary function of project management is to ensure that the project is implemented to meet the established budget, schedule, safety, and performance requirements to satisfy its objectives.
Corey Ladas said:
When we agree to take on a work request, we intend to deliver it within n days
There seems to be a general idea that the concepts of Lean can be applied very well to the process of software development, but it leaves unanswered the question of how to plan a long term project.
Agile and Lean both take the view that we will apply some fixed team size to the software, and we will deliver as fast as possible, and allow as much flexibility as possible to the client’s ability to adjust the course (scope) of the project. This is undeniably the current most efficient way to produce software, but that does not mean that it is always the right choice.
The core of the problem is that detailed estimation is a wasteful effort – it does not add business value. So we can deliver more efficiently if we do not estimate. But we have to balance that against the requirements of the business, which has some objective that they are hoping to meet by some date. As the implementors of the solution, we are obligated to be able to tell the business the “when” of the delivery, and they are obligated to tell us the “what”. Unfortunately, the exact “what” always changes. So even if we estimate the “when”, we can very easily be wrong. Its a vicious circle.
In theory, Agile handles long term estimation better than Lean. This is because teams can estimate backlogs at a high level, months (but not years) in advance. Lean is very “just-in-time”, so it can only answer the question at the last instant. The best “lean” answer so far is that we can offer smaller commitments to minimal marketable features. That is, basically what the quote (above) is from Corey.
Neither Lean nor Agile answers the problem of the longer term, more complex project with multiple groups and critical paths and a well-defined scope. The scope is the primary problem – Lean and Agile will deliver faster, but they are not willing to tell the client what he wants to hear – that the particular scope will be completed 2 years from today. They can still give some very attractive answers though – Alistair Cockburn has a list on his wiki.
My conclusion? There is no question in my mind that traditional planned projects are suboptimal, but for now, they are still appropriate for many situations. First though, I would try to sell the client on one of the approaches from Alistair’s list – if they are willing to define what they want in a way that is compatible with Agile or Lean, then we can give them the result for much cheaper, or (more often) a better result for the same price.
