«    »

Comparing Agile and Traditional Project Management

I just attended a great presentation about Agile project management by Mike Cottmeyer at Agile Edmonton's monthly meeting. What stood out for me were two comparisons Mike made between Agile project management and traditional approaches (e.g. waterfall project, PMI/PMP).

Dealing with Uncertainty

Mike characterized traditional approaches as trying to manage out uncertainty in the effort to achieve predictable results. This strategy essentially involves determining up front the key aspects of the project (scope, budget, and schedule) and then seeking to minimize changes to it throughout the project. Unfortunately, virtually all software development is faced with a multitude of uncertainties. Trying to drive them out means conflicting with reality, which leads to a common litany of project problems such as: over budget, over schedule, scope achieved but business not satisfied (business objectives not met), and excessive cost for realized value.

Agile adopts the opposite philosophy: manage for uncertainty. Kent Beck used the term "embrace change" when first introducing Extreme Programming, and this is a common goal of all Agile methods. This is achieved through several strategies:

  • Requirements are defined and implemented throughout the project, making it trivial to accommodate changes. The next section below discusses this in more detail.
  • Providing frequent feedback via working software mitigates many of the risks of traditional development projects.
  • Prioritizing user stories and first implementing the ones with the highest value / highest risk maximizes the return on investment and mitigates a number of common risks.
  • Often Agile projects explicitly allow for the project to be stopped or brought to a close at any point if the business owner determines that there is no benefit in proceeding with the remaining requirements.

One of Mike's though-provoking points was that using an Agile method is a risk-mitigation strategy that mitigates many of the common risks associated with software development projects.

Deriving instead of Fixing Scope

One key aspect of project management is managing the iron triangle of scope, cost (budget), and time (schedule). In a traditional waterfall project the scope is defined first, the effort required to implement this scope is then estimated, and finally the budget and time required are derived from this estimate. This approach is maintained throughout the project: controls are often put in place to minimize changes to the scope and changes that are deemed necessary then typically require adjustments to the budget and/or schedule.

Fixing the scope up front is inherently flawed due to the nature of software development:

  • Business requirements almost always change over time. I have seen statistics mentioned on the order of 1% change in requirements per month.
  • Software development is inherently a learning activity. The business typically gains clarity about their requirements as they are analyzed and implemented. Insight is also gained into how the solution / system can best meet these requirements.
  • One technique from lean software development is set-based concurrent engineering, which aims to defer decisions to the last possible moment when the most information is available. This helps ensure that the best possible decision is made and hence minimizes waste caused by bad decisions (one of the main objectives of lean). Fixing scope up front requires making decisions at the worst possible time – when the least is known.

Agile addresses this problem by making scope flexible. While an Agile project can (and usually does) start with a high-level backlog of features or epics, the specific user stories selected for implementation are determined throughout the project, iteration by iteration. I have heard some say that Agile makes the project scope easy to change, but in reality the scope is not being changed at all – it is being defined throughout the project. The total scope achieved in a project is hence a function of the project schedule: the more iterations and releases available, the more that can be done. Going back to the triangle of scope, cost, and time, this means that time is the main variable being controlled, from which budget and scope can be derived.


I really enjoyed the clarity of thinking Mike brought to the topic of Agile project management. Considering that Mike has given this presentation at major software development conferences that require $$$ to attend, I really appreciated having the opportunity to see it for free in my home town. I am a little surprised that there are not more people taking advantage of these opportunities. If you live in the Edmonton area I strongly encourage you to attend the Agile Edmonton meetings.

If you find this article helpful, please make a donation.

3 Comments on “Comparing Agile and Traditional Project Management”

  1. Glad you enjoyed the presentation Basil. I’ve heard lots of good feedback about Mike’s presentation and it certainly validates the work that we put in to bring him here.

    While bringing in guys like Mike helps to increase our attendance numbers, what we’re really aiming for is the creation of an Agile community here in Edmonton. To do that, we need to get local speakers. That’s why I’m really looking forward to your presentation in January!

  2. Please no more “comparison” articles. The market has moved so far beyond this type of comparison it is like people saying, “Web 2.0 is important”. Of course it is important! but what NEW thing do you have to say about it?

    I am sorry to be so blunt but I am just tired of all of the comparison articles. There are enough of them. If someone wants to read and understand the difference between one and the other they have AMPLE articles to read. Please don’t add to the noise. Make some new thoughts, some new ideas, push the boundaries. This code is working, it doesn’t need more tweaking, it is good enough. ;-)

    Oh BTW I am a Scrum Master have been doing scrum only projects for several years and am an agile coach. I am just ready for some fresh thinking.

  3. Brian says:

    Great article Basil! – I found the summary quite useful.

«    »