I’ve written several articles on the subject of why the comparison of “Agile versus Waterfall” that is so widely used is so inaccurate and misleading. A better way to view it is to think of adaptive versus plan-driven project management. Check it out here:
There’s a lot of reasons why that comparison isn’t very meaningful and can be misleading – What is Agile? What is Waterfall? What are you comparing to what? Is it really a meaningful comparison? (I don’t think so)
A much more objective and meaningful way of comparing different methodologies is needed and I think the comparison of “Adaptive” versus “Plan-driven” is much better-suited for that purpose. Here’s how those terms are defined:
- Plan-driven – “Plan-driven software development is a more formal specific approach to creating an application. Plan-driven methodologies all incorporate: repeatability and predictability, a defined incremental process, extensive documentation, up-front system architecture, detailed plans, process monitoring, controlling and education, risk management, verification and validation” (Source: http://en.wikiversity.org/wiki/Plan-driven_software_development
- Adaptive – An “Adaptive” approach, on the other hand is characterized by having a less well-defined plan that is more adaptable to fit the situation as the project progresses. It’s more of a rolling-wave planning approach where the plan evolves as the project evolves.
This is not a binary, all-or-nothing choice between 100% plan-driven and 100% adaptive:
- You don’t typically find many situations that have an absolutely rigid plan down to the smallest detail that is not subject to any kind of change and
- You don’t typically find situations that are totally unplanned where you just start doing something without any kind of plan and make up the plan as you go.
Most situations lie somewhere between those two extremes – there is a continuum of different approaches from a heavily plan-driven approach at one extreme and a heavily adaptive approach at the other extreme with lots of alternatives in the middle. If you were to plot different approaches on this continuum, here’s a sketch of what it might look this:
Here’s some notes on this diagram:
- This is not meant to be an exhaustive and comprehensive diagram – it is simply an illustration showing a few examples
- Each of these methodologies can be used in a range of situations – for example, Scrum can be used in a range of situations that have varying levels of adaptivity; however, it would be difficult to make Scrum work in a heavily plan-driven approach
- However, by putting a plan-driven “wrapper” around Scrum, you can create a hybrid approach that provides a plan-driven shell at the project level but retains most of the flexibility of Scrum at the team level
- Kanban is generally more adaptive than Scrum because it is typically used in more reactive situations that are less planned (like a customer service process)
There is no “good” and “bad” judgment in characterizing a methodology as “adaptive” or “plan-driven”. Neither an adaptive methodology or a plan-driven methodology is inherently good or bad just because it is adaptive or plan-driven. The problem comes up when they are misused – for example, when you try to use a heavily plan-driven methodology like Waterfall for a situation that has a lot of uncertainty in it and calls for a more adaptive approach.
Why is this important? The traditional comparison of “Agile versus Waterfall” is almost meaningless and very misleading. It frequently is used judgmentally that “Waterfall” is bad and “Agile is good. That leads people to think of those two approaches as binary, mutually-exclusive choices; and, as a result, people many times tend to force-fit a project to one of those extremes. A much better approach, in my opinion, is to view these approaches from a more objective perspective and fit the approach to the nature of the problem based on the characteristics of the methodology and the problem.