Daniel Walsh, founder of nuCognitive, recently gave a talk at the Austin Design Sprint meetup, on complexity theory and his favorite complexity framework called Cynefin. With the title “Why Design Sprints Work”, attendees might have expected to hear about ROI calculations and justifications for why Design Sprints are the right thing for an enterprise to adopt. Instead, Walsh gave a captivating talk starting with an explanation of complexity theory, then walked through examples of how Design Sprints are an expression of complexity informed practices, and finished with a list of thoughtful questions around how we might further enhance Design Sprints using complex adaptive systems heuristics.
Complex Systems and the Cynefin Framework
3 Fundamental Systems
A system is a collection of independent but related components that comprise a coherent whole A system has a boundary and exists within a surrounding universe. Some systems are embedded in ecosystems, which are a subset of the universe. An agent is anything that acts within a system
- Chaotic systems are unstable, random and the cause and effect relationships are unknowable
- Complex systems are semi-stable, continually evolving, dispositional, and present emergent patterns. The whole is not the sum of its parts.
- Ordered systems are stable, predictable, and have resultant properties. They support decomposition and aggregation as the whole is the sum of its parts.
Cynefin Framework
Dave Snowden, Founder and Chief Science Officer of Cognitive Edge, began work on a Cynefin model in 1999 to help manage intellectual capital within IBM by formalizing an approach to situational awareness & contextually appropriate action
The nature of the system determines the way we can know things, how we make decisions, and how we act.
-David Snowden
There are 5 Cynefin domains are the differentiated by the nature of the constraints at work in the system: Obvious, Complicated, Complex, Chaotic, and Disorder. The framework is often misrepresented as a rigid 2×2 matrix with disorder in the center. Instead of starting there, Daniel shared with us a more linear view to help illustrate how the domains relate to each other. Starting with Obvious on the right and move towards Chaotic on the left, each domain becomes less and less constrained. In the Obvious domain, things are so constrained that there is one optimal solution that is “obvious” to all. Complicated domains are a little less constrained allowing for a few good solution but no one single solution. Complex domains are even less constrained and solutions must continually adapt to emergent properties. The Chaotic domain has no constraints and underlying causes for what is happening is unknowable. There are no solutions other than to take decisive action to transition to another domain.
The Cynefin Framework is used for social systems, so there are boundaries between domains. Teams also may experience disorder as constraints change and the situation moves from one domain to another. As humans we each associate with a number of different identities known as human identity. Daniel pointed out that he was identifying as a speaker at that moment, however, if he got a call that his young boy was injured, he might quickly transition into the father identity (i.e. protective father mode). Interestingly, any one person could default to a preferred approach or set of behaviors based on their current identity. Furthermore, we use rituals to transition between identities and shift the patterns of behaviors. Consider professions that require a uniform. The act of putting on the uniform is a ritual for entering that identity. We regularly use these rituals to help us prepare for a shift into a different Cynefin domain.
When the linear model is folded in half to view the model in a new way, an opening or gap between the Chaotic and Ordered domains is created. We refer to this opening as the fold or cliff. A common cautionary tail, and the reason we have the “cliff”, is that transitioning from Obvious to Chaotic often results in catastrophic. However, if you do survive a transition over the cliff, the novel solutions and situational awareness you acquire could lead you to new heights.
Domain Examples
For those of you that are a little lost, here are a few examples Daniel provided to make the domains more concreated
- Obvious: Police Roadblock
- Complicated: Traffic Light
- Complex: Roundabout
- Chaotic: Brownian Motion
Characteristics of Complex Adaptive Systems (CAS)
There is no standard definition of complexity, but there are some common characteristics.
- Large number of interacting agents or components with feedback
- Very sensitive to initial conditions and conditions
- Non-linear behavior (may respond in different ways to the same input depending on their state or context)
- Emergent properties (properties that are not apparent from their components in isolation but which result from interactions)
While hypothesis work in ordered systems, in the complex domain it is important to place small risk bets to probe the environment. This illustrated by Boisot’s Connecting the Dots: from data processing to pattern processing. Each dot represents an event in your system. Dot are connected together through links representing some relationship or causation. Starting with an overly simple system that has 4 events we can calculate 64 total possible patterns of links between dots. Simply adding 6 more events for a system of 10 and we are already at 35 Trillion patterns. As you can see, this quickly becomes an unexplainable phenomenon.
“Hindsight does not lead to foresight..” Max Boisot
Cynefin Dynamics
As we covered earlier, our human identity can influence how we behave. People need to adopt a different approach depending on the context of the current situation. Managing constraints is critical for shifting and moving dynamically between domains. When not grazing in one domain, you may find people cycling between 2 domains. For example, SCRUM is an example of a framework that allows teams to move from the complex to the complicated. Therefore, you can imagine, when someone is identifying as a SCRUM Master, they will often be found cycling between complex and complicates.
Checklists clearly live in the Obvious domain. If your checklist is out of date or requires updating, you need to assemble a team of experts to address the changes. During this process, you are in the Complicated domain. Once the new checklist is completed and put into use, you return to the Obvious domain.
Some organizations have teams which missions precisely aligned with a specific domain. When recruiting members for the teams, hiring managers will seek individuals that excel in that domain. For instance, and R&D team may cycle between Complex and Chaotic, while a commercialization team may function in the Complicated domain and sometimes cycle into the Complex.
Heuristics for Design Sprints in Complex Situations
Probes
Probes are small safe-to-fail interventions used to nudge a complex adaptive system and increase understanding of the system. A Design Sprint as well as some of it’s constituent parts are good examples of probes. The Prototype developed on Day 4 and tested on Day 5 is undoubtedly a probe used to understand the customer. Mapping, Ask the experts, sketching, and storyboards are also probes into the Sprint team and your extended team. Probes enable teams to avoid investing too much time and effort to predict outcomes and establish specific targets and instead focus on the desired direction instead.
- Make sure demos are safe-to-fail
- When in doubt, keep investments small
- Strive to conduct multiple probes in parallel.
Small finely-grain object
Complex adaptive systems are grown from smaller systems and evolved and therefore cannot be architected and planned thoroughly in advance. Therefore exploring and manipulating small finely-grained objects provide the required flexibility to explore this domain. Design Sprint methods use many small ideas and concepts (e.g. Crazy 8s, sketches, storyboards). Working with small, finely-grained objects allow us to mix and remix concepts to combine them in novel ways. Lightning demos is an example of an exaptive approach to innovation.
Disintermediation
Disintermediation is the removal of the intermediate layers between decision makers and on-the-ground reality. Consider the Andon cord from the Toyota production system. Complex adaptive systems are continually evolving and changing; they don’t stand still. Decision makers need to stay in touch with the way things actually are in the present. This might make you think of the undercover boss or lean practitioners seeking to“Get out of the building”. The Design Sprint demo places decision makers directly in touch with customer feedback. Everyone on team observes the interview and get feedback in real time.
Distributed Cognition
Distributed cognition is the process of enabling agents in a complex adaptive system to think for themselves. Consider a roundabout. They have so many moving parts and different perspectives that no-one can “know” everything. Need to take advantage of the cognitive capacity of everyone in the systems. Examples of this in action during designs sprints are heat maps, dot voting, lightning demos. Design Sprints are a powerful combination of individual work balanced with group synthesis.
“What are the differences that make a difference” — Glenda Eoyang
Requisite Diversity
Diversity of agents and perspectives is essential for complex adaptive systems involving humans. Requisite diversity is about understanding the differences make a difference and ensuring that there is sufficient density of perspective. Design Sprints have mechanisms that help ensure diversity. The Design Sprint roles (decider, finance, marketing expert, customer expert, technology and logistics expert, design expert) provide multiple diverse perspectives for unpacking the problem space and evaluating the demo.
Miscellaneous
A few other uncategorized examples of complexity principals at work in Design Sprints
- Seeking opinions and advice from outside experts in a related field (i.e. naive perspective)
- High-fidelity prototypes provide more context
- Manage constraints to move between domains
– e.g. The decider constrains the team, shifting them from Chaotic to Complex
– e.g. Converge/Diverge Sprint mechanics
“How Might We” improve Design Sprints using Complexity Theory Principals
I especially liked Daniel’s closer. He provided a list of thoughtful how might we statements that prompted us to consider how complexity theory principals might be used to improve Design Sprints.
How might we…
- Ensure that our teams are not converging too fast?
- Monitor our Design Sprints to more proactively manage constraints
- Run more probes in parallel?
- Use human identity to inform design and customer recruiting
- Use ritual to help situate customers within context and get a more authentic behavioral response
