Agile or Waterfall: What’s the best approach for your project?

Examining 4 Quadrants of Project Extremes

Extreme Scenarios

Extreme scenarios are rare in projects as they are in most aspects of life.

“…examining project extremes can help us learn to identify the types of projects where Agile methods may be most and least effective.”

Rare scenarios like these may never be encountered in your day-to-day work, and at first, it could feel like analyzing them is a waste of time.

Waterfall vs Agile: How to Choose?

But in many industries, there is often something to be learned from taking a closer look at these extreme events.

Examining extremes in business like overnight success stories versus unprecedented failures can help entrepreneurs mold better processes for successfully managing the average organization.

Examining extremes in human performance like the habits of olympic athletes versus the habits of the highly sedentary can help health professionals prescribe better nutrition and exercise plans for the average patient.
In a similar way, examining project extremes can help identify the types of work where Agile methods like Scrum can be most and least effective.

To get started, we need to begin by first categorizing projects using the following 2 attributes: project requirements and the project solution. [3]

Requirements & Solution

“What” and “How”

Requirements: "What" we're trying to do. Solution: "How" we're going to do it.
Requirements: “What we’re trying to do.” Solution: “How we’re going to do it.”

When defining new terms or just organizing my thoughts, I’ve often found that utilizing Five W’s (and How) to be a valuable tool.

For our purposes, project requirements can be thought of as a high-level list of “what” must be delivered in order to consider a project complete.

The project solution can be thought of as simply the details surrounding “how” the team will deliver that solution. A team’s skill set, knowledge of required technologies and experience solving similar problems will all play a factor here.

Now that our basic terms are a little better defined, the next step is to identify the extremes of the “what” and the “how” which we’ll use later.

Known vs Unknown

Degree of Certainty

… “known” and “unknown” represent the highest and lowest degrees of certainty for project requirements and project solutions…

For consistency, we will identify the extremes for both project requirements and project solutions as “known” and “unknown” – the former possessing the highest degree of certainty and the latter possessing the lowest degree of certainty.

Requirements that are known are well-defined and should not change, and unknown requirements are those that are unclear, lack stakeholder agreement and/or change very frequently.

Known solutions are straightforward, easily accessible and require little thought. Solutions that are unknown involve teams that lack experience solving similar problems or require technologies that are foreign to the team.

With known and unknown now defined as the extreme values for a project’s “what” and “how”, we can use these values to help categorize a few different types of projects.

4 Quadrants of Project Extremes

Examples and Best Approach

…the degree of certainty for project requirements and project solutions allows us to group projects into 4 quadrants…”

4 Quadrants of Project Extremes [3]
Utilizing known and unknown – the highest and lowest degrees of certainty for project requirements and project solutions – allows us to categorize projects into 4 unique quadrants.

Next, we can look at some examples of the types of projects likely to fall into each quadrant as well as some approaches that can be used to move each project forward.

Quadrant 1

Solution = Known | Requirements = Known

Quadrant 1 projects have very well-defined, stable requirements and solutions: we can easily identify what needs to be done and the team knows how to do it.

Example: Manufacturing and other well-known repeatable processes.

Best Approach: Best practices (or a Waterfall-like plan) should be defined and implemented. [5] Don’t you wish they were all this easy! 

Quadrant 2

Solution = Unknown | Requirements = Known

Quadrant 2 projects also have well-defined and stable requirements, but the solution is outside the team’s expertise to solve: we know what needs to be done, but don’t have the time or expertise to figure out how to do it.

Example: Software projects where stakeholders have a clear vision of requirements, but the team is completely lost and lacks experience solving similar problems. [1]

Best Approach: There are a few options here: (1) the existing team should be educated on solving similar problems, (2) a new team should be assembled with the necessary expertise or (3) the project should be outsourced.

Quadrant 3

Solution = Known | Requirements = Unknown

Quadrant 3 projects have unclear, unstable requirements; although, the solution should be well within the team’s ability to solve.

Example: Projects still early in the ideation phase where stakeholders have yet to agree on basic requirements.

Best Approach: Stakeholders should solidify a basic project vision before moving forward.

Quadrant 4

Solution = Unknown | Requirements = Unknown

Quadrant 4 projects are the least realistic and least likely to be encountered of any of the four quadrants.

Projects here would have unclear, unstable requirements, and the range of possible solutions are unknown and likely to change significantly once requirements are established.

Example: Realistic examples for this Quadrant are tough but might apply to extreme scenarios where some problem has been identified, but no one can clearly define what that problem is – much less how to solve it.

Best Approach: No good approach here. You’re on your own. =)

So, where do Agile projects fall?

Requirements = ? | Solution = ?

“…the truth is that Agile projects fall somewhere in between…”

Agile Projects fall somewhere in between

After all of this reading, I bet you were hoping for a clear answer. That would be nice, wouldn’t it?

The truth is that Agile projects fall somewhere in between.

Before we examine the types of projects most suitable for Agile methods, let’s look at the situations where the Agile approach makes the least sense.

Don’t use Agile…

When the solution is clear and requirements are rock solid, it’s best to simply follow an existing plan. These are the easy ones so don’t over complicate things. An empirical approach or Agile method like Scrum would offer little value here.

And on the flip side, if stakeholders can’t agree on basic requirements or the solution is clearly outside the project team’s capability to solve, it will likely be a struggle to gain the traction needed to move the project forward regardless of the approach being used.

Use Agile…

“… when stakeholders can agree on a basic project vision and the solution is too complex for a defined approach… an Agile method usually makes sense.”

Agile projects fall somewhere in between our project extremes when requirements and solutions can be described as seen below. [7]

  • Requirements: Stakeholders agree on a basic project vision while accepting that requirements will change as more is learned.
  • Solution: Too complex for a defined approach like the Waterfall model but well within the project team’s ability to solve.

The reason Agile beats simply following a defined plan for complex problems is that requirements and solutions can often only crystallize in retrospect – after work begins and more information is learned. [5]

Iterative development cycles and frequent incremental product releases encourage stakeholders to frequently inspect work and provide valuable feedback which teams use to quickly adapt when new requirements are uncovered and new technologies are needed.

The ability to quickly respond to change is what allows Agile businesses to maintain a competitive edge in the increasingly fast-paced world of new product development.

Thanks for reading!



[1] Brian Rabon “Scrum for the Rest of Us: A Braintrust Field Guide” (2013)
[2] Jeff Sutherland, Ken Schwaber “The Scrum Guide” (2016)
[3] Modified version of chart from Michael James “Scrum Reference Card” (2012), referenced in Agile Software Development with Scrum, Schwaber/Beedle (2001)
[4] Herbi Bodner “Why agile? – The Stacey complexity model” (2016)
[5] “Cynefin framework” Wikipedia (2016)
[6] “Ralph D. Stacey” Wikipedia (2016)
[7] Michael James “Scrum Reference Card” (2012)

User Stories: Background & Benefits

What are they? Why use them?

Story Time with the Fam
Everybody loves a good story.

Stories are powerful tools.

They help us remember, they entertain us and they allow us to relate to one another unlike anything else.

If you’re familiar with Agile development (if not, start here) you’re probably aware that user stories are a common approach for capturing product requirements. But have you ever wondered, why?
Or have you ever been curious about where they originated?

If so, this article might be able to help.

Key Takeaways

What is a user story? 

A user story is a lightweight method for quickly capturing the “who”, “what” and “why” of a product requirement.

User stories are written in everyday language and describe a specific goal (what) from the perspective of an individual (who) along with the reason (why) he/she wants it.

In software development, the goal Continue reading “User Stories: Background & Benefits”

Scrum vs Agile

What’s the difference? How do they relate?

Scrum Co-founders: Jeff Sutherland & Ken Schwaber
Scrum co-founders: Jeff Sutherland & Ken Schwaber img

Ever find yourself using “Agile” and “Scrum” interchangeably because you’re unsure which is correct?

Do you know the history of each term or how the two are related?

Did you know that’s it’s been over 30 years since the article that inspired Scrum was published in the Harvard Business Review?

If these questions interest you or you’d just like stop confusing the terms (like me!), this article may be able to help

Quick Overview

While the two concepts are related with many of the same players involved, Agile and Scrum are not synonymous. “Agile” refers to a group of several software development frameworks that are united around a few key principles. “Scrum” is simply Continue reading “Scrum vs Agile”

Getting Things Done

How I Never Forget To Do Anything

Do you often have the best intentions but fail to follow through?

Do you make too many commitments and feel overwhelmed from trying to juggle way too many tasks?

Do you have piles of “stuff” that continually builds up in your mind that you’re never quite sure what to do about?

If so, this blog may be for you.

Ok… “never” may be a strong word. I do forget things on occasion, but I have found that it seems to happen much less frequently than many people.

In the past, I’ve been somewhat reluctant to talk much about productivity and self-improvement until a recent conversation with a couple of friends who encouraged me to share more often.

Getting Things Done by David Allen
Getting Things Done by David Allen

So today I thought I would share a simplified version of the system I use to organize everything that comes across my plate.

First off, I don’t believe that the ability to remember and keep track of commitments is a reflection of one’s character, work ethic or intelligence. It’s simply about having a trusted system in place that works for you.

The following 5 steps are Continue reading “Getting Things Done”