I often see questions on “How do you choose between Agile and Waterfall?”
Is There a Binary and Mutually-Exclusive Choice?
The typical Agile versus Waterfall question implies that those two are discrete and well-defined alternatives and there is a binary and mutually-exclusive choice between the two. It also implies that there is one “best” methodology for all projects and it is limited to those two choices. That is a popular misconception and stereotype and it sometimes results in people force-fitting a project to one of those extremes.
Traditional Plan-driven Approach (“Waterfall”)
What many people call “Waterfall” is not really a discrete and well-defined methodology and it is not necessarily the rigid, phase-driven approach that was documented by Dr. Winston Royce in the 1970’s. What people generally really mean when they say “Waterfall” is any traditional, plan-driven approach that is not Agile. Some project managers will try to use a traditional plan-driven approach for almost any project:
- It may be the only project management approach that they know.
- It has also been widely-accepted as the only way to do project management
On the other side of the spectrum, many people in the Agile community think that Agile/Scrum is the best solution to any problem you might have and they are very passionate and zealous about that. There has been a lot of polarization between these two different factions to the extent that it has almost become a religious war. It’s time to get past that and see these alternatives in a fresh new perspective as complementary to each other rather than competitive.
Fit the Methodology to the Project
The key to this new perspective is to recognize that these two approaches are not mutually-exclusive and it is possible to blend the right amount of the two different approaches in the right proportions to get the best of both worlds. In many situations, rather than force-fitting a project to one of these extremes, the “best” approach is to go in the other direction and fit the methodology to the nature of the project.
- That takes more skill but it definitely can be done
- You should also recognize that there is not a binary and mutually-exclusive choice between “Agile” and “Waterfall”
- There is a whole spectrum of different approaches ranging from heavily plan-driven at one extreme to heavily adaptive (or Agile) at the other extreme
Factors to Consider
There are a number of factors that influence the selection of the best approach for a particular project:
1. Level of Uncertainty
First and probably the most significant factor in choosing an approach, is the level of uncertainty in the project. A project with a high level of uncertainty would be best-suited for a more adaptive (Agile) approach. Attempting to force-fit such a project to a traditional plan-driven project management approach could be disastrous.
- It would force you to make a lot of assumptions to try to resolve the uncertainty; and, in many cases, those assumptions may be wrong and require a lot of re-planning and possible re-work
- The emphasis on planning and control in a traditional plan-driven project is not conducive to changes. That will make it difficult to maximize the value of the solution in an uncertain environment
2. Need for Creativity and Innovation
Next, in today’s competitive environment, creativity and innovation can be very important to create very competitive business solutions. An approach with a heavy emphasis on planning and control can stifle creativity and innovation.
3. Customer Relationship
Finally, managing customer expectations is probably one of the most critical aspects of any project. If the results of a project are not consistent with customer expectations, the project will likely not be viewed as successful no matter how good you think it is. The nature of the customer relationship can range between:
Contractual Style of Relationship
A contractual style of relationship is where there are very definite and well-defined customer expectations that must be met. In this type of relationship, the customer may not take any responsibility for the success of the project. The customer defines requirements and expects the project team to do whatever is necessary to meet those requirements. In this style of relationship, there is limited participation by the customer in the project
Naturally, the contractual style of relationship is well-suited to a project with a relatively low level of uncertainty. It must be possible to define the customer’s requirements in some level of detail prior to the start of the project. It would be much more difficult to make a contractual-style relationship work in a project with a high level of uncertainty.
Collaborative Style of Relationship
A collaborative style of relationship is where there is a shared responsibility for the success of the project. In this environment both the project team and the customer take an active role in defining the direction of the project as it is in progress
What’s the Right Style of Relationship?
Of course, the customer has to be amenable to whatever type of relationship you choose. If the project has a high level of uncertainty, that would lean towards more of a collaborative relationship; however:
- The customer has to be open to that kind of relationship for it to be successful.
- This is a big problem in many companies where it is difficult to break down organizational boundaries between organizations
- It requires establishing truly collaborative relationships based on a spirit of shared responsibility, trust, and partnership.
4. Project Team Capabilities
The final major factor in selecting a project approach is, of course, the capabilities of the project team.
- An Agile approach requires a lot of training and skill and a hybrid Agile approach can require even more training and skill.
- Naturally, it does not make any sense to choose an approach that the team is not capable of implementing.
Why Is Choosing the Best Methodology for a Project Important?
There are two major factors that require us to broaden the way we think about “project management” today:
- Solutions tend to be much more complex and the level of uncertainty is much higher
- Competitive pressures frequently require much higher levels of creativity and innovation
For those reasons, force-fitting all projects to a standardized plan-driven approach is not necessarily the best approach for all projects.
Choosing the best methodology for a project can be a difficult thing to do. It is not necessarily a simple matter of choosing Agile or Waterfall. You have to fit the methodology to the nature of the project and to the business environment:
A project should be focused on producing value for the customer and its very important to understand what “value” means to the customer:
- First of all, meeting cost and schedule goals is only one component of value, and it may not be the most important component of value to the customer
- Second, there have been many projects that have met their cost and schedule goals but failed to deliver an acceptable level of business value
- Finally, “Value” can be a very elusive goal but, in any case, it’s what the customer thinks that “value” is that counts
There is no “best” process. Saying that “Agile is better than Waterfall” is like saying “A car is better than a boat”. Both have advantages and disadvantages depending on the environment you’re in:
When Does an Agile Approach Work Best?
When does an Agile approach work best? An Agile model tends to work best in projects where:
- There is a relatively high level of uncertainty and a flexible and adaptive approach is needed to resolve the uncertainty as the project is in progress
- Creativity and innovation are needed to maximize the business value of the solution
When Does a Plan-driven Approach Work Best?
When does a plan-driven approach work best? A traditional plan-driven model (what many people loosely call “Waterfall”) tends to work best where:
- There is a relatively low level of uncertainty, the solution is well-defined, and some level of planning and control are needed to maximize predictability of costs and schedules
- The organization is not really well-prepared to implement an Agile approach and/or the project team is not trained in Agile
You can find related articles on the topic of “Choosing the Right Approach” here:
You will find much more detail on this in my Online Agile Project Management Training.