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.


From Capability to Potential

At Lean Agile Scotland last weekend I was chatting with Gojko Adzic over dinner, and one of the many topics we covered was whether capability was the right word for one of the three impacts I describe as desirable with Kanban Thinking. Earlier this year I described what I meant by capability, but more recently I’ve realised capability is more commonly referenced as a property of the whole system, rather than one specific impact. In other words, if we improve a system’s flow, we have improved the system’s overall capability. Thus I needed to find a new word.

When I referred to capability as an impact, my goal was to ensure as much emphasis was placed on the people who are doing the work, as was on the work itself and its process. This emphasis is what enables a system’s performance to be sustainable over the long term, and even to improve over time. I had been toying with sustainability, but Gojko suggested the word potential and the more I think about it, the more I like it. Potential can be defined as the “possible, as opposed to the actual”, and what is “capable of being or becoming”. This clearly describes that improving a system’s potential is improving the long term future of that system.

Another way of looking at it is the metaphor of a pipe, again inspired by Gojko. If value is what comes out of the pipe, and flow is the progress through the pipe, potential is what can go into the pipe. A system which has a positive impact on potential is one which opens the tap to allow more to be done.


Then there is also the notion of human potential. Bob Marshall referred to this, and specifically to the waste of human potential, in his Lean Agile Scotland session on Rightshifting, further reinforcing the notion. I also noticed that Matt Wynne has referred to the same waste in his blog post following the conference. This has a nice synergy and helps reinforce the idea that increasing a system’s potential is not about cracking the whip harder. Rather it is about investing in people, unleashing their creativity, and making work fun.

As a result, the latest Kanban Thinking model now looks likes this.


Portfolio Kanban

I recently wrote an article for GOTO Magazine which has just been published its latest issue.

Given that it is embedded within the magazine, I thought I’d reproduce it here.

Steering the Agile Enterprise with Kanban Thinking


Large scale, enterprise organisations consist of many initiatives, programs, projects and development teams. While it is well understood how each individual team can achieve the benefits of agility, it is more difficult for the enterprise as a whole to achieve those same benefits. This article will look at how Kanban Thinking can inform the design of a Portfolio Kanban System, with a view to steering the Agile Enterprise to attain those benefits in order to respond to today’s competitive environments and unpredictable change.

Kanban Thinking

Kanban Thinking is the framework I use when approaching the design of a Kanban System within a given context. The central concept is that the design approach is based on principles of Systems Thinking.

On the right side are the leverage activities for evolving the system design; study, share, limit, sense and learn. Studying the current system helps understanding of the existing context. Sharing that understanding gives everyone knowledge about what is happening. Putting limits in place bounds the system to help stabilise it. Sensing how the system is performing gives an understanding of current capability. Finally, learning from the systems performance allows its capability to be continually improved.

On the right side are the anticipated impacts the system design should have; flow, value and capability. Achieving flow involves a smooth, regular and frequent progress of work. Kanban Thinking looks to eliminate delays rather than eliminate waste. Delivering value involves focussing on doing the right thing in order to delight the customer (and other stakeholders). Kanban Thinking looks to maximise value rather than minimise cost. Building capability involves developing people and knowledge as a foundation for business success. Kanban Thinking looks to develop people as problem solvers rather than their tools to solve problems.


The Portfolio as a System

As a system, a portfolio is more than the sum of its parts – that is the initiatives, projects, features, teams and people – but is a product of the interactions of those parts with a particular tendency. Managing a portfolio, and as a result steering the enterprise, is the job of designing and guiding the portfolio such that its tendency is to have a positive impact.

First I will describe how the levers can be used to discover a Portfolio Kanban System design, and then show how to understand the impact of that design.

Portfolio Levers


When studying an existing portfolio, it is useful to begin by identifying all the work that is currently known about, from early ideation, to already in production and being maintained. That work can then be clustered and arranged into themes based on similarity or relatedness. Common patterns which emerge are often based around investment and work item types, hierarchies and their governance workflow.

Examples of investment types might be areas such as architecture, urgent customer requests, current market segments, expanding market segments or future opportunities. Those investment types could be made up of initiatives, which are progressed through the development of features, which are iterated on by breaking down into stories.


Sharing a portfolio involves creating a model of the work which everyone can easily access and understand. Visual kanban boards provide a powerful mechanism for achieving this.

The most common approach is to create columns for the various stages of workflow that work items go through. For example, initiatives might begin as options, then have some discovery work done, then be assessed for suitability, then built and released before the results are reviewed for learning.

An important question to ask when designing the mechanism to share the portfolio is what you want to understand in order to learn. The TIP (Token, Inscription, Placement) heuristic is one I find useful to think about how to amplify the important signals, and dampen any noise.


Limiting a portfolio is the means by which it can be effectively steered. By limiting the number of initiatives or features being worked on, they can be completed sooner, and with greater predictability, allowing organisations to get earlier feedback and respond better to new information and changing market conditions.

Work can be limited at a number of levels. Investment allocation can help keep the portfolio focussed on the right mix of work.  The number of initiatives and features can be limited to focus on finishing work before new work is started. Flowing work through stable teams can be used to balance demand against the capacity and capability of those teams.

As well as just limiting work in process through a Portfolio Kanban System, another form of limit is explicit policies. Creating transparency of the boundaries of the system design mean that the system can be stable within those constraints and the policies can be evolved to allow the system to evolve. A simple approach to policies is to add a checklist of exit criteria to each stage of the workflow.


Sensing the performance of the portfolio is what tells us how well it is being steered, so that direction can be adjusted effectively. There are generally two elements to sensing; establishing a cadence and measuring outcomes.

Establishing a cadence creates a sense of rhythm, and helps lessen the co-ordination cost of getting people together. Setting up a regular meeting to plan and review the portfolio enables a forum for gathering new information and feedback. A Portfolio Council is then able to respond by scheduling and re-prioritizing work in a timely manner and ensure focus is on the most important work.

Establishing appropriate measures generates insights which can aid decision making about what can be done to enable better outcomes.  For a Portfolio Kanban System, financial measure seems to be appropriate. An economic model, which uses high level estimates of the costs and benefits of initiative or features, along with an understanding of the run-rate of teams, allows effective trade-off to be made between portfolio items. A timeline of planned and actual progress, for example, provides the basis for a rolling forecast as an alternative to annual plans.


Whatever choices you make, the design of your Portfolio Kanban System, and the work within it, it will be wrong! Learning, the detection and correction of those errors, is key to evolving the portfolio to have a greater impact.

Steering a portfolio is about updating the portfolio to match the reality of the current situation, rather than managing the portfolio towards a future situation. By sensing current performance with a regular cadence, work can be advanced, delayed or even killed to keep focus on the most important work.

Evolving a Portfolio Kanban System is about running deliberate experiments, with prediction and validation of how changes to the system design will affect its impact. Again, by sensing current performance with a regular cadence, visualisations, WIP limits and other explicit policies can be adjusted as knowledge is gained about what a better design should be.

Portfolio Impact


Achieving flow across a Portfolio Kanban System means that the initiatives, programs, projects or features in the system progress with as few delays as possible. As a result the enterprise will be more responsive to the competitive landscape, so that when new information surfaces it can be reacted to effectively. Further, when flow is smooth across a portfolio, the work delivered by the system becomes more reliable as variability of lead times is reduced to within understood ranges.


Delivering value from a Portfolio Kanban System means the initiatives, programs, projects or features in the system are the most important things that could be worked on at that time. As a result stakeholder satisfaction will increase as customers get their needs met. Maintaining stakeholder satisfaction sustainably means that quality will also increase.


Building capability with a Portfolio Kanban System means that the right initiatives, programs, projects or features can be effectively delivered over the long term, and not just the short term. As a result employee satisfaction will increase, leading to greater retention of people and their knowledge. This long term building of people, teams and their skills will also lead to an increase in overall productivity.

The Value Impact

The impact of value is difficult to quantify, and putting a currency number is not as simple as it is with cost. The challenge is even greater for organisations which are not selling products, such as governments or charities. However, there are a number of approaches which can be used to help understand the value that is being delivered such that we can maximise across the whole system. Some of these I have already covered when I wrote about the science of kanban from an economic point of view, but it is worth including them again.

Customer Delight

Steve Denning suggests that ultimately value is in delighting customers. I agree with this, using a broad definition of customer which is not limited to the end user, but can be anyone with an interest in the outcome. That could include people interested in the user experience, architecture or operational aspects, for example. Having said that, the end user is generally the customer who ultimately determines success.

Value Horizons

In his recent book Escape Velocity, Geoffrey Moore draws heavily on the The Horizons Model developed at McKinsey and published in The Alchemy of Growth. Using this model, Horizon 1 features are intended to have an immediate impact in the current financial year. Horizon 2 features are considered to be investments which are intended to have an impact in the medium term, probably the next financial year. Horizon 3 features are options which have the potential to have an impact in the long term, and not until subsequent financial years. It is very easy to be drawn into focussing on Horizon 1 features due to the anticipated immediate return. However, when that wave peaks and crashes, it is important to be ready for the next wave. Therefore, explicitly spreading the allocation of investment in features across the horizons can mitigate this short term thinking and lead to longer term success.

Life Cycle Profits

Looking at value over the longer term is a form of considering total life cycle profits. Investing in Horizon 2 and Horizon 3 features is a way of looking at overall life cycle of a product, and of prolonging the profit period.

Revenue and Expenditure

Another way of looking at value is something I picked up off Chris Matts. He suggests that there are 4 types of value based on revenue and expenditure. The first is in increasing revenue, for example by adding functionality which attract more customers. The second is in protecting revenue, for example by adding functionality which keeps existing customers. The third is in reducing expenditure, for example by adding functionality which improves development efficiencies. Finally, the fourth is in avoiding expenditure, for example by adding functionality which is required to avoid regulatory fines.

Competitive Landscape

The perspective of the competitive landscape is also a way of classifying features, this time as either MVP (Minimal Viable Product), neutralising, differentiating or optimising. MVP features are those which have to be completed to even enter the market. Neutralising features are those which attack a competitors dominance by eliminating any advantage they have with unique capability.  Differentiating features are those which create market dominance by providing new unique capability which the market demands and no competitor can provide. Finally, optimising features are those which don’t add any new capability, but improve the performance if existing functionality in some way. While MVP features are clearly essential, only working on those can be a high risk strategy, and a portfolio of features which includes a mix of all four types can be lower risk.

Cost of Delay

The value of a feature is often dependant on when it is delivered. Using cost of delay as a model can help understand when to schedule features in order to maximise value. Four common patterns are Expedite, Standard, Fixed Date and Intangible. Expedited features are ones where the cost of delay is high and immediate. These items are genuinely urgent and should be scheduled immediately. Standard features are ones where the cost of delay rises linearly. Examples are items with an opportunity cost, where the later the delivery, the more opportunity for gain is lost. Fixed Date features are ones where the cost of delay rises sharply at a specific date. Examples are regulatory dates at which fines may be imposed, or seasonal dates such as Christmas or trade-shows. Delivering these features early creates little or no extra value. Intangible features are ones where the cost of delay is likely to happen in future, but the exact nature is unpredictable. Examples are technical debt or infrastructure work.


Cost of Delay helps with making effective scheduling decisions by prioritising features against each other. Don Reinertsen describes a number of algorithms in his book Principles of Product Development Flow. Principles F15, F16, and F17, can be summarised as follows. When two features have an equivalent cost of delay, schedule the shortest one first. When two features require equivalent time, schedule the one with the highest cost of delay first. When two features require different times and have different costs of delay, then schedule the one with the weighted shortest time first, where the weighting is calculated by dividing the cost of delay by the time. Dean Leffingwell has a great blog post about prioritising features describing this in more detail.

Feature Injection

Having these models is all very well, but how do we know what to actually build? Feature Injection can provide some guidance. With Feature Injection, we start with a vision, decide what goals meet that vision, what capabilities enable those goals, what features deliver those capabilities, what scenarios exemplify those features and finally, what stories make up those scenarios. Thus by starting with the vision, the details can be ‘injected’ just-in-time, incrementing and iterating based on feedback. Liz Keogh describes this well in a recent blog post about BDD in the large.


Feature Injection is designed to deal with the fact that even when we have some idea of the capabilities we want to create, we still have little idea about the precise functionality to build. In these cases experimentation is important. Lean Startup, with its Build, Measure, Learn cycle is a great means of achieving this. It is also a good example of running safe-to-fail probes within the probe-sense-respond approach the Cynefin recommends in the complex domain. I’m also curious about how the software community can apply set-based design ideas such as trade-off curves to better learn and create knowledge about what to build. When running these sorts of experiments, the value is more in the information generated, and the learning experienced, than in any financial return or saving.

And More

There are many more ideas which can be used to help us understand value. These are the ones I use most. For example, I know Tom Gilb has done a lot of thinking on the subject, which I have yet to explore. Eli Goldratt’s work with theory of constraints is another area of potential, which Bob Marshall explored recently in a post asking what is value.

What else is missing? Let me know in the comments.

The Kanban Thinking Picture

I’ve recently settled on a visual representation of Kanban Thinking which has been working well. The structure took shape when I realised that Flow, Value and Capability were system impacts. Those are the arrows coming out of the right hand side of the central System. The arrows going into the left hand side are the levers we have to influence the system behaviour; Study, Share, Limit, Sense and Learn. The primary lever is limiting. Studying and sharing provide the transparency and visibility to enable the limits. Sensing and learning give the feedback to evolve the limits.


Feel free to use this picture. I hope it proves useful.

Linking Flow, Value and Capability

I wrote recently that I have come to think about Flow, Value and Capability as the primary impacts I hope a Kanban System will have. Flow, Value and Capability are not independent entities, however, with Capability being the link between Flow and Value. We can think of Flow as “doing the thing right”, where good flow is the result of a good process. Similarly, we can think of Value as “doing the right thing”, where high value is the result of good outputs from the process. We want both, however, and we can think of Capability as “doing the right thing right”, where a good process delivers good outputs.

Flow Value Capability

Here’s another way of looking at it…

A common scenario is creating projects, and assigning people to those projects to form a project team. This is great for the project in isolation, but when the project finishes the team is usually disbanded, and all the capability that was created as tacit knowledge in the team is lost.

Project Team

A further challenge (amongst many) with this approach is that when another project comes along – and then another – people get assigned to multiple project teams, at which point they’re not really teams any more. This might seem efficient, but it is not effective, and is not good for the people or the work. In the diagram below, the person in the middle on three projects is not in a good place!

Multiple Teams

An alternative idea is to form teams around organisational capabilities – things which will enable the business to make an impact. Small pieces of valuable work which enhance this capability can then be individually pulled by these teams, creating flow. This is what I call a Capability Team.

Capability Team

Pursuing this approach, the notion of the project goes away, replaced by a Flow of Value through Capability teams who are able to “do the right thing right”. These teams can stay together for as long as the capability is important, building knowledge about all aspects of what they are building, and how they build it.

What is Capability?

I recently gave talk at the London Scrum User Group (LSUG) describing Kanban Thinking and had a very interesting conversation about what I mean by the impact on capability. I realised I needed to think it through in a bit more detail, and this is an attempt to articulate it better.

Defining Capability

In his book Rethink: A Business Manifesto for Cutting Costs and Boosting Innovation, Ric Merrifield used the term capability to define the outcomes which drive business performance. One of the dictionary.com definitions is that a capability is a quality, ability or feature which can be used or developed. Additionally, to be capable of something is to be predisposed to, or inclined to, which ties in with the idea that complex systems have disposition. Putting all these together, we can say that a systems capability is its degree of disposition, which can be used and developed, towards create a business outcome.

Doing the Right Thing and Doing the Thing Right

We can think of capability in two ways – that of the business, and that of the people. The business’s capability is its ability to do the right thing, while its people’s capability is their ability to do the thing right. This can be visualised in a 2×2 matrix, where ideally we want to be in the top right quadrant where we are aligning business capability with human capability.


Developing Capability

When I first described Kanban Thinking, I said that “to build capability is to develop people and knowledge as a foundation for business success. Kanban Thinking looks to develop people as problem solvers rather than their tools to solve problems”. Capability is more than just how good the flow of value is. It is also how well the flow and value can be sustained and improved over time. Simply swapping in and out different people to an existing process (flow) with existing requirements (value) will not work. Businesses are social and cognitive systems where people have tacit knowledge, and they share and use that tacit knowledge to deliver the work. That is why teams are such as core part of making an agile approach work.

Capability Teams

Feature teams are a great example of how to build capability, collaborating to delivering customer value directly. A more debatable approach, however, is the use of component teams, and the idea of capability can provide guidance on when this may be appropriate.  Where a component or architectural layer provides some direct impact on organisational capability, then it may be worth having its own team. The decision on team structure becomes one of whether the team is a Capability Team. Taking a cue from “Rethink”, a Capability Team as one whose outcomes have a resultant improvement on the business performance, as opposed to one whose activities are needed to achieve a business outcome.

An Example

A financial services organisation had a team dedicated to developing an SOA capability which would be used by a variety customer facing applications to access a common data repository. The ability to effectively manage customer data was a key capability for the organisation, and development of the data repository was a business outcome which enabled a better customer experience by providing cross-application consistency. The same organisation also had a QA team. This is not a capability because on its own it does not deliver a business outcome. Rather, it is an skill or activity required to deliver quality, and which should be built into the work performed by capability teams delivering business outcomes.

Even with the notion of Capability Teams, its not necessarily a simple black or white decision, hence the interesting conversation at LSUG. When unsure about what team structure to go with, I think the more interesting question is “how will I know if the structure is having a positive impact?” As I mentioned at the end of the post on Impact, Outcome and Output, I believe Geoffrey Moore’s hierarchy of powers offers some insights here, which I hope to expand on in a future post.  I’d also be interested in hearing of any other interesting examples of Capability Teams. Please leave a comment if you have one!

Impact, Outcome and Output

As I alluded to in the previous post, one of the changes in thinking, and in particular language, for me recently is the idea of impact. Specifically that impact is different from outcome which is itself different from output. I’ve differentiated outcome from output for some time, as have others, but I believe impact is a further step in understanding how we approach change.

To relate the three ideas to each other, I would say that:

Outputs create outcomes which have impact.

This mapping also ties in nicely to Simon Sinek’s Golden Circle model that I have referenced before.

Outputs (or sometimes activities) are the things that we do in order to achieve something. They provide the details about what gets done, such as specific practices or implementation details. In the Golden Circle, they are the WHAT.

Outcomes are the future state we hope to achieve by completing the outputs. They provide the details about what goals we hope to achieve, such as end results or behaviours. In the Golden Circle, they are the HOW.

Impacts are the tendencies or dispositions of an outcome. They give an indication of whether the future state is a positive or negative one, without limiting the scope of what that future state might be.  In the Golden Circle, they are the WHY.

As Simon Sinek recommends with the Golden Circle, we should always Start with Why, and thus when implementing any process or product it is useful to know what impact we want to have. I have realised that the notions of Flow, Value and Capability that I refer to as part of Kanban Thinking are actually the primary impacts that I hope that a Kanban System will achieve.

  • A positive impact on flow might be one which results in earlier and smoother delivery and might be seen in a reduction in lead time or variability.
  • A positive impact in value might be one which results in a better return on investment or improved margins and might be seen in improved economic outcomes
  • A positive impact in capability might be one which results in better business performance and might be seen in improved quality, throughput, or customer and employee satisfaction.

Another recent and related influence has been Geoffrey Moore’s Escape Velocity, where he talks about a hierarchy of powers.

  • Category Power relates to the relative demand for a class of product.
  • Company Power relates to the organisation’s relative position within a category.
  • Market Power relates to the relative company power within a specific market segment.
  • Offer Power relates to the relative demand for a specific product.
  • Execution Power relates to the relative ability to outperform competition.

This has got me thinking about how impact might be the effect a change has on one or more of these powers. While flow is more aligned with execution power, value and capability are aligned to the other powers.

Three Cynefin Ahas

Over the last year I’ve been increasingly influenced by ideas from Cynefin, created by Dave Snowden of Cognitive Edge. If you want a good introduction, Liz Keogh recently blogged a good explanation. I’ve realised that there are 3 key changes in my thinking, some completely new, and some reinforced by a better understanding of cognitive complexity. None of these are unique to Cynefin, and Cynefin contains much more. This list is my take, rather than any official list, although if you know Dave’s work I’m sure you’ll recognise a lot of the language!

1. Evolutionary Potential. Even though I’m a fan of Systems Thinking, I’ve realised that in complex situations, defining a future state and closing the gap isn’t the right approach. I still find system archetypes such as Tragedy of the Commons useful, but more in understanding the current situation than defining a future one. Instead I prefer to explore the evolutionary potential. There may be many different answers, some of which are not yet know, so experimenting, in a safe to fail way, helps evolve to the potential. An interesting case of this is exaptation, where a function is used for a purpose it was not originally adapted or selected for. My most recent aha related to evolutionary potential was that even though complex systems aren’t controllable, they are dispositional. In other words, while we still might not be able to know what the outcome of a change will be (let alone the output or activity to get there), but we can determine whether a change has a positive or negative impact on the overall system.

2 Sense-making. Cynefin is primarily a sense-making framework. This means that the data precedes the framework, as opposed to a categorisation framework where the framework precedes the data. Thus, rather than trying to figure out where an example should go in a matrix, examples are positioned relative to each other based on some criteria, and then boundaries are drawn subsequently. This makes sense-making much more dynamic, and what becomes interesting is not the classification of whether something is complex or complicated, but how things transition across the boundaries. No domain is better than any other as each is contextual. Moving from complex to complicated may be appropriate when optimising or exploiting. Equally, moving from complicated to complex (via a shallow dive into chaos) may be appropriate when wanting to innovate or explore. Further, any scenario is often in multiple places at the same time (after all Cynefin translates from Welsh into “place of our multiple affiliations”). Elements may be simple, complicated and complex, and narrative becomes an useful tool for understanding the differences.

3. Narrative. One of the main benefits of Kanban Systems that attracted me was the power of the contextual approach. A Kanban System is something that is overlaid on top of an existing approach to better understand and improve it and narratives are a great way of discovering, exploring and understanding aspects of a context. Collecting a set of anecdotes about best and worst experiences in a context creates a form of knowledge against which to pattern match for similarity of new situations, leading to better insights and decisions as to how to manage those situations.

Putting those three ahas together, I can imagine applying them through working with organisations to collect a range of narratives, help make sense of them by contextualising them with Cynefin, and then facilitate the creation of appropriate actions to make an impact on the business. Those actions might be safe to fail experiments, based on lean and agile principles, to explore the evolutionary potential for complex problems, or a more direct application of lean and agile practices for complicated problems. Or more likely a hybrid of both!


Kanban Thinking on SPaMCAST

I recently gave an interview with Tom Cagley who puts together the Software Process and Measurement Cast, and talked about what I am calling Kanban Thinking. The result has just been published – have a listen and let me know what you think.

SPaMCAST 174 – Karl Scotland, Kanban Thinking