As we all know, there are two general approaches or methodologies used for projects: Waterfall and Agile. Before I continue with an explanation of the differences between those two, let me emphasize one major and the biggest difference there is: The PLAN!
Waterfall methodologies are plan driven. Everything is—or should be—known upfront. With a Waterfall project, the scope (what should be done), the time plan/schedule (when each activity will be done), the human resource plan (who should work on what and when), and the costs (how much each activity will cost) should be well defined before the project begins. As we all know, when it comes to IT projects, Waterfall methodology is not suitable. With this approach, a lot of change requests (changes to scope, time, and costs) arise, and there is always a problem with extending those three. This is Waterfall:
Agile methodologies, on the other hand, follow more of a “plan as you go” model. There may be NO strong and fixed plan defined upfront. In fact, just the opposite is true. Plans are made for a short time period (up to one month), and only some parts of the project are planned at all (for that short time period). After that, the customer (or person who is the beneficiary of the project) can see what has been done, is it OK or not, and according to their judgement, can make further decisions on what is going to be done in the next (short) time period. Yes, Agile is better for IT projects. There is no question about that.
This is Agile (Scrum to be more precise, as one of the most known methodologies within Agile project management):
The major differences between Waterfall and Agile methodologies are listed below:
waterfall methods” width=”850″ height=”461″ />
The limitations and advantages of both are shown in next figure:
As usual, it is “Always – BUT!” For the sake of this comparison, we see that is very true. Sometimes (or very often) it is hard to run a project only with Agile. Here are some examples of Agile challenges:
- The customer wants to know upfront what will result when the project is finished. In this case, requirements should be defined in the earliest stages of the project, which is likely impossible.
- The customer wants to know the budget. Funding must be prepared upfront, and to get that funding, one must know the scope!
- The customer wants to know the deadline (i.e. when the project will be finished).
These challenges are also known as triple constraint, or the “iron triangle,” as shown below:
With only Agile or Waterfall to choose from, what is a project manager to do? The answer is a hybrid model, also known as “Water-Agile-Fall.” Here is a picture, which explains this type of methodology:
Basically, it is Agile inside of Waterfall. How does it work? Remember, Waterfall is outside and Agile is inside.
Let’s suppose that we have a fixed scope, fixed time, and fixed price IT project. Contracts should be signed according to statement of work, WBS, and schedule. All requirements are collected and estimations are done at the very beginning. After that, when the execution of the project has begun (i.e. the design and development phase), the project functions with Agile methodology. We can organize Sprints (Scrum), Kanban Board (Kanban), or something else. The greatest benefit of this hybrid approach is that we can show and deliver as we go, and the customer will be aware of what is he is really getting. This is a much better scenario than one “big bang” delivery. In a classic Waterfall approach, customers get everything at once at the end of the project, and there is a 50/50 chance of satisfaction with the solution. More realistically, the 50% chance that our customer will not be satisfied is actually a 99% chance. Why? Because he hasn’t seen anything until the project’s end. By then, it is too late to change things.
With a hybrid model, the customer has multiple opportunities to see and react during development in short time periods. He can change his mind or add something new. With this approach, it is much easier to reach agreement that something is out-of-scope because it has already been defined. We have the option to get more funding and/or time. Best of all, we have a good chance of there being a successful trade-off (i.e. the customer will give up of some previous defined and desired functionalities in favor of some new ones, which many have not been considered or defined in the original plan).
In summary, my recommendations are as follows:
- Use Agile whenever you can. This is the best approach!
- If you can’t go Agile all the way, do not go Waterfall as the only other option. Instead, go with a hybrid “Water-Agile-Fall” method. You’ll be able to take the best from both methodologies, and with frequent delivery, you will have your customer on your side from the very beginning, throughout, and until the end of the project!
Sonya Calef
Isn’t this just reality? In my 20+ years of managing IT projects, I’ve never, ever, not even one time had a waterfall project (purely finish-to-start task dependencies). There has never been the luxury of sequencing work that way. The idea would get me laughed out of the office. Maybe the odd bit here or there for infrastructure builds, or solicitation/purchasing due to internal rules, but definitely not the project as a whole.
Everything has to be overlapped and exceptionally iterative or cyclical out of necessity whether it’s called Agile, RAD, RUP, Progressive Elaboration, or any of the other iterative methods. I’ve never met anyone who ran a waterfall IT project since the dawn of e-commerce. Not since my dad retired from Pascal, Cobol, & Fortran programming in the mid-1980s anyway.
PMI has never taught or published direction to run a waterfall (Finish-to-Start) project. Quite the opposite. The scheduling standard expressly teaches to find overlaps, efficiencies, and ways to reduce the end to end duration. Anybody out there who is running in waterfall-only mode must have a really good reason (that I’d love to hear).
Phil Planner
Everything is—or should be—known upfront. With a Waterfall project, the scope (what should be done), the time plan/schedule (when each activity will be done), the human resource plan (who should work on what and when), and the costs (how much each activity will cost) should be well defined before the project begins.
I will be generous and say this is a poorly drafted explanation rather than a misunderstanding. A waterfall model commonly starts with analysis / requirements gathering. No PM could ever schedule the detail design without having the requirements, nor schedule the development without the detail design, nor schedule the deployment without the development (mostly) complete etc. etc.
Nenad Trajkovski
Daryl,
my article is not meant to be like: “Waterfall is all wrong”. but in my experience almost always in my projects I have to know scope upfront. And this is the hardest thing. Because (I’m talking about IT SW projects), customer knows what he wants AFTER he gets what he said he wants (in Specification). And then, we are facing the problem. If you didn’t get what you wanted who will pay for what we have delivered, and who will pay for the change.
Amr Miqdadi
Dear Nenad,
Thank you so much for this great article. I totally agree with your hybrid approach, especially that we adapted it recently in one of our software development projects. I was struggling with how to explain this concept to our top level management but you put it in a very clear and nice way.
In project management as I learned there is no clear wrong or right but there is bad, good, and the best approach. So I do adapt the approach that serves my project the best whether it is agile, waterfall or as you said Water-Agile-Fall.