Strategy Deployment, Foxes and Hedgehogs

Graffiti artwork to visulasise foxes and a hedgehogs. A fox is sitting down in a forest looking to the left. Behind it is a hedgehog also looking to the left.

I recently came across the idea of foxes and hedgehogs in a Cautionary Tales podcast episode. It has inspired this post in my occasional series on Strategy Deployment and other ideas. Isaiah Berlin popularised the metaphor in an essay and subsequent book, which is based on an excerpt from a classic poem from ancient Greece.

“The fox knows many things, the hedgehog knows one big thing”.

Archilochus

Subsequently, numerous authors and academics have referenced it, including Philip Tetlock in his work on Superforecasting.

What are foxes and hedgehogs?

Telock argues that so-called experts can be considered to be hedgehogs, and are generally wrong in their predictions. Meanwhile, superforecasters can be considered to be foxes and are more likely to be correct in their predictions. The difference between the two types of people is that foxes explore many options and possibilities and are more likely to change their minds. However, hedgehogs focus on one big idea that they think is the right one and therefore don’t change their minds.

Why is this relevant?

While this distinction between two types of people is clearly an oversimplification, it does resonate with me. From a Cynefin perspective, hedgehogs tend to think the world is ordered (clear or complicated). Foxes tend to think the world is complex. Cynefin as a sensemaking framework is designed to recognise that there are different domains, that they are all equally valid in context, and that they require different approaches. In the same way, the analogy of foxes and hedgehogs recognises that people have different preferences and tendencies and that they are both valid in context. Thus neither is right or wrong, and it’s even possible to apply the two approaches in combination.

What’s this got to do with Strategy Deployment?

Strategy deployment requires a mix of both fox and hedgehog thinking. The hedgehog brings a clear sense of direction, while the fox brings flexibility and options for progressing on the journey. Using the TASTE model, having a clear True North and Aspirations is a hedgehog attribute. Strategy as an enabling constraint can be thought of as a liminal state. It provides both a hedgehog’s focus with guiding policies and a fox’s freedom to allow solutions to emerge. Using Tactics and Evidence in a portfolio of experiments and bets is a fox attribute.

The X-Matrix brings all of these elements together such that the fox and hedgehog can work together coherently.

Strategy Deployment and Estuarine Mapping

Wyre Estuary representing Estuarine Mapping
Wyre Estuary

This is in part a follow-up to the two recent posts on a typology of tactics and the associated triads. I was initially inspired to write those posts while attending a series of training sessions on Estuarine Mapping. Having completed that training, I now want to reflect on what I learned and how it relates to Strategy Deployment.

Estuarine Mapping

First, a very quick review of the Estuarine Mapping process for context. For more depth, I’d recommend starting with this description by Dave Snowden, and this experience report by Tom Kerwin. There are three basic steps.

  1. Describe where you are now (the current state) using constraints and constructors. This generates a granular list of items that can be managed.
  2. Visualise these items in terms of the amount of time, and the amount of energy (resource, people, cost) required to make any changes.
  3. Decide which items to take immediate action on, and the type of action, based on that visualisation.

Insights

There were 3 key things that struck me about Estuarine Mapping:

  • It creates a collated view of both strategy and tactics. The positioning and clustering of items on the map inform a choice of ‘why’ to work on some things even over others (the strategy). At the same time, the chosen items represent ‘what’ work will be done (the tactics).
  • It’s a continuous process. There is never a final right answer, but there is an ongoing process of iteration and refinement. That happens across all three steps, and not necessarily linearly. Firstly, identifying and breaking down the constraints and constructors. Secondly, placing and moving them on the map. Finally, identifying and evolving the actions. I can imagine how an Estuarine Map might be a persistent artefact which is revisited and updated on a regular basis to explore what has changed and what the next actions should be.
  • It’s a collaborative effort. The level of engagement and conversation required to explore, identify and refine the elements in the various steps is extremely high. Further, a high diversity of participation will create richer discussions. However, even though it will be intensive and time-consuming, it will be well worth it given the deep insights and novel ideas generated.

Strategy Deployment

On the one hand, I think Esturaine Mapping is more about strategy “development” than “deployment”. The output is focused on identifying the strategic problems to be solved, as opposed to enabling the tactical solutions to emerge. On the other hand, given the collated, continuous and collaborative properties described above, I think it is a perfect fit for a Strategy Deployment. Additionally, Estuarine Mapping identifies many of the elements that can go on an X-Matrix. Specifically:

  • The choices of which items to take action on can easily be phrased as Strategies.
  • The actions themselves, with their types, naturally become Tactics.
  • Where actions require some indicator (e.g. monitoring, or conditional types), then those become the Evidence.

I’m looking forward to having the opportunity to explore Estuarine Mapping in more detail and I’m excited by the potential. Let me know if you’d be interested in being part of that!

Two Triads for the Terrific Typology of Transformation Tactics

Triads
Triads

I’ve joined an online training with Dave Snowden yesterday about his latest thinking on Estuarine Mapping. That is one of the ideas which inspired my last post on a Terrific Typology of Transformation Tactics. In particular, Estuarine Mapping uses two typologies with triads to “generate a list of things which can be managed” – constraints and constructors.

Estuarine Mapping Triads

I’m not going to go into any detail about those typologies here. I would recommend reading the latest posts from Dave on the subject. However, I will describe the general triad pattern Dave is using, and how it gave me a better idea of how to structure the typology.

A few thoughts on why I think this could be useful in relation to Strategy Deployment and the X-Matrix. I describe tactics are the “coherent action we will take”. Another way of saying that could be the “coherent things we will manage”, which is what Estuarine Mapping is designed to explore. Thus I’m curious how Estuarine Mapping can be a way of generating the Tactics. Given that, I wonder whether my typology of tactics might work as an alternative way of generating input for the exercise. On the one hand, the language might be more relatable. On the other hand, it might be too relatable in that preconceptions of the meaning behind those words might narrow people’s thinking.

Transformation Tactics Triads

A reminder of the typology:

  • People – related to roles or leadership
  • Plexuses – related organisational structures or networks
  • Processes – related to workflows or methods
  • Practices – related to techniques or skills
  • Products – related to customer or market deliverables
  • Platforms – related to enabling tools or technologies

Initially, I paired those up, into 3 sets of diads. However, the alternative pattern that Dave uses is to group them into two triads with an overarching diad. That could then look like this:

It’s not perfect, but I’m not sure it has to be. The goal is to trigger people into thinking about what coherent actions they might take, breaking them down into small enough (granular) tactics to decide what to do next and start running experiments.

How to use Hexis for Powerful Strategy Deployment

Hexis BAse Kit
Hexi Base Kit

This post is a follow-up to the list of 50 Quick Ideas To Improve Your Agile Transformation but from the perspective of Cynefin Company Hexis. I will describe what Hexis are, along with how I think they could be used as part of Strategy Deployment.

What are Hexis?

Hexis Method Kits are a product from Dave Snowden and The Cynefin Company. They are designed to enable the (re)combination of different methods, practices, tools, and techniques into new assemblies. Therefore, this allows unique solutions to be created for different contexts. A Hexi Kit primarily contains a set of hexagonal cards (the Hexis), each of which describes a single, granular unit within a body of knowledge. Further, there are pieces which allow overlaying an additional layer of information.

Currently, there are two kits available:

  • a base pack with core Cynefin methods and tools, and
  • an EU Field Gude kit based on the publication of the same name.

However, there are plans to create additional kits, including an Agile one based on Ivar Jacobson’s Essence. Dave and Ivar explain more in this meetup video on “Seeking vendor independent approaches to Agile and agility“. Moreover, there may be third parties who create their own kits. Together, this sets up the potential to create a rich ecosystem of ideas with which people can explore and discover new solutions to their challenges.

What has this got to do with Strategy Deployment?

My definition of Strategy Deployment is “any form of organisational improvement in which solutions emerge from the people closest to the problem“. Given that, I’m excited about the prospect of using Hexis as a way of helping those solutions emerge. The Hexis provide a way of starting with a set of known and granular options. However, a diverse group of people can combine them, and add to them, in their own way. Thus they provide a mechanism for the emergence.

In particular, when the Agile Hexis are available, they can help organisations discuss and design their own approaches to an agile transformation, rather than taking a pre-designed off-the-shelf one.

Given that, I’m excited about the possibilities for using Hexis. I’m looking forward to finding opportunities to use them and learning more about how to realise that potential.

What would Strategy Deployment Hexis be?

The possibility of creating third-party kits makes me wonder about a set of Hexis based on the X-Matrix TASTE model. This would help organisations to design their strategy deployment approach, as well as their agile transformation.

Thus, as well as a Hexi for the X-Matrix itself, there could be a set of “organising” Hexis for each element of TASTE. These would be similar to the EU Field Guide Stages of Assess, Adapt, [<>] (aporetic turn), Exapt, and Transcend for those familiar with that. That gives us:

  • X-Matrix
  • True North
  • Aspirations
  • Strategies
  • Tactics
  • Evidence

In addition, for each of those elements, there could be a set of related Hexis for various techniques or exercises. Consequently, these could be used to begin working out how to go about discovering what strategy deployment might look like. Given that, an initial brainstorm came up with this.

True North
Aspirations
Strategies
Tactics
Evidence
  • Leading / Input metrics
  • Flow Metrics
  • Catchball

There are plenty more ideas that could be included on my list of 50 Quick Ideas To Improve Your Agile Transformation. Furthermore, some of those don’t necessarily fit neatly into the above categorisation, which they don’t have to. However, this should give a high-level idea of how a Hexis Kit might be created which could include Strategy Deployment related concepts. Moreover, it should give a glimpse of how those Hexis could be used, in combination with others, to invite people to design their own agile transformation.

Option Orientation with Reverse Wardley Mapping

At the start of the year Mike Burrows posted about an idea he called Reverse Wardley, with some background to where it came from. As one of the sources of the idea I thought I should say some more about my thinking that led to it. Mike has also called the approach Option Visbility, and in writing this post I am preferring the name Option Orientation. Taking a set of existing options, and orientating oursleves with them such that we know how we should move next.

To explain the origins, lets first make a disctinction between sensemaking and categorisation.

  • Sensemaking is where the data precedes the framework. We position a set of data in a blank space, and then draw lines around it.
  • Categorisation is where the framework precedes the data. We draw lines in a blank space, and then position data between the lines.

Cynefin is intended to be a sensemaking framework, and exercises such as Four Points Contextualisation are designed to use it this way by placing items on a blank canvas, relative to the four corners, before any lines are drawn around them. The question that seeded the creation of Option Orientation is whether we can consider a Wardley Map to be a form of categorisation, in that data is added to a pre-defined evolutionary framework? And if it is, what would it look like to use a Sensemaking approach to create a Wardley Map? Hence the original name Reverse Wardley.

I should be clear that I am in no way saying that Wardley Mapping needs improving. Nor am I suggesting that sensemaking is any way superior to categorisation. Both are equally useful in context. These were just thoughts that occurred to me while listening to Dave and Simon talk at their “Snowden/Wardley Masterclass” last December.

I voiced these thoughts and discussed the questions with Liz Keogh, who came up with the idea of integrating with Agendashift. As I posted in the Agendashift Slack channel which Mike’s post references.

Liz and I have just figured out how to use Wardley Mapping to create the Transformation Map. Muwahahaha.

The basic idea is to take the FOTO outcomes that get used in 4-Points, and re-use them in a Wardley Map, so the Transformation Map is more of a Wardley Map than a Story Map.

Vertical axis is “distance” from the customer.

Horizontal axis is ambiguity of solution (which may or may not relate to the Cynefin domains)

I recommend reading Mike’s post for his interpretation of that quote and how he applied the thinking.

Here’s the way I have facilitated it.

  1. Rather than starting with a Blank Wardley Map and add the items starting from the top of the valeu chain (i.e. most visible) down, we start with a blank canvas, and an existing set of previously generated items (e.g. Agendashift outcomes)
  2. The items are first moved onto the hoizontal axis in order of relative ambiguity.  First I’ll ask for the most abmigious to be placed furthest left. Then for the least ambigious to be placed furthest righ. Then another random item to be placed relatively inbetween. Then another, and so on, until all have been placed realtively.
  3. The items are then moved vertically in order of visibility to the customer (which can generate a good discussion about who that is!). First I’ll ask for the most visible to be placed highest up, keeping its horizontal postion. Then for the least visible to be placed lowest down, still keeping its horizontal placement. Then another random item to placed relatively, and another, and so on, always maintaining the horizontal placement.

Now we have an Option Orientation Map such as the one below, which was generated with a Miro (aka Realtime) Board. Sorry that its (intentioanlly) not readable. The details are client specific, and it’s the overall look and effect that I hope is more useful.

Given something like the above we can now ask some questions about it:

  1. Which items would we like to move up/down/left/right? We can annotate this on the map with arrows to show desired movement.
  2. How do the items relate to each other? We can draw links between items to show relationships.
  3. Which items should we choose to work on? We can circle and name important groups or themes.

Thus the map gives us the context to make some strategic decisions on what needs to be done next as part of a continuous transformation effort, and can be revisited over time to re-align and renew direction.

Strategy Deployment and the Agile Industrial Complex

RozgwiazdaThere has been much debate online, and in particular on Twitter recently, about the imposition of Agile and the Agile Industrial Complex. See Ron Jeffries’ recent blog for more context. It’s an important topic. I have seen plenty of imposed Agile which I would call Incoherent Agile. Agile processes imposed as Best Practice without any coherence or alignment with the challenges that they are intended to be addressing. As a result the promised benefits aren’t realised, the people become demoralised and ultimately Agile is blamed.

I’ve refrained from getting directly involved the debate so far, but I do have a view, which I hope to explain here.

Lets first look at the idea of imposition. As usual, Cynefin provides a useful lens to look through with its four domains and associated forms of constraints.

  1. The Obvious domain has Rigid Constraints, which allow no freedom of choice
  2. The Complicated domain has Governing Constraints, which allow a little freedom of choice
  3. The Complex domain has Enabling Constraints, which allow a bounded freedom of choice
  4. The Chaos domain has No Constraints, which allow complete freedom of choice

When we impose something, we are effectively imposing constraints. Cynefin suggests that imposing no constraints will lead to Chaos, which we generally don’t want to happen (unless it’s an intentional, short and transitionary state). Thus imposition is not necessarily good or bad and it’s more important to consider the nature of the imposition in context, and whether we are imposing the right degree of constraint.

That leads to the question of what we are imposing in an Agile Transformation.

Much of the backlash against imposed Agile is a reaction to Agile imposed as a Governing or Rigid Constraint, where leadership decides which frameworks, processes or practices are to be implemented as the standard approach, leaving little or no room for variation or experimentation by the people actually doing the work.

This is exactly the sort of experience which led my interest in Strategy Deployment and the X-Matrix. It’s why I am a proponent of Agendashift and why I like the concept of the Engagement Model. I regard a Strategic approach to Agile Transformation as one where leadership sets Enabling Constraints, within which the solutions can emerge from the people closest to the problem.

Therefore, by choosing to use an Engagement Model, whether it be Agendashift, OpenSpace Agility or my own TASTE approach, I believe you are still imposing that Engagement Model on an organisation. The important distinction is that with an Engagement Model you are imposing Enabling Constraints. With Agendashift, those constraints have a strong focus on outcomes. With Open Space Agility those constraints come from the chosen theme or purpose. With TASTE, those constraints are defined by strategies and evidence.

All this means that we can impose Enabling Constraints, and invite people to participate within those constraints. That’s not to say that everyone should always be an agreeable participant. We don’t necessarily want everyone to be obedient and compliant. Engagement should allow for rebels and cynics to question the approach and keep everyone honest.

Much of the debate I have observed has been between Invitation as a force for good, versus Imposition as a force for evil. What I have hopefully shown is that the two are not mutually exclusive and that instead of arguing and fighting we should be working to help organisations impose the right levels of constraints and inviting people to collaboratively engage within them.

Measuring the X-Matrix

"Measure a thousand times, cut once"

Dave Snowden recently posted a series of blog posts on A Sense of Direction, about the use of goals and targets with Cynefin. As the X-Matrix uses measures in two of its sections (Aspirations and Evidence) I found that useful in clarifying my thinking on how I generally approach those areas.

Lets start by addressing Dave’s two primary concerns; the tyranny of the explicit and a cliché of platitudes.

To avoid the tyranny of the explicit, I’ve been very careful to avoid the use of the word target. Evidence was a carefully chosen word (after trying multiple alternatives) to describe leading indicators of positive outcomes. The outcomes themselves are not specific goals, and can be either objective or subjective. They are things we want to see more of (or less of) and should be trends, suggesting an increased likelihood of meeting Aspirations. Aspirations again was chosen to suggest hope and ambition rather than prediction and expectation. While they define desired results, those should be considered to be challenges and not targets.

To avoid a cliché of platitudes we need to focus on Good Strategy, beginning with the clear, challenging and ambitious Aspirations. I find it interesting that Dave cites Kennedy’s “man on the moon” challenge as a liminal dip into chaos, and Rumelt uses the same example as a Proximate Object source of power for Good Strategy. An ambitious yet achievable Aspiration helps focus on the challenges and opportunities for change. With proximate Aspirations, and a clear Diagnosis of the current situation, we can set some Guiding Policies as enabling constraints with which to decide what Coherent Action to take. Thus we can avoid fluffy, wishful, aimless or horoscopic Bad Strategy.

Put together, we have a set of hypotheses which are specific enough to avoid a cliché of platitudes, yet are speculative enough to avoid the tyranny of the explicit. We believe the Aspirations are achievable. We believe our Strategies will help us be successful. We believe our Tactics will move us forward on a good bearing. We believe the Evidence will indicate favourable progress. The X-Matrix helps visualise the messy coherence of all these hypotheses with each other and Strategy Deployment is the means of continuously testing, adjusting and refining them as we navigate our way in the desired direction.

Agendashift, Cynefin and the Butterfly Stamped

The butterfly who stamped

I’ve recently become an Agendashift partner and have enjoyed exploring how this inclusive, contextual, fulfilling, open approach fits with how I use Strategy Deployment.

Specifically, I find that the Agendashift values-based  assessment can be a form of diagnosis of a team or organisation’s critical challenges, in order to agree guiding policy for change and focus coherent action. I use those italicised terms deliberately as they come from Richard Rumelt’s book Good Strategy/Bad Strategy in which he defines a good strategy kernel as containing those key elements. I love this definition as it maps beautifully onto how I understand Strategy Deployment, and I intent to blog more about this soon.

In an early conversation with Mike when I was first experimenting with the assessment, we were exploring how Cynefin relates to the approach, and in particular the fact that not everything needs to be an experiment. This led to the idea of using the Agendashift assessment prompts as part of a Cynefin contextualisation exercise, which in turn led to the session we ran together at Lean Agile Scotland this year (also including elements of Clean Language).

My original thought had been to try something even more basic though, using the assessment prompts directly in a method that Dave Snowden calls “and the butterfly stamped“, and I got the chance to give that a go last week at Agile Northants.

The exercise – sometimes called simply Butterfly Stamping – is essentially a Four Points Contextualisation in which the items being contextualised are provided by the facilitator rather than generated by the participants. In this case those items were the prompts used in the Agendashift mini assessment, which you can see by completing the 2016 Agendashift global survey.

This meant that as well as learning about Cynefin and Sensemaking, participants were able to have rich conversations about their contexts and how well they were working, without getting stuck on what they were doing and what tools, techniques and practices they were using. Feedback was very positive, and you can see some of the output in this tweet:

I hope we can turn this into something that can be easily shared and reused. Let me know if you’re interested in running at your event. And watch this space!

Understanding SAFe PI Planning with Cynefin

3128266497_077f9144af_z

Within SAFe, PI Planning (or Release Planning) is when all the people on an Agile Release Train (ART), including all team members and anyone else involved in delivering the Program Increment (PI), get together to collaborate on co-creating a plan. The goal is to create confidence around the ability to deliver business benefits and meet business objectives over the coming weeks and months – typically around 3 months or a quarter.

To many people this feels un-agile. Isn’t it creating a big plan up-front and defining work far ahead? However, a recent experience led me to realise why its not about the plan, but the planning and the dynamics of the event itself. In Cynefin terms, PI Planning is a catalyst for transition and movement between domains.

Let me explain.

Before PI Planning, and a move into an ART cadence, many organisations are in Disorder, relying on order and expertise when they should be using experiments and emergence. The scheduling of a PI Planning event triggers a realisation that there is  a lack of alignment, focus or vision. In order to prepare for the event people have to agree on what is important and what the immediate objectives, intentions and needs are. In short, what does the Program Backlog look like, and what Features should be at the top. The conversations and work required to figure are the beginning of a shallow (or sometimes not so shallow!) dive into Chaos.

During PI Planning is when the Chaos reaches a peak, typically at the end of Day One, as it becomes clearly apparent that the nice ordered approach that was anticipated isn’t achievable. More conversations happen, decisions are made about the minimum plausible solution and hypothesis are formulated about what might be possible. This is when action happens as everyone starts to pull together to figure out how they might collectively meet the business objectives and move the situation out of Chaos into Complexity.

After PI Planning there is still uncertainty, and the iteration cadences and synchronisation points guide the movement through that uncertainty. Feedback on the system development, transparency of program status and evolution of the solution are all necessary to understand progress, identify learning and inform ongoing changes. This may require subsequent dips into Chaos again at future PI Planning events, or over time the ART may become more stable as understanding grows, and PI Planning in the initial form may eventually become unnecessary.

It is this triggering of a journey that makes me believe that PI Planning, or equivalent “mid-range” and “big-room” planning events, are a keystone to achieving agility at scale for many organisations. I wonder how this matches other’s experience of successful PI Planning meetings? Let me know with a comment.

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.