A deep dive into complexity
FAST Agile and Scrum both exist to operate in the Complex domain. That said, the creators of FAST Agile claim Scrum is not suited for this. This claim is interesting and the creators of Scrum obviously don’t agree.
In my previous article, I also discussed FAST Agile and Scrum. I compared many aspects of the frameworks. But I only could scratch the surface of the topic complexity.
Now I will take a deep dive into the complexity and argue why both frameworks sit in the Compex domain. The Complex domain is broad. And the border areas of Complex with Complicated and Chaotic aren’t clear-cut.
I think this is important. The claims a contradictory and confusing, potentially leading to misunderstanding and misapplication. So it requires clarification.
Cynefin
There are several ways to depict and identify types of domains. The two most famous are the Stacey Matrix and the Cynefin framework. I decided to use Cynefin for this discussion as that model is used by FAST Agile.
Cynefin helps people understand which domain they operate in to know how to respond to challenges. The framework knows 4 domains:
Clear — Cause and effect are clear.
Complicated — Cause and effect can be discovered
Complex — Understanding the system through interaction
Chaotic — Turbulence rules and immediate action to stabilize is key
And there’s also:
Confused — No idea of which domain one is in
Cynefin suggests different responses to different domains. For each domain, Cynefin defined a three-step response:
Clear — Sense, Categorize, Respond
Complicated — Sense, Analyze, Respond
Complex — Probe, Sense, Respond
Chaotic — Act, Sense, Respond
The Clear domain involves using best practices. The Complicated domain has analysis before responding. The Complex domain is about experimentation to verify assumptions. The Chaotic domain calls for action.
Cynefin also has liminal areas, bordering two domains. As an example, below I singled out the liminal area between Complex and Complicated. This liminal area is in the Complex domain. This means that Probe, Sense, Respond is the best response, verifying assumptions. Assumptions will often be proven right in the liminal area than in the pure Complex domain. Here the predictability is higher than in ‘pure’ Complex.
The claims of FAST Agile and Scrum
Scrum and FAST Agile have two different ways to approach complexity.
The creators of Scrum claim the following:
“Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.” — Scrum Guide 2020
The creators of FAST Agile state:
“FAST is ideally suited for business environments or challenges that show complexity, rapid change, or where there is a need for innovation.” — FAST Guide 2.1
FAST Agile is about ‘pure’ Complex, even bordering on Chaotic.
But FAST Agile creators also claim Scrum is not for the Complex domain. Scrum would only be suited for the liminal area between Complex and Complicated. Here’s how Ron Quartel depicts it:
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F11172f10-58b1-4b6c-921a-6a91f785c590_800x330.png)
Now we know how FAST Agile and Scrum view complexity. Let’s now look at how the framework tackle complexity.
Scrum and complexity
Scrum has always been a framework to create value in complex environments. This was true in 1995 when Scrum was introduced. It is still true today.
Principles
Scrum uses empiricism to manage complexity. The pillars are transparency, inspection and adaptation. Every Sprint the Scrum Team collaborates to create a ‘Done’ Increment. The Scrum Team and its stakeholders understand what’s in the Definition of Done. This brings transparency.
They inspect the Increment and other developments impacting what to do next. They do this to verify assumptions and learn something new. Then the Scrum Team decides what they will target next.
Scrum doesn’t function with detailed long term plans. It uses goals instead. To manage the longer term, there’s the Product Goal. The Scrum Team commits to working towards this Product Goal.
Practice
Every Sprint, the Scrum Team defines a Sprint Goal. During the Sprint the Developers work towards achieving this Sprint Goal. Plans are highly adaptable. The Sprint Goal is stable. Managing the complexity of work in a Sprint is the first way to manage complexity.
Scrum Teams have Sprint Reviews with their stakeholders to inspect their progress towards The Product Goal. This is a second aspect of the complexity of the environment.
Lastly, Scrum has the Sprint Retrospective. Here Scrum Teams inspect themselves to look for ways to be more effective. This is the third aspect of managing complexity.
Scrum manages complexity in three ways. The work during the Sprint, the progress towards the Product Goal and the effectiveness of the team all are addressed by Probing, Sensing and Responding.
Sprints have a cadence and are no longer than a month. Typically, Sprints are one or two weeks. But they could be shorter.
FAST Agile and complexity
FAST Agile has several traits to tackle complexity. For one, it has short Value Cycles which allows for fast verification. Two days is the recommended length. But it can be anything up to five days. changed. One Value Cycle could be four days and the next one could be one day. The variation of the length of the Value Cycles highlights the complexity of the challenges. They vary significantly.
The most prominent trait of FAST Agile is fluid teaming. Everyone is part of a Tribe. This Tribe self-organizes into teams to address one specific goal each during the Value Cycle. Every Value Cycle, they repeat this. The Tribe is adaptable to tackle complex challenges.
At the start of a Value Cycle, the Product Director highlights a set of priorities. Tribe members create fluid teams to address a priority, a goal. The Tribe works on multiple goals with multiple fluid teams. Parallel experimentation fits with complex challenges.
Scrum and complexity — my thoughts
Scrum’s empiricism aligns with how Cynefin proposes to manage complex problems (Probe, Sense, Respond). Teams aim to meet a Sprint Goal and they have every flexibility to change course. They do this to maximize the chances of meeting this goal. Teams are cross-functional and self-managing. They should have all the skills and autonomy to do the work.
That said, Scrum Teams tend to be stable for a long time. As a result, they are less flexible than FAST Agile teams in what they can take on. They are limited in an environment that calls for a different mix of skills with every objective.
But Scrum does have the inspection and adaptation opportunities at the end of the Sprint. The Sprint Review allows stakeholders to verify what has been done and what would be the best next step. The Sprint Retrospective is there to inspect how the team works together and find better ways.
Scrum definitely fits the Complex domain of Cynefin. It exceeds the liminal area between Complicated and Complex.
FAST Agile and complexity — my thoughts
FAST Agile has great potential to solve multiple complex problems at the same time. This is due to fluid teams and the flexible Value Cycle length.
I also see the limitations of FAST Agile. The framework concentrates on the complexity of the work in an iteration. It hardly helps with uncovering learnings from the iteration on what to do next. This hints towards the fact FAST Agile aims to solve issues bordering Chaotic.
To elaborate, there’s only one sentence to describe an equivalent of Scrum’s Sprint Review AND the Sprint Retrospective:
“A representative from each team briefly summarises their team’s work in the last Value Cycle, highlighting value delivered and discoveries made.” — FAST Guide 2.1
Here I miss mentioning interaction between the team and other people. Like people from other teams or stakeholders from the Tribe. I miss the “Customer collaboration”, one of the cornerstones of the Manifesto for Agile Software Development.
On top of that, I miss a clear indication that teams are looking at how they did their work to learn from it and improve.
I conclude FAST Agile specifically targets the complexity of solving a problem during the Value Cycle. FAST Agile does less with the complexity of reaching a longer-term objective, taking multiple cycles. The Value Cycle merely ends with teams explaining what happened. There’s no mention of an inspection of their findings and of a response leading to priority changes.
FAST Agile also has less eye on the complexity of the teamwork itself. One could argue that this is intentional, due to the complex nature of the environment.
Longer-term objectives may be impossible to convey on the edge of chaos. That does mean FAST Agile has the most value as an approach for Complex work close to the Chaotic domain.
End Conclusion
FAST Agile and Scrum are approaches that both work in a Complex domain.
FAST Agile creators state Scrum is not suited for Complex domains. This doesn’t do Scrum justice. Scrum fits in the liminal zone between Complex and Complicated. But this is in the Complex domain. It is wrongly depicted in Ron Quartel’s article and the picture above.
On top of that, Scrum also clearly is designed to work in pure Complex domains. Scrum’s empiricism fits Cynefin’s response in Complex domains.
Here is how I view the positions of Scrum and FAST Agile:
FAST Agile has a better answer than Scrum to the more complex environments, bordering Chaotic. The reasons are the fluid teams and fluid iteration length. FAST Agile doesn’t focus on longer-term goals and self-improvement. This supports my observation.
FAST Agile and Scrum are two different frameworks. FAST Agile fills the empty spot close to and bordering Chaotic, where Scrum doesn’t flourish. Scrum has just enough rules and events to address complexity. But it has too many rules for environments bordering Chaotic.