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.
4 comments:
>that the particular scope will be completed 2 years from today
If you can run a "traditional planned project" that can hit a specific date 2 years out then you don't need agile/lean approaches.
As for the rest of us mortals, we need a more achievable approach.
In some ways the agile/lean approach is just being honest when we say we don't know exactly when we will be done because we don't know everything and you are likely to change your mind along the way.
In the space and defense business long term usually means 5 to 10 years. This is a similar problem found in agile or lean (what ever lean means for the project management aspects). The offical as well as successful approach is a "Planning Package."
The Planning Package contains a description of the work to be done in the future to some degree of granularity or fidelity. This granularity is usually at a higher level (possibly a much higher level) than th current Rolling Wave. The PP contains an estimated budget, estimated outcomes, and some form of dependencies between PP's and the Work Packages in the current Rolling Wave.
Wayne may be suprised that Mars spacecraft can hit a few week's window 5 years out, with emerging requirements, changing funding and lots of inventive new phsysics, software and hardware. This is the role of "event based planning," programmatic risk management, iterative and incremental development along with continuous testing.
Maybe it helps to treat the business request for estimates and planning like a requirement (or user story) like anything else. There's a tension between what they want (pinpoint accuracy) and what we can deliver, especially early on a major project.
What we can provide, and what the business needs, is decision support. Should they do this project, or that one? What constraints are hard (Mars launch window, annual trade show, regulatory requirements) and what are softer? What does the ensemble of technical and team options look like?
Early estimates don't have to be accurate (in the sense of low variance) to be useful for decision support. Good executives deal with uncertainty all the time. We just need to help them quantify it.
Great insights Robert, thanks!
Post a Comment