10 Questions that will help you choosing between Agile and Waterfall

How did you decide between Agile and Waterfall in your latest project? Did you choose Waterfall, simply because you are used to it? Or did you pick Scrum because your management told you that all projects must be Agile as of now? This blog will provide you with ten simple questions that will allow you to make an objective decision between Agile, Waterfall or Change driven projects. The answers will also help you explain your choice to your management.

Because you started reading this article, I will simply assume that you, at times, hesitate between Agile and Waterfall.

Let me share you one insight already: the choice between Agile and Waterfall (or change driven) project management is not binary. There are many shades of grey between building an app in an Agile track, and building a bridge the Waterfall way. The grey zone adds to the discussions between believers and non-believers of either project management methodology. And once you have chosen a project management track, it is difficult to simply change to another (see also the Chagwa theory below). Therefore, the decision on how to manage a project must be right from the start. The following ten questions should help you making a decision.

To get the most out of the questions, think of the next project you want to manage and then note a ‘yes’ or ‘no’ for each. It’s as easy as that.

Question 1: If your project does not deliver the full product or result in the agreed time period, will your customer remind you of the signed contract and hold you legally accountable?

Question 2: Are all tasks in the project standard changes that don’t require additional engineering?

Question 3: Is there high interaction needed with the end users on all tasks, e.g. for decision making or verification that the delivered result is as expected by them?

Question 4: Can the project be done by a small and experienced team?

Question 5: Will the time and cost of requesting a budget and doing the paperwork for creating the project, be in the order of (or even more) than actually doing the project?

Question 6: Can the project deliver its results in at least five chunks of about equal size? You can also answer yes to this question if you would be able to deliver the Product in multiple releases, but decide to only bring the final Product to the market for quality reasons.

Question 7: Is additional upfront research or engineering needed in the project?

Question 8: Can you rely on a person who has full knowledge of the Product that the project will work upon, and who will be fully available for the project?

Question 9: Does more than 95% of the work load in the project comply with the INVEST Principle? I.e. are the tasks Independent of each other? Can a task still be changed after Negotiating the details with the customer to provide more Value? Can the time needed to execute a task be Estimated by the team upfront and will the tasks be Small enough to be executed in a short time frame? And finally, can all tasks be independently Tested and completed? Only answer yes if you have a yes for all questions!

Question 10: Give a number from 1 to 5 where 1 means that the project is highly risk-averse, and 5 means that you are allowed to take risks and the project is allowed to (partly) fail.

Before you count your scores, be aware that I don’t just distinguish between Agile and Waterfall project management. There is a third way of doing project management, called Change Driven project management. You can also call it “change request baby-sitting”. I will touch change driven project management in a later blog, but in a nutshell, it comes down to guarding a series of standard change requests and making sure they are done in the right order.

The next step involves rocket-science mathematics, and you may want to call your math professor to help you out. You know what I am talking about: additions and multiplications. Dependent on your answer you need to add a value to one of the three possible ways of running a project: Change, Agile or Waterfall.

Question 1: Are you bound to a fixed time and scope contract?

·        If you answered ‘yes’ to this question, add +5 to Waterfall.

·        If you answered ‘no’ to this question, add +2 to Change and +1 to Agile.

Question 2: Are all tasks standard change requests?

·        If you answered ‘yes’ to this question, add +3 to Change.

·        If you answered ‘no’ to this question, add +2 to both Agile and Waterfall.

Question 3: High interaction needed with End Users.

·        If you answered ‘yes’ to this question, add +2 to Agile.

·        If you answered ‘no’ to this question, add +1 to Waterfall.

Question 4: The project team is small and experienced.

·        If you answered ‘yes’ to this question, add +2 to Agile.

·        If you answered ‘no’ to this question, add +2 to Waterfall.

Question 5: Project paperwork large when compared to project work.

·        If you answered ‘yes’ to this question, add +3 to Change and +1 to Agile.

·        If you answered ‘no’ to this question, add +1 to Waterfall.

Question 6: Can the project be delivered in chunks?

·        If you answered ‘yes’ to this question, add +2 to Agile.

·        If you answered ‘no’ to this question, add +3 to Waterfall.

Question 7: Is additional research needed in the project?

·        If you answered ‘yes’ to this question, add +4 for Agile, and +5 for Waterfall. If the research will be used to make final decisions on continuing the project, add another +2 for Waterfall

·        If you answered ‘no’ to this question, add +2 to Change.

Question 8: The project can rely on the availability of a Product Owner.

·        If you answered ‘yes’ to this question, add +3 to Agile.

·        If you answered ‘no’ to this question, add +1 to Change and +2 to Waterfall.

Question 9: The tasks in the project comply with the INVEST principle.

·        If you answered ‘yes’ to this question, add +2 to Change and +2 to Agile.

·        If you answered ‘no’ to this question, add +3 to Waterfall and subtract 3 from Change.

Question 10: The project is risk-averse (x=1) to risk-accepting (x=5)

·        Add (x-1) to Change

·        Add x/2 to Agile

·        Add (5-x) to Waterfall

You now have three scores for either Change, Agile or Waterfall driven project management. If you are lucky, one method pops out clearly and you have hard evidence for the project management method to choose. In most cases, however, the numbers are a bit fuzzy and some more discussion may be needed. But even in these cases, the questions should help you in making a well thought through decision.

If you want to learn more about the reasoning behind the scores (or if you want to add to the discussion), feel free to read on.

 Justification of the scores

Question 1: Are you bound to a fixed time and scope contract? If you have a tight contract with your customer, start thinking Waterfall. Consider Waterfall too if you have tight demands on legal or documentation requirements.

By nature, Agile projects are strong on timing (fixed sprint time) and costs (the team is known), but the scope is gradually developed. Agile is therefore a good approach if you can develop the project from ‘need to have’ to ‘nice to have’ where the project sponsor is allowed to stop the project even before the ‘nice to have’ is delivered. This conflicts with hard targets on scope and timing. Only go this route if you have high experience on similar projects.

True, also in Agile projects it is possible to provide initial estimates on the project, and techniques exist to scale up Agile Teams if the velocity needs to be increased. Yet, fixed time and scope contracts require hard deadlines that may need to be studied upfront. Guarantees must exist on costs and milestones. Waterfall just better matches these demands.

Question 2: Are all tasks standard change requests? Both Agile and Waterfall project management methodologies assume that new development or engineering must be done. But, what if the tasks in the project are all standard changes? What if the project is simply a series of smaller tasks that can be executed independent of each other? It would be a waste of energy and resources to pour that into a Waterfall project.

The easiest would be to have a project lead follow up on the Change Requests in a Change driven project and e.g. use a Kanban board for guarding Work In Progress (WIP). If timing is of an essence, an Agile project can be initiated to guard the velocity in the project.

Question 3: High interaction needed with End Users. A Waterfall project demands that most of the requirements are known and fixed before starting a design. High interaction with End Users will probably result in regular changes in the requirements, design or project approach.

An Agile project approach can cover for constant changes in scope, e.g. because End Users are expected to constantly add requirements when the Product grows. A Change Driven project can be used if the tasks are known and small (e.g. replacement of all telephone sets in the offices), but when planning the changes requires high interaction with End Users.

Be wary that not one single project management methodology can protect you from highly undecisive customers who are constantly changing vision. If the customer cannot clearly describe what the project must deliver, it is probably better to not start a project at all.

Question 4: The project team is small and experienced. A need for training of project resources, or a need to do upfront research to better understand the Product, already indicates that a Waterfall approach is the best approach. The same applies if the project is large and involves many different teams with different skill sets.

Agile offers scrum of scrums for managing larger projects (e.g. writing a large software package), but that works best if all teams are experienced and tasks are similar in nature. Even then, Agile tends to break up the teams in smaller groups of 5 to 9 people. Small projects executed by experienced teams will profit from handling the project in an Agile or Change driven fashion.

Question 5: Project paperwork large when compared to project work. Let’s face it: we all want to avoid the red tape for creating a new project if the project is just a tiny bit of work. The risk here lies in the interpretation of ‘tiny bit’, but the project may result in a limited set of change requests for which a Change Driven project is sufficient. The time you lose by chopping up the project in individual change requests, is probably gained back by the fact you do not need to go through the cycle for creating a new project. The project documentation is then limited to the evidence that is kept in the Change Requests.

Question 6: Can the project be delivered in chunks? The number of five is chosen arbitrarily here, it could be three, it could be twenty. The essence is that Agile and Change drive project need to be able to deliver value in a rolling wave.

If your project has one single big-bang Go-Live, you will undoubtedly need/want to test the Product thoroughly after development completes and before the Go-Live. Well, if something looks like an apple, smells like an apple and tastes like an apple, it’s an apple. If a project has a single go-live, preceded by a final test, preceded by development, it is called a Waterfall project.

Some discussion may exist on the need for having all requirements fixed before the project starts. As a rule of thumb, Waterfall projects should have 90% or more of the requirements cleared out when starting the project. If assessing requirements and User Story development go hand-in-hand, you may still consider Agile techniques. Even then, be aware that a single go-live will result in late customer feedback which in turn questions why you would want to run the project in an Agile way.

Question 7: Additional research needed in the project. If additional research is needed in the project, the assumption is that no standard processes exist to do the work. This takes Change Driven project management off the hook. In opposition, if all work to be done is based on standard procedures, it is tempting to execute the project as a series of change requests.

Waterfall driven project management is graded a bit higher than Agile for this question, because it has a clear upfront analysis/research cycle in the beginning of the project. It will allow you to estimate costs in case the project is stopped. This is even more the case if the research will decide on the future of the project, e.g. in the format of a pilot run or a mockup build.

If less research is needed, and you can directly go into development, consider using Agile. You can also consider Agile if you have high confidence that the project will succeed and development can continue while the pilot run is prepared and executed.

Question 8: The project can rely on the availability of a Product Owner. This question goes back to roles and responsibilities for executing a project. In Waterfall, the Project Manager is responsible that the project delivers within time, cost and scope, in alignment with the project steering committee.

In Change driven projects the Operations (or DevOps) organization is ultimately responsible for executing the tasks. Since this is done through standard change requests, procedures for approval and execution already exist and there is little involvement of the Product Owner.

In Agile projects it is the Agile Project (Scrum) Team that is responsible for delivering the User Stories. They can only do this in close collaboration with the Product Owner, who will need to be available for constantly developing the User Stories.

Question 9: The tasks in the project comply with the INVEST principle. Not being able to split the project work into small and independent tasks, is a showstopper for Change Driven projects.

It also makes it difficult for Agile projects to measure velocity in a sprint. By rule User Stories must be small and independent in Agile projects. The INVEST principle allows a steady development, testing and closing of User Stories. It increases the level of controllability of the Agile project. It would be possible to extend the Sprint Cycle from e.g. two weeks to four weeks to allow larger User Stories, but that also lowers the level of feedback, and impediments in the sprint are detected later.

Large tasks that can only be tested at the very end, automatically push the project into a Waterfall mode. It would become necessary to measure progress of the tasks in between. It is possible to have User Stories cover multiple sprints, but let’s be honest about it: the project would only be Agile in name while it should better have been Waterfall.

Question 10: The project is risk-averse (x=1) to risk-accepting (x=5). The highest risk in late or even non-delivery of project tasks lies with Change driven projects. There is risk that changes will not be executed in time because the customer is not ready, or the operational teams have other things to do. Change driven projects tend to deliver late and it requires a stubborn project manager to keep the pace.

Agile driven projects have an implicit risk that the scope is not delivered in full. Yet, the high interaction between project members and the Product Owner helps keeping the project under control.

Risk-averse organizations will prefer Waterfall projects where the scope is well defined and signed for, and where sign-off can be requested for the different stage-gates and the go-live activities. Risk-averse organizations will like the high level of central control that Waterfall projects offer.

To conclude: I invite you to share your thoughts on the points given to the different questions. Should I assign a higher or lower grade for any of the questions? Let me know, either by responding or by contacting me directly.

This blog is part of the Chagwa training. Are you interested in learning more about the different ways of doing project management? Then I am inviting you to the next trainings in April and September. Subscribing to the training can be done through the following link.

https://bayardpartnership.com/chagwa-training/