Scrum can be a very effective framework when used for product development. With its many built in feedback loops the team can more quickly zero in on the correct functionality. They can target what is most valuable using feedback from customers, users, stakeholders and others.
But Scrum might not be the best option for all types of work.
Introducing Cynefin
Around the year 2000, Dave Snowden introduced what he called the Cynefin (kuh-NEV-in) Framework. Cynefin is a Welsh word that loosely translates to “habitat”. In our context, Cynefin can be thought of as a “sense-making” framework. How do we think about, or interpret, our work “habitat”?
The Cynefin Framework describes 5 domains, each of which contains a process of making decisions within that space.
A full description of Cynefin is beyond the scope of this article. For a deeper dive, click on the image below. I’ll keep it high level here.
The five domains in Cynefin are loosely defined as:
- Clear – known knowns. Both the problem and solution are well understood. This is the domain of Best Practices. An example would be automating a call tree.
- Complicated – known unknowns. There are a number of practices that will deliver the desired outcome, or goal. This is the domain of Good Practices. An example would be implementing middleware between an Identity Management system and existing software applications.
- Complex – unknown unknowns. We are now into domains where cause & effect are only known after-the-fact. There are too many different things happening. We define safe-to-fail experiments to make sense of what is happening. From there the solution will emerge. This is the domain of Emergent Practices. An example is developing a brand new software product (knowledge work).
- Chaotic – unknowable unknowns. The situation is so out-of-control that acting, doing anything, is necessary to better understand the situation before a path forward can be decided. This is the domain of Novel Practices. An example would be the collapse of Enron.
- Confusion – When nothing makes sense. Break down the problem into smaller pieces and then place those into the correct domain.

The Complex Quadrant
For the purposes of this post I will concentrate on the Complex quadrant.
Since cause and effect are only discovered after the fact, to better understand the problem and determine the correct solution we use small, safe to fail experiments and then inspect the results. Cynefin refers to this technique as “probe, sense, respond”.
The majority of the work performed in software development falls neatly into this quadrant. We have a general idea for a product, general sense of what customers would like, but these are (hopefully) educated guesses. We’ve probably all been subjected to “changing requirements” once development begins. This is an example of unknown, unknowns – we cannot predict ahead of time what in the environment might change or when.
Scrum Works Best for Complex Problems
Scrum utilizes time boxes, known as Sprints, as one level of small, safe to fail experiments. Typically Sprints will be 2 weeks in duration, at the end of which the team seeks feedback on what has been created so far.
As it relates to cynefin, Complex quadrant:
- Probe – the team builds a Sprint Plan, anchored by a Sprint Goal, that the team believes will bring value to the customer. This plan defines the experiment.
- Sense – the team completes the work of the Sprint and then seeks feedback on what was created during the Sprint Review.
- Respond – the team utilizes that feedback to adapt their future efforts accordingly, completing the experiment. Alterations to the Product Backlog are common after a Sprint Review.
The above is an example of iterative, incremental development. The team iterates to discover the highest value solution by developing the larger features incrementally. The product & best way to develop it emerges.
At an even smaller scale, work items, often in the form of user stories, can also be thought of as small, safe to fail experiments.
These layers of experiments, combined with an iterative & incremental approach, help the team to lower the risk of developing the wrong product. The frequent feedback allows them to course correct quickly, otherwise known as “adapting at speed”.
Difficulties for Non-Iterative Work
There are other types of work done by teams. Work that doesn’t require iterating to the correct solution. Work where the cause & effect are already well understood. Where there is only one, or very few, solutions to a well understood problem.
A Product Owner once stated to me “I want a car. I know I want a car. I even know I want a blue one. Why do we need all these meetings & time boxes to discover the solution I already know we need?”
Fair point!
Scrum is a framework, which means it has prescribed roles, artifacts and events. It is lightweight but that is not the same as free from overhead. Scrum has overhead.
Types of work where the solution is already well understood, such as updating to a new version of a system you use, or developing connectors between OIM (Oracle Identity Manager) and your systems, would not require such level of experimentation. You already understand what is needed to solve the problem.
In this case, the events & time boxing in Scrum aren’t necessary to discover the correct solution. Some experimentation may still be needed but it won’t be the foundation of your processes. Scrum can then feel clunky, or even intrusive. It can get in your way if you try to shoehorn it into a space its benefits are not needed.
The Scrum Guide suggests that, for a 2 week Sprint, 4 hours would be allocated to Sprint Planning. Similarly, several hours would be dedicated to the Sprint Review. Those are hours the entire team can reclaim by moving to a Continuous Flow model. Yes there will likely still be a bit of time needed for reviews/approvals but they would typically not include the entire team for large blocks of time. That time can then be used on more productive efforts.
Trust your gut in this case, Scrum might not be a fit in your environment.
Options for Other Types of Work
In the cases where an iterative approach isn’t needed to discover the best solution, look into utilizing Lean approaches.
I would definitely consider learning more about Kanban and its usages in the Clear and Complicated quadrants. Kanban will help your team visualize the work. It will help you understand & improve your processes and detect where you have constraints within those processes.
The scope of switching to Kanban is beyond the scope of this article.
Wrapping Up
Scrum can be a very useful framework to learn Agile and develop incredible products your customers will love. But it’s not a solution for every type of work teams might do. It can also get in the way in some cases.
If you liked this post and want to learn more about Agile, Lean or Leadership, please consider purchasing a book from my Recommended Reading page.
Until next time!
