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:

1. 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.
2. The customer wants to know the budget. Funding must be prepared upfront, and to get that funding, one must know the scope!
3. 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:

1. Use Agile whenever you can. This is the best approach!
2. 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!