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.
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. 
Requirements & Solution
“What” and “How”
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
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.
“…the degree of certainty for project requirements and project solutions allows us to group projects into 4 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.
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.  Don’t you wish they were all this easy!
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. 
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.
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.
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…”
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.
“… 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. 
- 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. 
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!
References Brian Rabon “Scrum for the Rest of Us: A Braintrust Field Guide” (2013)
 Jeff Sutherland, Ken Schwaber “The Scrum Guide” (2016)
 Modified version of chart from Michael James “Scrum Reference Card” (2012), referenced in Agile Software Development with Scrum, Schwaber/Beedle (2001)
 Herbi Bodner “Why agile? – The Stacey complexity model” (2016)
 “Cynefin framework” Wikipedia (2016)
 “Ralph D. Stacey” Wikipedia (2016)
 Michael James “Scrum Reference Card” (2012)