Most folks know that any building is only as strong as its foundation allows. Almost everyone would nod in agreement at such an obvious statement if you made this comment in a crowd. So why do people risk laying the wrong foundation for what they plan to do in other aspects of life that are based on something other than physical building architecture? In many ways, it’s a human shortcoming where we would identify something as painfully obvious in one setting but completely overlook it in another setting where it holds the same weight.

A typical example of this in business is choosing what approach or framework to use when planning and delivering a project. We can narrow it down to two options: Agile or Waterfall. Have you heard someone ask, “Should this project even be an Agile project?” or make a statement like “This would have worked much better using Agile”? I know I have on multiple occasions. The problem is that these questions and statements are made during the project, usually around the middle, somewhere when the wheels start coming off. That’s way too late because it means the very foundation of the project is being questioned.

To help avoid existential crisis moments like those, I’ve put together a guide to help you question the project’s initial intentions and to help you ask the right questions to select the most appropriate framework for delivering success. To use the guide, could you answer the questions in each of the twelve sections? Each section will present a choice between Agile and Waterfall in a situation that would suit your answers. Each choice has a number in brackets at the end. This is a weighting out of 120 for both Agile and Waterfall. At the end of the guide, you can tally the total points for both Agile and Waterfall, and you’ll indicate which framework should, in theory at least, work best for your project.

How do we use this questionnaire? 

Step 1: Go over the main criteria. The criteria provided are a default set that is found in most projects. Add your own or remove the ones that are not relevant.

Step 2: Each criterion has a weighting of 10. If you think something isn’t worth 10 points, subtract 1 point from that criteria and add it to a criteria that you think is more important. Go through each criterion until you are satisfied with the weighting of all of them. The total weighting should never go over 120 or be less than 120. 

Step 3: Choose between Agile or Waterfall for each criterion.

Step 4: Assign the weighting of each criterion to either Waterfall or Agile, depending on what was chosen.

Step 5: Tally the total weighting points awarded to Waterfall and Agile.

Step 6: Discuss the result.

 

Project Vision and Objectives (weight 10)

What are the key objectives and expected outcomes of this project?
Is the project vision well-defined and unlikely to change?

Agile: Choose Agile if the project objectives are expected to evolve or if there’s a need for flexibility in the project vision.
Waterfall: Choose Waterfall if the objectives are clear and fixed from the outset with no expected changes.

 

Requirements and Scope (weight 10)

Are the project requirements clearly understood and well-documented?
How likely will the project requirements change during the development process?

Agile: If requirements are not fully understood or are expected to change, Agile allows for adaptation throughout the project.
Waterfall: If all requirements are known and well-documented upfront with little change anticipated, Waterfall is appropriate.

 

Customer and Stakeholder Engagement (weight 10)

How frequently do stakeholders expect to see progress, and how often will they want to provide input?
Do stakeholders require early and incremental delivery of the product?

Agile: Agile is suitable when frequent stakeholder input and collaboration are necessary and stakeholders wish to see iterative releases.
Waterfall: Waterfall works well when stakeholder requirements are known, and their input is limited to specific review points, not throughout the process.

 

Risk and Uncertainty (weight 10)

What risks are associated with the project, and how comfortable is the team with uncertainty?
Does the project involve the exploration of new technologies or uncertain solutions?

Agile: Agile is better when there’s high uncertainty or when the project involves exploring new solutions, as it can adapt to changes and risks as they arise.
Waterfall: If risks are minimal and well-understood, the predictability of Waterfall can be advantageous.

 

Complexity and Size (weight 10)

How complex is the project, and what is the estimated size?
Can the project be easily divided into smaller, manageable pieces?

Agile: Agile is advantageous for complex projects that can be broken down into smaller, incremental pieces that can be tackled iteratively.
Waterfall: Waterfall can be efficient for less complex and smaller projects with a well-defined scope.

 

Time to Market (weight 10)

Is there a fixed deadline, or is time-to-market a critical factor for the project?
Would delivering a minimum viable product (MVP) early be more valuable than delivering a complete product later?

Agile: Agile is preferable when the goal is to get a product to market quickly and to iterate based on user feedback.
Waterfall: If the timeline is fixed with clear milestones and deadlines, Waterfall can ensure a structured approach to meet these dates.

 

Resource Availability (weight 10)

Are the project team members available full-time for this project?
Do the team members have the necessary skills to adapt to a changing environment?

Agile: Agile works well with dedicated, full-time teams, especially if they are cross-functional and can adapt to change.
Waterfall: If resources are only available part-time or are fixed, Waterfall’s structured phases may allow for better scheduling.

 

Quality and Performance (weight 10)

How critical are the final product’s quality and performance?
Is there a need for rigorous documentation and traceability throughout the project?

Agile: If quality needs to be assessed continuously with room for improvement, Agile’s iterative testing is beneficial.
Waterfall: In cases where high-quality standards with extensive documentation are required from the start, Waterfall is more suitable.

 

Budget and Cost Constraints (weight 10)

Is the budget fixed, or is there flexibility for changes in scope?
How important is cost predictability to the stakeholders?

Agile: When the budget has some flexibility to accommodate changing scope, Agile allows for re-prioritization of features based on available funds.
Waterfall: If cost predictability is essential and the budget is fixed, Waterfall’s structured approach helps in detailed budget planning.

 

Team Dynamics (weight 10)

Does the team have experience with Agile or Waterfall methodologies?
Is the team co-located or distributed, and how does this impact communication and collaboration?

Agile: Agile is effective with experienced Agile collaborative teams who can self-organize.
Waterfall: Waterfall suits teams that are more accustomed to a structured approach with clear directives and less collaboration required.

 

Delivery and Feedback (weight 10)

How important is it to have early feedback from end-users or stakeholders?
Would the project benefit from iterative testing and integration?

Agile: Agile is the right choice if early and continuous feedback is crucial for the project’s success.
Waterfall: Waterfall should be used when feedback is only necessary at specific milestones rather than throughout development.

 

Regulatory Compliance (weight 10)

Are there stringent regulatory requirements that mandate detailed documentation and formalised phases of development?

Agile: Agile can still be used in regulated environments but requires a focus on creating documentation iteratively throughout the project.
Waterfall: Waterfall is often chosen in heavily regulated industries where comprehensive documentation and phase-wise validation are mandatory.

 

 

Now that you’ve answered the questions and chosen between Agile and Waterfall for each of the criteria above, you’ll have a little more confidence in the choice of framework for your project’s approach. That confidence is vital to a good, solid foundation on which to build your next steps. You can always return to your questions and answers as things change (and they often do) to help determine whether or not your project is still using the framework with the best potential for success.

As always, this guide is not from some rule book. It’s not a law, and the weighting assigned to each option is a suggestion. Those points can and should be adjusted to suit your particular project.