Engineering Workflow Choices: When Agile Fits—and When It Doesn’t
A practical guide to aligning engineering methods with task complexity for better outcomes
In practice, almost all of us work in some form of Agile. There are quite a few variations nowadaysEngineering Workflow Choices: When Agile Fits—and When It Doesn’t—from simple Kanban or classic Scrum to Scrum of Scrums or SAFe. One thing is certain: very few of us work in a methodology that isn’t Agile. In today’s world, it’s almost frowned upon not to, even if what we’re really doing is Water-Scrum-Fall (more: https://www.plutora.com/blog/water-scrum-fall).
But what’s the reality? Is Agile always the best way to develop software? Some time ago, we discussed the Cynefin Framework - A Stuff+ Tool for Approaching Problems, which is not just about management or project delivery—it’s a guide for self and organizational improvement. Today, we’ll focus on Ralph Stacey’s Complexity Matrix (often called the Stacey Matrix).
What is the Stacey Matrix?
The Stacey Matrix was developed by Ralph Stacey to help organizations understand and manage complexity by assessing two key dimensions:
Certainty (how well outcomes can be predicted)
Agreement (how much consensus exists among stakeholders)
These dimensions define four main zones:
Simple: High certainty and agreement. Clear cause-and-effect relationships; best practices and routine procedures work well.
Complicated: High certainty, but lower agreement. Solutions require expert analysis or negotiation.
Complex: Low certainty and agreement. Problems are unpredictable, and solutions emerge through experimentation and adaptation.
Chaotic: Neither certainty nor agreement exists. Rapid response and innovation are needed.
When is structured Agile (not) suitable?
Looking at “simple” tasks, introducing Agile practices often leads to frustration. For example: why plan something that’s faster to just sit down and do? Of course, that doesn’t mean we shouldn’t measure or improve, but often the Agile “overhead” seems unnecessary to those doing the work.
It’s similar with “complicated” tasks. If we know how to do it, we just need to sit down, think it through, and execute. From experience, a simple Kanban board is often enough. The structure that methodology brings mostly benefits stakeholders, not the team members themselves.
Let’s jump to “chaotic” for a moment. For example, architecture or application (r)evolution aligns more naturally with “anarchy.” It’s really hard to use Scrum for something we have no clue about. As an example, consider rewriting an application you work on from technology A (e.g., Python/React Native/Angular) to technology B (e.g., Node.js/native iOS & Android/React). You might be able to define some high-level milestones, but creating a detailed plan and estimating it seems extremely difficult.
It’s different with complex tasks. They involve uncertainty in both requirements and technology. These tasks don’t have a clear path, and the solution emerges through experimentation, adaptation, and collaboration. Agile practices are particularly effective for complex tasks because they allow flexibility and iterative development.
Should I Stick to One Method?
From the perspective of a team or technical leader, tasks are often a mix of the above categories. But the truth is, we don’t have to force ourselves into one approach. We can mix them. For example, for “bug handling” tasks, we can carve out a Kanban stream and allocate, say, 0.5 FTE, while using Scrum for product development.
Importantly, such improvements don’t have to come from a Scrum Master or manager. If you see the opportunity as a team member—propose it. The same goes if you’re an outsider, like a staff+ engineer.