Kanban Deployment with the X-Matrix

This is a continuation of my musings on Strategy Deployment, the X-Matrix and Kanban Thinking (including Strategy Deployment as Organisational Improv and How Do I Know If Agile Is Working). I’ve been thinking more about the overlap between Strategy Deployment and Kanban and come to the conclusion that the intersection of the two is what could be called “Kanban Deployment” [1].

Let me explain…

To begin with, the name Strategy Deployment describes how a centralised decision is made about strategy, which is deployed such that decentralised decisions can be made on defining and executing plans. The people who are engaged at the coal face are the people who are most likely to know what might (or might not) work. In other words its the strategy that is deployed, not a plan.

Similarly, Kanban Deployment can be used to describe how a centralised decision is made about kanban as an approach to change, which is deployed such that decentralised decisions can be made on defining and executing processes. Again, the people who are engaged at the coal face are again the people who are most likely to know what might (or might not) work. Its kanban that is deployed, not a process.

With this perspective, we can look at how the X-Matrix could be used to describe a Kanban Deployment in terms of Kanban Thinking. (For a brief explanation of the X-Matrix see a post on how we used the approach at Rally).

The Results describe the impact we want the kanban system to have, and the positive outcomes we are looking to achieve with regard to Flow, Value and Potential. Just like with ‘regular’ Strategy Deployment, an economic model as recommended by Don Reinertsen is likely to provide clues as to what good results would be, as will a good understanding of fitness for purpose.

For Strategies we can look to the Kanban Thinking interventions of Study, Share, Stabilise. Studying the system is a strategy for learning more about the current context. Sharing knowledge is a strategy for creating a common understanding of the work and the way the work is done. Stabilising the work is a strategy for introducing policies which will enable and catalyse evolutionary change.

The Indicators are equivalent to the Kanban Thinking intervention Sense. These measures of improvement, while proxies, should give quick and regular feedback about whether the kanban system is likely to lead to the results.

Lastly the Tactics are equivalent to the Kanban Thinking intervention Search. These are the specific practices, techniques and policies used as part of the experiment that are run. The Kanban Method core practices can also provide guidance as to what tactics can be used to design the kanban system.

While I’m not sure I would want to be overly rigid about defining the strategies, I find the X-Matrix a useful model for exploring, visualising and communicating the elements of a kanban system and how they correlate to each other. As with all tools like this (i.e. A3s) its not the template or the document that is important, its the conversations and thinking that happen that have the value.

[1] I did consider the name “Kanban Kanri” for the alliteration, but apart from preferring to minimise Japanese terminology, it’s probably meaningless nonsense in Japanese!

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Insights from a Kanban Board

Donkey DerbyI was working with a team this week, part of which involved reviewing their kanban board and discussing how it was evolving and what they were learning. There was one aspect in particular which generated a number of insights, and is a good example of how visualising work can help make discoveries that you might not otherwise unearth.

The board had a “On Hold” section, where post-its were collected for work on which some time had been spent, but which was not actively being progressed or had any expectation to be progressed, and which wasn’t blocked in any way. Quite a lot of work had built up in “On Hold”, which made it an obvious talking point, so we explored what that work was, and why it was there. These are the things we learnt:

  1. Some of the work wasn’t really “On Hold”, but were really requests which had been “Assessed” (the first stage in the workflow) and deemed valid and important, but not urgent enough to schedule imminently. This led to a discussion about commitment points, and a better understanding of what the backlog and scheduling policies were. In this case, items were not really “On Hold”, but had been put back on the backlog. In addition, a cadence of cleaning the backlog was created to remove requests that were no longer valid or important.
  2. Some of the work was “On Hold” because while it was valid and important, the urgency was unknown. It was an “Intangible” class of service. As a result it was always de-prioritised in favour of work where the urgency was clearer. For example work to mitigate a security risk wasn’t going to be urgent enough until the risk turned into a genuine issue which needed resolving. To avoid these items building up, and generating even greater risk, a “Donkey Derby” lane was created as a converse of their “Fast Track” lane. Work in this lane would progress more slowly, but at least there would always be at least one “Intangible” items in process.
  3. A very few items were genuinely “On-Hold”, but they were lost amidst the noise of all the other tokens. Thus any discussion about what to do, or what could be learned, was being lost.

In summary, by visualising the “On Hold” work (however imperfect it was), and creating a shared understanding, the team were able to improve their knowledge creation workflow, better manage their risk and increase their ability to learn from their work.

VN:F [1.9.22_1171]
Rating: 5.0/5 (3 votes cast)

Draft Kanban Canvas User Guide


This is an initial draft for brief guide to how I use the Kanban Canvas, building on the recently posted Prezi. It will eventually be added to the main Kanban Thinking site. Generally, I use the canvas as the core of a two day workshop, during which I use it to facilitate the collaborative co-creation of a kanban system. The canvas becomes a single, simple artefact which captures a common understanding of how a system is designed, and why it is designed the way it is.


1. First we begin with understanding the scope and purpose of the System. I’m looking to discover key people, problems, frustrations, boundaries and interfaces. I like to get participants to tell their story leading up to the present day, explaining why they are in a room together designing a kanban system.

The output in this section is one or more a simple narratives capturing the essential system elements and interactions.


Next, we need to be able to assess whether any changes we make are improving or deteriorating the systems fitness for purpose. The goal is to be able to describe the general direction we want to go in, without identifying any specific outcomes or end states.

2. We explore various ways we might want the story to end – and what endings might we want to avoid. I ask participants to imagine impossibly good and bad endings – utopian and dystopian futures – using the three Impacts of Flow, Value and Potential to help them look from different perspectives. They are not distinct impacts, but more like triads, where elements of all three could be involved. This generates healthy conversations about how the potential futures relate to the different impacts.

The output across these three sections is a set up potential endings, placed relative to where they have most resonance. Colour coding is used to distinguish between the utopian (green) and dystopian (red) futures.


Now we have a good understanding of the recent past and desired future direction, we can begin looking at how we can start interacting with the system to make interventions which we hope will have a positive impact.

3. To really understand how we can make effective change, we first need to Study the context. There are 3 areas that I find it useful to study; the customer or stakeholder, the work demand that comes from them, and the way that demand is processed. We usually start by looking at demand, and the group applies concepts such as value and failure demand, the CORE Profile and Classes of Service. Then we’ll explore where that work comes from with a technique such as Empathy Mapping, and how that work is processed with a variation of Value Stream Mapping focussing on the flow of information and its discovery.

The output in this section is a set of sticky notes capturing a summary of customer/stakeholder needs, demand classifications and classes of service, and primary workflow states, transitions or delays.

4. Once we have a good common understanding of the existing context, then we can Share it by visualising our knowledge on a kanban board. First I ask the group to discuss and agree which information is most relevant and important for them to share – trying to show everything will just create noise. Then I introduce the Token, Inscription, Placement concept as a way of thinking about board design patterns, and the group comes up with approaches to visualise their important information.

The output in this section is a set of mappings between each important informational dimension to be visualised, and the visualisation technique to be used.

5. The next step is to begin to Stabilise the current system by introducing explicit policies. These policies will form flexible boundaries to contain the work. Boundaries which are too hard and fixed will lead to rigid bureaucracy, while boundaries which are too loose will lead to chaos. I introduce Work In Process limits as a core policy type, and we explore the various strategies and techniques for introducing and setting WIP limits. Then the group brainstorms some simple quality checklists to agree how and when work should progress across the board. These simple, standard work definitions become the baseline for future improvements.

The output in this section is a set of decisions regarding basic WIP limit strategies and allocations, and bullet points for initial entry/exit criteria on the board.

6. As a system is put in place and evolves, we need a way to Sense its capability in order to assess its fitness for purpose. The two primary means for this are measures and meetings. First, groups decide which outcomes they hope will have a positive impact, typically selecting from productivity, reliability, responsiveness, quality, customer satisfaction and employee engagement. Metrics are discussed and defined for these outcomes, considering the anticipated behaviour and consequences, and potential tradeoffs with other outcomes. Then groups decide what meetings and cadences they would like to use to give them an ongoing rhythm for assessing capability and progress.

The output in this section is a set of simple metrics definitions, and a list of meetings and respective cadences.

7. Finally, the evolutionary potential of the system is explored by beginning a Search for alternative designs. Given everything that has been discussed so far, the groups begins to define small experiments that could be run on possible changes. Each experiment has a hypothesis, a rationale, measures to both validate and falsify, and a mechanism for ensuring safety and reversibility.

The output in this section is a set of initial simple experiment definitions which can be run.

All of this is done in a very collaborative way, using various facilitation techniques to ensure everyone is able to contribute, different opinions are heard, and consensus is reached. At this point, the group is able to begin learning, evolving and improving their kanban system using the canvas as a basis.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Kanban Thinking: The Canvas

Kanban CanvasLast week, at SparkConf, I announced a new website for Kanban Thinking, which is where I will add new material in a more structured way (I’ll continue to blog ideas here in an un-structured way!). The primary new piece is what I’m calling a Kanban Canvas – a sheet designed to be printed on A0 paper and used to collaboratively explore the model when designing a kanban system.

The canvas is built around the heuristics and related questions, with the goal being to co-create a design by exploring and answering the questions. You can see some more on this in the SparkConf slides below. Please visit the new site, download the canvas, and let me know your experiences.

And of course, let me know if you would like me to help facilitate your work!

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Announcing The Lego Flow Game

I have just published a page for the Lego Flow Game – a new game that I have co-created with Dr. Sallyann Freudenberg. Its based on an ‘experiment’ I originally ran in 2010 at the SPA conference. Then I used an exercise of matching, solving and checking equations to explore and experience workflow with different types of processes and policies. While this worked in terms of having a game that consisted of knowledge work, it turned out to be painfully tedious and hard work, which detracted from the main learning objectives. Sal was in the audience that day, and took the concept and evolved it by swapping in Lego building instead of the mathematics. We’ve run the updated version a few time over the last 6 months or so, and made some tweaks to the rules and timings, and we’re pretty happy with the latest version – hence publishing it.

The most recent outing was at the Kanban Coaching Exchange in London last week. It was pretty chaotic with around 50 people attending in a relatively small space, and only 3 full kits – we need to stock up on staplers! That meant that there were lots of observers – if you were there, we thank you for your patience. It didn’t help that we were also missing the right cable to connect a laptop to the TV in the room, so we had to explain the exercise without any supporting slides, and I had to show the end-result Cumulative Flow Diagrams by holding my laptop over my head. Given all that, there seemed to be high energy, good discussion and overall the feedback seemed positive. If we can run the exercise successfully in that environment, then it’ll probably work in most situations!

You can find the full instructions on the main page – please let us know if anything isn’t clear. You’ll also find the slides and spreadsheet to go with the exercise there. There are some photographs from the Kanban Coaching Exchange session on the event page and I’ll add any others that I come across here as well.

Here are the final spreadsheets for the 3 teams. I’ll briefly describe what I interpret from one of them (team 1).

Round 1 is a ‘waterfall-like’ process, or batch and stage. In other words, the work flows through the process in a single batch, one stage at a time. You can see the work build up in the Analysis stage until all 5 are complete, and then moved together into Supply stage, and then Build, where the team ran out of time. Thus no items were completed. The debrief of this round mentioned that the person working felt very pressured, while everyone else was very relaxed. Waterfall is great if you’re not the critical path – and you don’t care about getting anything done!

Team 1 Batch CFD

Round 2 is a ‘scrum-like’ process, or time-boxed, with 3 x 2 minute ‘Sprints’. The time-boxes themselves are not obvious from the CFD, but its clear that there is some more flow, even if it is fairly ragged. One item is completed in the the first time-box, but the team estimated, and started four items. However, they must have learned from this, because they didn’t start anymore work in the second time-box (between minutes 2:00 ad 4:00) and they completed one more item on this time-box. For the final time-box, they decided to start one more item, and complete 2 more. If they had seen the data and the graph (I didn’t show anything until the end) they might have realised that it probably wasn’t worth starting anything in the final time-box either. Four items were completed in total. You can also start to see some predictability at the end as the built in retrospective cadence generated learning and improvement in how much work the team took on. The debrief discussed how this round tends to feel fairly chaotic with strong focus, punctuated by the retrospectives.

Team 1 Timebox CFD

Round 3 is a ‘kanban-like’ process, or purely flow-based with WIP limits. The flow is much smoother this time, and the WIP limit of 1 in each stage is clear. The slope of the graph is also fairly smooth, and its would probably be fairly easy to predict the future performance of the team. Five items were completed at almost one per minute. The debrief discussed how this round tends to be more relaxed, with a more gently hum of activity.

Team 1 Flow CFD

I hope this is useful in getting a feel for how the game works, and making it possible to run the game yourself. Please try it for yourself and let us know how you get on. In particular Sal and I would love to hear about modifications you make, or what other policies you experiment with.

VN:F [1.9.22_1171]
Rating: 5.0/5 (2 votes cast)

Visual Management – Creating A Kanban Multiverse

This is an article I originally wrote for the Management 3.0 site in 2010. As it is no longer available there, I am republishing it here in its original form other than a few minor edits.

At the Lean and Kanban Exchange in London in 2009, I was chatting with David Anderson and David Laribee about the possibilities for Kanban software tooling, and how a great piece for software could enable the visualisation of multiple dimensions within a two dimensional space. The right application could allow easy shifting between multiple perspectives to give different views on the various dimensions. This got me thinking, and led me to the concept a multiverse. This post is a write-up of the presentation I was due to give at the Lean Software and Systems Conference in Atlanta, before Eyjafjallajokull intervened. The associated Prezi can also be found on my blog.

Wikipedia defines as multiverse as “the hypothetical set of multiple possible universes that together comprise everything that physically exists: the entirety of space and time, all forms of matter, energy and momentum, and the physical laws and constants that govern them”. How does that map onto the concept of a kanban board? A kanban multiverse could be “the hypothetical set of multiple possible kanban boards that together comprise everything that physically could be visualised: the entirety of scope and time, all forms of work type, status and flow, and the organisational laws and constants that govern them”.

What would make a great kanban board to create this kanban multiverse? That led me to look into ideas around visual management and data visualisation, and think about what the data variants might be that could be visualised.

Visual Management

In a TED Talk Tom Wujec talks about 3 ways that the brain creates meaning. Firstly, visualisation creates a mental model because of the way that different areas of the brain process different visual inputs such as shape, size, and location. The greater the readability of a kanban board, the greater the impact of this visual processing. Secondly, interaction enriches the mental model further through engagement. The greater the usability of a kanban board, the more it will be interacted with. Finally, persistence allows the mental model to be part of an augmented memory which can evolve over time. The greater the visibility of a kanban board, the more accessible it will be as augmented memory. Thus kanban boards become such powerful tools when they create mental models through being visual, interactive and persistent.

This leads to the idea of boundary objects. Brian Marick wrote an introductory paper in which he talks about communities and practice and interest. A community of practice is formed around a work discipline, while a community of interest is formed around a common problem or concern. Communities of interest are made up of members of different communities of practice. A boundary object provides a means for communities of interest to communicate across their different practices, and a kanban board, through creating a shared mental model, can be a boundary object. This is because the mental model is created collectively and collaboratively, and helps clarify the meaning of what the board is representing.

Brian lists several properties of a boundary object which can be useful to bear in mind when building a kanban board; it should be a common point of reference for the community of interest, represent different meaning to different members of the community and help translation between the meanings, support coordination and alignment of the work within the community, be a plastic working agreement which evolves with the communities practices, and address different concerns of the community members simultaneously.

Another relevant set of ideas to visual management are those raised by Dan Pink when he talks about the surprising science of motivation. In his book Drive he says that rather than the carrot and stick approach of extrinsic motivation, a better approach is intrinsic motivation, which consists of three elements; autonomy, mastery and purpose. Autonomy, or the “desire to direct our own lives”, is achieved when team members can see what needs doing, understand the working agreements, and choose what they should do. Mastery or “the urge to get better and better at something that matters” is achieved through being able to interact with the kanban board to evolve and improve it. Purpose, or “the yearning to do what we do in the service of something larger than ourselves”, is achieved when the persistence of the kanban board makes it clear what the value of the work is and why it is being done.


In his classic book “The Visual Display of Quantitative Information”, Edward Tufte introduces a set of principles for the effective display of data. Given that a kanban board can visualise multiple pieces of data, it is useful to review some of these ideas.

Tufte talks about a number of different types of graphical designs. Time series is probably the most common, where time is along the horizontal axis, and another data type along the vertical. This is probably the least relevant design, because a kanban board is typically a snapshot of the current status. Similarly, a space time narrative, which tells a story in a spatial dimension over time, may not be the most obvious choice. It does raise the question of visualising the narrative of the work over time though, which could be interesting. Maps also introduce some different ideas. What would a kanban board look like it showed the terrain of a project, and where each piece of work was on that terrain? The most common form kanban board is probably a relational one, where the two axes show different types of information, such as scope and status. Tufte refers to relational graphics as being more sophisticated and interestingly, from a Lean and Toyota perspective claims that Japanese publications tend to have more sophisticated graphics.

Most of the book is spent discussing ways of improving the way that data is presented; specifically, maximising data ink, reducing chart junk, and improving data density. Data ink is the ink that actually represents data. While kanban boards generally use more than just ink, the principle holds true for making sure that as far as possible, anything on the board should hold information. The corollary to this is that anything which isn’t data ink is chart junk. Grids, redundant data, or decorations and embellishments for aesthetics may create noise which masks the real story. Finally, data density is the amount of data within the given space. The eye can take in a high precision of detail, so by maximising the data ink and being clever with multi-functioning graphical elements, it is possible to visualise many dimensions in a small space.


This leads us to the decision of how we can represent a kanban multiverse. Each dimension that can be visualised is what Edward Tufte calls a variant, and a kanban board is a multi-variant display. What are the variants, and how can they be displayed, using maximum data ink, minimum chart junk, and at a greatest density? This post will not provide the answers, but will I hope provide some ideas for thinking about some alternatives and creating innovative solutions.

The variants will typically be the usual project management interest, but can include the concerns of any member of the community of interest. As a starter, there are the popular “iron triangle” variants of scope, time, resource and quality. Other common variants are things like priority, status, issues, risks, constraints, dependencies and assumptions. More recently, teams have been talking in terms of variants such as capacity and demand, not to mention value and other economic points.

To visualise all these variants we can use a number of techniques. Properties such as size, colour, format, location and alignment can all create multi-functioning graphical elements to achieve a high data density. For a physical board, material and texture can add further depth. What would the implications be of showing quality with colour, or dependencies with material?


A kanban board is more than simply a task board, or a story board, or even a team board. It’s a visual management tool to create a shared mental model amongst a community of interest. As such, sophisticated display techniques should be used to create meaning and motivation through collaboration and communication.

Thanks to Xavier Quesada Allue who has written much more about techniques for creating kanban boards on his Visual Management Blog, and who I have had many interesting conversations about ideas for creating kanban boards.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Limiting WIP? Or Containing the Work?

I’ve thought for some time now that WIP limits are a special form of explicit policy – one that is called out specifically because it is a core concept behind kanban systems. That has made be uncomfortable with the third Kanban Thinking heuristic; “Limit (with Policies)”. Limits and policies are a means to an end. What is that end (other than the over-arching goal of making in impact)? Further, all the other fuller versions of the heuristics are of the form “<verb> the <noun>”.

  • Study the Context
  • Share the Understanding
  • Limit with Policies
  • Sense the Capability
  • Explore the Potential

We define WIP limits and explicit policies in order to create a boundary within which the system can evolve, and which allows self-organisation to happen. Thus they create a container for the system. That leads to the heuristic “Contain the Work”, which covers both WIP limits and explicit policies.

I also like the notion of containing rather that limiting for another more subtle reason. Limiting, to me, implies applying an external pressure in order to reduce WIP. I used to think this was a good thing, but now consider WIP limits to be an economic choice – too little WIP can have a negative impact if it leads to throughput becoming too low, or a portfolio with not enough variety. Containing, on the other hand, implies a different dynamic where we are trying to resist internal pressure in order to avoid WIP getting out of control.

This all might be semantics! I’d love to get feedback on this alternative to talking about limits. What does “contain the work” suggest to you? What other alternatives would you suggest?

VN:F [1.9.22_1171]
Rating: 3.7/5 (3 votes cast)

Kanban Values, Impacts and Heuristics

A recent thread discussing the values behind kanban on the kanbandev mailing list inspired a couple of great blog posts by Mike Burrows on “Introducing Kanban Through Its Values” and “Kanban: Values Understanding And Purpose“, which have in turn inspired me make some updates to the Kanban Thinking model.

The key points for me in Mike’s second post are these. First,

We often say what the Kanban method is (an evolutionary approach to change) without saying what it is actually for! Change what? To what end?

and then,

The Kanban method is an evolutionary approach to building learning organisations.


I have a different take on the values discussion and how they help answer the question “to what end?” I’ve come to the view that articulating values is not a useful exercise because they often end up being things that anyone could espouse. One alternative is to use narratives and parables to describe the values in action. With Kanban Thinking, I prefer to talk about the desired impacts of a kanban system. Knowing what impact we want the kanban system to have, and how to measure that impact, will inform our system design decisions.

Thus, in answer to the question “to what end?”, Kanban Thinking suggests 3 impacts; improved flow (demonstrated in terms of productivity, predictability or responsiveness), increased value (demonstrated in terms of customer satisfaction, quality or productivity) and unleashed potential (demonstrated in terms of employee satisfaction, quality or responsiveness).


Mike suggests that the purpose of a kanban system is to learn, and in light of the above, that would be to learn how best to have maximum impact. Up until now, I have talked about five leverage points (or levers) on a kanban system, with Learn being one of those levers. As a result of the insights I had from Mike’s post I have switched to referring to those five elements as heuristics rather than levers, with the fifth heuristic changed from Learn to Explore.

This is one definition of heuristic:

involving or serving as an aid to learning, discovery, or problem-solving by experimental and especially trial-and-error methods.


of or relating to exploratory problem-solving techniques that utilize self-educating techniques (as the evaluation of feedback) to improve performance

Thus, the five (updated) heuristics of Study, Share, Limit, Sense and Explore help with the learning about a kanban system in order to have the desired impacts of improved Flow, increased Value and unleashed Potential.

Exploration is a more active description of what I originally intended by Learning as a then lever. Exploration requires curiosity (another value suggested by Mike) and experimentation to try things out, observe the results, and amplify or dampen accordingly.

That leaves the updated Kanban Thinking model looking like this:


VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Three Kanban Reminders

I seem to have had a number of conversations recently which have all had some common themes. The general pattern has been that someone wants to talk about Kanban and let me know how its not working for them in some way. When I enquire further, and dig into the background some more, I’ve found that there are generally 3 things missing or misunderstood.

  1. You still need discipline. I hear of teams who find traditional agile practices difficult, for various reasons, some which may be valid, and some which may not. They decide to drop those practices, which may or may not be due to a lack of discipline. Dropping those practices, and just keeping the board, does not mean they have a Kanban System. In fact, if the board doesn’t have WIP limits, its not really even a Kanban Board! Whether or not teams have the discipline to follow their original process, they do need to have the discipline to define their own process by creating explicit policies.
  2. You still need cadence. The most common instance of a dropped practice that I hear is that of the time-box. The complaint is then that the team loses their rhythm, and that they have nothing to give them short term focus. They lose their sense of capability. What they have done is gone from a tightly coupled metronomic cadence, to an asynchronous, random and imperceivable cadence. There is a middle ground of a loosely coupled, poly-rhythmic cadence which is more resilient to the nature of their work, yet provides an ability to sense. As described above, it takes discipline to define this cadence.
  3. You still need people. The last misconception is that a Kanban-based approach is removing people from the equation again by trying to simply optimise the current process. Personally, this is why I talk about increasing Potential as one of the impacts we want a Kanban System to have. The potential of a system – its ability to improve over time – is grounded in the human potential of the people who are a fundamental part of the system. Its the people, and their connections and collaborations, who are best placed to know how to change the system for the better now, and be able to continue to change the system as the landscape changes.

I believe that attendees at the recent Kanban Leadership Retreat in San Diego were having similar experiences and I saw on twitter that the phrase “there’s a lot of sh*t out there” was used! This is partly why I came up with the Kanban Thinking model. As I alluded to when I talked about Cargo Cult Kanban, the Kanban community is not copying Toyota’s Kanban implementation tool, but the thinking behind it. If you trying a Kanban-based approach and its not working, think about why, identify something to change, and run an experiment. See, its not really that different to Agile!


VN:F [1.9.22_1171]
Rating: 5.0/5 (3 votes cast)

Understanding Change with Cynefin

I have written a number of posts on systemic thinking, which I believe is at the heart of Kanban Thinking. I’m currently referring to systemic thinking, rather than Systems Thinking, in order to try and avoid any confusion with any particular school of thought, of which Systems Thinking could be one. I have also written an number of posts on Cynefin. This post brings the two together.

Understanding Systems

Being able to start thinking systemically is not easy, because there are different types of system, and each requires a different approach to working within them. Dave Snowden has developed a framework known as Cynefin, which is a useful way of understanding some of the differences, and the implications of those differences.



Cynefin is a Welsh word, which translates as “place of our multiple affiliations”. Snowden describes it as a multi-ontological sense-making framework. The multi-ontological aspect refers to the fact that there are different types of system, all of which are may be valid for different contexts. The sense-making aspect refers to the exercise of gathering data before creating the framework, as opposed to categorisation where a framework is created first and onto which data is subsequently placed. In practice, this means that examples are first gathered first and placed relative to each other based on some criteria, and then boundaries are then drawn in order to understand the relationships. This allows the emergence of a framework that might not otherwise have been identified.

System Domains

Cynefin has five domains; two ordered, two unordered, and one of disorder.

On the right hand side are the ordered domains simple and complicated. These are ordered because there is a direct relationship between cause and effect. Causality is known and clearly perceivable, predictable and repeatable for simple problems, or it is at least knowable, although less obvious due to separation in time and space, for complicated problems. As a result we can immediately get a sense of the situation first, before categorising or analysing, in or to decide how to respond with best or good practice.

On the left hand side are the unordered domains complex and chaotic. These are unordered because of the ambiguous relationship between cause and effect. Causality may be retrospectively coherent, but not repeatable for complex problems, or simply incoherent and not perceivable at all for chaotic problems. As a result we need to probe with experiments or act quickly and assertively before we can get a sense of the situation in order to know how to respond.

In the centre is the domain of disorder. This is where we are unsure what type of problem we are dealing with and as a result are likely to respond instinctively with our preferred approach rather than the one appropriate for the situation.

The Cynefin framework, and in particular its distinction between ordered and unordered systems, is useful in understanding two common ways of dealing with change.

Managed Change

On the ordered side, in the simple and complicated domains, we can take advantage of expert and common knowledge, using best and good practice, to define a desirable future state, and the work to close the gap from the current state.

This is the approach generally taken by managed change programs, which put together teams, define roadmaps and create backlogs of work to implement in order to complete the change. This is a perfectly valid approach when the system really is ordered, and not incompatible with Kanban Thinking. A future state Kanban System can be designed, with pre-determined work types and workflow, and an appropriate visualisation, WIP limits and other policies. Metrics can be gathered, but learning may be minimal because of the assumption that the correct solution can be known in advance. However, while short term results may be achieved, there is also the risk that the chosen practices being implemented are not appropriate, or get followed blindly and dogmatically, with the long term result being a fall over the cliff into chaos as already described.

Evolutionary Change

On the unordered side, in the complex and chaotic domains, we need to be more experimental, using emergent and novel practice, to understand the current state and discover its evolutionary potential. The author John Kay describes this approach as being one of Obliquity in his book of the same name. Similarly, Tim Harford discusses the need for a variety of experiments, resilience to the possibility of failure of those experiments, and clear selection of which experiments to kill or continue in his book Adapt.

This is the approach that really harnesses the power of Kanban Thinking. A Kanban System can be designed to represent the current state with existing work types and work flow, an appropriate visualisation  conservative WIP limits and other policies. Metrics can be used to further understand the current state and adjustments can be made to the work, its flow, visualisation and policies in the form of intentional experiments, run to learn how to evolve the system for greater impact. A more suitable system design is likely to emerge this way than could be envisaged up front, although there is the risk that the improvement could be achieved more quickly using expert guidance.

Domain Dynamics

What becomes interesting with Cynefin is not the classification of whether something is simple, complicated, complex or chaotic, but how situations transition between the domains and across the boundaries. No domain is considered to better than the others because each is contextual. Moving from the complex to the complicated domain may be appropriate when optimising or exploiting a solution. Conversely, moving from the complicated to complex domain may be appropriate when wanting to innovate or explore an idea. Occasionally a short and shallow dive through chaos into complexity might be appropriate for more radical changes. A key transition to be aware of is the one from the simple to chaotic domain. This results from complacency and over reliance on best practice, which pushes problems over the cliff into chaos. This transition is known as a cliff, and represented differently by the squiggle, because recovery is a non-trivial and costly process.

Use of the domains can be further confusing because often it is discovered that scenarios may be in multiple domains at the same time because elements of it live in a different domains. Narrative fragments, in the form of short anecdotes, are a common and useful form for capturing the examples and identifying and understanding the differences. Taking coding as an example, someone could tell a story about learning a new language, which might be a simple problem with best practice about syntax and coding styles. At the same time, someone else could tell a story about using Test Driven Development with that language as a good practice for a more complicated challenge of detailed design and development. Yet another person could tell a story about using spikes to experiment with a complex feature which requires the emergence of an innovative new design and architecture. Finally, a further person could tell a story about dealing with the chaos resulting from having to react to defects found in some legacy spaghetti code.

So What?

I have found that having an understanding of these different system domains, and their dynamics, to be useful in guiding my approach to taking action when working to  help organisations change and improve their system. While my experience may often lead me to believe I know the answer, there are times when there is no right answer, and sometime the answer is not even knowable. By helping others discover the answer for themselves, they are able to both get to a better place now, and be better positioned to be able to discover new answers for themselves in the future.


VN:F [1.9.22_1171]
Rating: 5.0/5 (4 votes cast)