Approaching Work Based on the Domain of Work
As we’ve seen, product development, unique change, is emergent, not deterministic. The work is filled with unknown-unknowns and acting in the space changes the space. Conversely, a worker making wheels all day long on an assembly line knows when the wheel is built and when it’s not. Likewise an organization processing ten million payment transactions a day. In that context, you want standardized work, not variability.
It’s much harder when each thing you build is unique. Only once the product is built can you realize a better way of building it, or even realize that building something entirely different would better meet the needs of the consumer. In an emergent domain, you want variability to learn and then amplify the experiments that optimize for the desired outcomes.
This means there is no one-size-fits-all way of working. It’s not about Agile-everything or Lean-everything or DevOps-everything. It’s about optimizing the way of working based on the type of work and your unique context.
The Cynefin Framework
In 1999, while working as a management consultant for IBM Global Services, Dave Snowden produced the “Cynefin” (pronounced kuh-nev-in) framework to categorize the different domains in which work today takes place. Named after the Welsh word for “habitat,” the framework provides a model of five domains for problem-solving and decision-making. It is a very useful way to determine when to take an agile approach, a lean approach, or neither.
Clear: Child’s Play
The “clear” domain of the Cynefin framework is straightforward and has predictable results. This is child’s play. There is no need for a project plan, a sprint, or a backlog. A child knows that if she turns left, then right, then left again, she will arrive at school. The route is the same every day and so is the result. This domain has known-knowns and a best practice. In the UK you drive on the left. In the US you drive on the right. The relationship between cause and effect is clear. In this domain it is possible to sense the situation and the environment (e.g., I’m in the UK), categorize it based on what you know (in this country people drive on the left), and respond by following the rules or applying best practices (set off, driving on the left).
Complicated: Sweet Spot for Lean
The Complicated domain requires more judgment. It is knowable because this activity has been done many times before in this context. However, it’s not child’s play; it requires expertise. There are known-unknowns. The relationship between cause and effect needs analysis or knowledge. In this domain, you sense, analyze, and then respond, applying the appropriate good operating practice. There is good practice here, but there is no best practice. As it is non-trivial, there is still room for improvement, to eliminate waste, to improve quality, and to optimize flow.
For example, an IT firm installing servers in a datacenter; an automotive manufacturer building cars; an investment bank trading and processing equity trades; the HR department onboarding new employees. These activities are knowable because they’ve all been done many times before; however, the work requires expertise, especially when things go wrong. Even then, the failure patterns have been experienced before. This is ordered, repetitive, knowable activity. This is the sweet spot for lean.
Complex: Sweet Spot for Agile
Unique product development takes place in the Complex Domain. This is where there are unknown-unknowns and acting in the space changes the space. Cause and effect can only be deduced in retrospect. Whereas the previous two domains are ordered, this domain is unordered. There is no such thing as best practice or even good practice because activity in this domain is emergent. The best approach here is to probe by running a safe-to-learn experiment to test a hypothesis, to sense the results, and then to respond by amplifying or dampening the experiment.
In the Age of Digital, all software development is unique. You don’t write the same code twice. People don’t know what they want until they see it. You don’t know how you’re going to write it until you’ve written it, and then it needs to be refactored as you realize how it could have been written to be more usable, maintainable, or resilient. Even installing a third-party application, such as an ERP system, is novel: that code has never been installed in that context with those data feeds, those people, and those processes before. Minimizing time to learning is key; fast feedback loops de-risk delivery and enable optimizing for outcomes. This is the sweet spot for agility.
Chaos: Act First
Sometimes decisions have to be made in a domain that is “chaotic.” Knowledge here is less important than rapid action that returns order. We act to establish order, to stem the bleeding; sense where stability lies; and respond to turn the Chaotic into Complex. Like the Complex domain, this domain is also unordered.
The global COVID-19 pandemic is a good example of this domain. With mandated lockdowns in force globally and people required to stay at home, organizations scrambled remarkably quickly to act. That could have been to open up more network connections to enable huge numbers of people to work from home, or in industries such as aviation, automotive, and hospitality to shut down operations, or supermarkets and suppliers working to keep the supply chains operating. There was no time for months of planning and multiple committee-based approvals. Organizations often comment that they are at their best in these situations, with people coming together, irrespective of job role or business unit, working as one multidisciplinary team to quickly address the issue. Most then go back to their previous ways of working. Techniques stumbled upon in Chaos can end up becoming a new good or best practice in the Complicated or Clear domains for business as usual.
Confused
The last of the domains in the Cynefin framework is Confused, when it’s not clear which of the domains currently apply. This can be authentic (you’re really not sure, in which case break the situation down into smaller parts) or inauthentic (which means that you are complacently ignoring any distinction and carry on managing Complex situations as if they were Complicated or Clear).
Work Moves Around Domains
Work is rarely stationary in one domain. For example, the creation of a new product, such as a new model of car, will start in the Complex domain. In an agile manner, there will be customer focus groups, pencil sketches, computer-aided design (or “digital twin” simulation), and eventually a small-scale prototype and wind tunnel testing for quickest time and cheapest cost of learning, avoiding a sunk cost fallacy. At some point there will be a full-size prototype and eventually testing in the extremes of the Sahara and Alaska, all the time making updates to maximize the desired outcomes. Later 100,000 instances of that model are built each year, which is into the Complicated domain. Then there is a shallow dip into Chaos with a recall of certain models due to a fault, some Complex domain experimentation to fix it, and then back into Complicated domain with lean production.
Software benefits from both an agile and lean approach. The software binary is agile-created and the path to production is lean, as the build, test, deploy process should run repetitively and with a high degree of automation many times a day. Periodically there will be step-change agile experimentation in the path to production and then back into lean again. Software is an agile-created box on a lean conveyor belt.
by Jon Smart, 11/10/22