Making an Impact with Kanban Thinking

This post pulls together a number of ideas  on impact into a single place, and will become the content for a page in Impact on the Kanban Thinking site.

What is Impact

Outputs creates Outcomes which have Impact.

Designing a Kanban System involves the evolution and discovery of a good design. It cannot be pre-determined in advance. Thus instead of defining a future-state and working towards it, we start with the current-state and work away from it, exploring and assessing different alternatives. Each output of a design iteration will create different outcomes, and those that improve the system can be said to have a positive impact, while those that worsen the system have a negative impact.

Impact, therefore, describes the disposition of the system, or its tendency to behave in a certain way. Rather than defining a planned destination, impact points to the desired direction, such that we can check whether any changes are moving us towards or away from the direction we want to be heading. Impact can be assessed by using narrative techniques to capture stories about utopian (and dystopian) futures, and subsequently asking whether an outcome is likely to lead to more of the positive stories and fewer of the negative stories.

Describing Impacts

When imagining what impacts would be desirable, its easy for our experiences and biases to lead us to narrow our thinking and prematurely converge on only one particular type of impact. To avoid this, and encourage diversity in exploring a wide variety of potential impacts, Kanban Thinking describes three types to consider, giving different perspectives.

  • Flow. This is Doing the Thing Right. Stories will be primarily related to the process, efficiency and reliability.
  • Value. This is Doing the Right Thing. Stories will be primarily related to the product, effectiveness and validity.
  • Potential. This is Doing the Thing Sustainably. Stories will be primarily related to people, euphoria and flexibility.

Impacts as Triads

When exploring the impacts, it will become apparent that there is not always an obvious and neat mapping to either flow, value or potential. Thus, the three impacts can be thought of as a triad, with each being a vertex of a triangle.

Triads are concept I learned from Dave Snowden and used by the Cognitive Edge Sensemaker Suite (note that they have a patent associated with this), where a triangle is used as a measuring instrument to assess against three parameters. By using triads, impacts can be placed relative to where they have the strongest affinity, without having to decide on any one in particular. Imagine an impact being connected to each vertex with elastic. The greater the affinity to a vertex, the greater the tension, with the final position being a result of the combination of all three. Thus the story in the triad below has the strongest affinity with the Flow vertex. The next strongest is Potential, with Value being the weakest.

Impact Triad

While triads are an approach not directly supported by the canvas in its current form, the deliberate choice of words to describe each impact creates multiple possible triads which could be explored. Deciding where an impact goes generally requires more thinking, and generates greater dialogue and insight.

Thing RightRight ThingThing Sustainably

Generating lots of utopian (and dystopian) future stories, instrumented with these triads, will generate patterns which can give a sense of where the improvement opportunities are for making an impact.


Here’s an example of thinking about impact from the three perspectives. It is intentionally lacking in direct relevance to minimise the risk of biasing your own answers to the questions.

When I go running, I’m generally wanting to improve my health and fitness. What impact do I want to have?

  • From a Flow perspective, impact could be about pace and speed. I could imagine a utopian future where I can run a 4 minute mile.
  • From a Value perspective, impact could be about distance and stamina. I could imagine a utopian future where I can run 100 miles.
  • From a Potential perspective, impact could be about friendship and community. I could imagine a utopian future where I am the president of a local running club.

None of these are mutually exclusive. If I can run a 4 minute mile, then there is a high likelihood that I’ll be involved in a running club, and training longer distances as well. However, explicitly exploring the different perspectives avoids me just focussing on one thing such as speed, to the detriment of friendship or stamina.

What stories would you like to tell about the impact your kanban system makes in the future?

Anatomy of the Kanban Canvas

I’ve just added a high level explanation of the anatomy of the Kanban Canvas to the main Kanban Thinking site (where you can downloade the Canvas). I thought I would also post it here.


How to assess the systemic problem and who is experiencing it.

At the centre of the Canvas is the system being worked on.

Assuming that the current situation is not perfect, and there is always room for improvement, then understanding the scope of the system helps focus on the biggest opportunities for improvement and avoids “rearranging the deck chairs on the Titanic”. By thinking about the situation as part of a holistic system, and having clarity on the scope of the system, we are more likely to identifying opportunities which improve the whole, rather than making smaller, local improvements, which might worsen the whole.

This leads to the question of what is the scope of the system. Defining the system to be too small, might not lead to any significant improvements. Equally defining the system to be too large, might be like trying to “boil the ocean”.

One way of understanding the system is to look at the people involved, and explore what problems those people are having. Narrative is an extremely useful form of doing this – finding and telling stories about people’s experiences and frustration with their work. In particular, the stories related to the customers and stakeholders will start to identify the boundaries of the system.

One fun way of exploring the system through narrative is by using the Pixar Pitch. This approach makes the final “Because of that…” refer to the current kanban system design, and the “Until Finally…” is left blank to be explored in the Impact section.


How to assess the fitness criteria in terms of flow, value and potential.

The three arrows coming out of the right of the central System are potential Impacts which might be made. These Impacts encourage a focus on what success or failure could look like, before any changes get made.

Given that in most situations, we are dealing with complex problems, where cause and effect are only apparent with hindsight and past solutions are not necessarily repeatable in the future, then we should not try to define a specific future state to solve the problem. However, that does not mean that we cannot determine the characteristics of the outcomes of solutions so we can assess their fitness criteria, or how fit for purpose a solution is.

Impact is an evaluation of fitness for purpose. A successful solution is one which has positive impact and an unsuccessful solution is what which has negative (or no) impact. Impact can be thought of as direction, as opposed to a point solution being a specific destination.

Having explored the scope of the System through narrative, we can also begin to define Impact in a similar way by asking what stories do we want to hear more of, or less off, in the future. When using the Pixar Pitch technique, imaging impossible good and bad endings to the story brings out exaggerated scenarios which can be compared against by asking whether the System is becoming more or less like the suggested endings. Getting both good and bad endings allows both positive and negative Impact to be easily imagined and identified.

When imagining the future, to create a range of diverse possibilities, the Impacts on Flow, Value and Potential are used to encourage thinking from different perspectives.


How to assess the evolutionary potential in terms of studying, sharing, stabilising, sensing and searching.

The five arrows going into the left of the System are the potential Interventions that could be made. These Interventions provide a frame for appreciating the intent behind various practices, learning and discovering which ways of working are the right ones for the current situation, and transforming those practices as the system continuously evolves.

Working through the interventions encourages continuous curiosity about which tools and techniques to use, understanding when and why they are appropriate, and ultimately collaboratively, co-creating an initial kanban system as a baseline to begin experimenting and improving.

The interventions used are to Study the context, Share the understanding, Stabilise the work, Sense the capability and Search the alternatives.

Kanban Thinking Questions

Question MarkQuestions

Kanban Thinking emerged from a realisation that “best practices” are not universal, and that sometimes, continuing to try harder, do better and have more discipline isn’t the right thing to do when those practices are not appropriate. As a result, the challenge became one of how to help people learn and discover their own solutions to the challenges they face when pre-packaged solutions don’t work. The result, Kanban Thinking, is a mental model that guides my thinking, and gives me a framework with which to ask questions when designing kanban systems. This post describes Kanban Thinking in terms of some basic questions.

The System

The starting point is to understand why we are designing a kanban system.

  • What systemic problem, difficulty or frustration are we trying to address?


Next we consider how we will know whether the kanban system is doing its job.


Improving the progress of the work might be a positive impact.

  • How would investing in our process, its efficiency and reliability make a difference?


Improving the product of the work might be a positive impact.

  • How would investing in our product, its effectiveness and validity make a difference?


Improving the sustainability of the work might be a positive impact.

  • How would investing in our people, their euphoria and humanity make a difference?


Then we evaluate what interventions we might make to begin evolving the kanban system.


Studying the context allows a better understanding of the current situation.

  • What could be done to learn more about customer and stakeholder needs, the resultant demand, and how that demand is processed?


Sharing the knowledge gives everyone a common understanding of the situation.

  • What information is important to share, and how can tokens, the inscriptions on them, and their placements, provide a single visual model?


Containing the work, with loose constraints, creates a stable, yet supple system.

  • What policies could help limit work in process, and remove unnecessary or unexpected delays or rework?


Sensing the current capability provides understanding of how well the system is performing.

  • What measures and meetings might create insights and guide decisions on the interventions required to have the desired impact?


Exploring possible interventions leads to discovery of the evolutionary potential of the system.

  • What small experiments could be run to safely learn the impact of different interventions?


There are not necessarily any right or wrong answers to these questions. The intent is that they should lead to dialogue and conversations, which themselves lead to awareness and ideas for how to go about change and improvement.

How do these questions help you? Let me know!

Heuristics for Building the Right Thing

On Monday I had the privilege of spending the day with some really smart people. Organised by Gojko Adjic, other attendees included Chris Matts, Henrik Kniberg, Mary and Tom Poppendieck, Gabby Benefield, Jeff Patton, Aaron Sanders and Olaf Lewitz.

The theme of the day was exploring how we can help organisations not just build the “thing right”, but build the “right thing”. We spent the morning sharing and exploring the various techniques we used, such as Story Mapping, Impact Mapping, Effect Mapping, Feature Injection, Real Options and Lean Canvas. We then moved onto more general discussion on the problem we are trying solve, before focussing back in on putting something together to try and articulate the commonalities we had found and create a platform to continue the conversation and try and make an impact ourselves.

Henrik has already blogged one statement summarising our conclusions.

Great results happen when:

  • People know why they are doing the work
  • Organisations focus on outcomes and impacts rather than features
  • Teams decide what to do next based on immediate and dircet feedback from the use of their work
  • Everyone cares

Another output was what I called “Heuristics for Building the Right Thing”. I mentioned heuristics in relation to Kanban Thinking, and again, the goal was to provide enough guidance for people to learn, without constraining to specific solutions or techniques. We started by brainstorming ideas and then grouped those into 5 themes, before putting some action-focussed words describe the themes. We noticed that there was a general feedback loop that the heuristics formed, and that there was a missing heuristic that was central to everything. Thus we ended up with:

  • Understand your customer
  • Be Comfortable with Ambiguity
  • Co-Create
  • Learn Fast
  • Make an Impact
  • Make it Visible

IMG_1222 IMG_1221

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:


A Review of Impact Mapping

I mentioned that I had a great conversation with Gojko Adzic at Lean Agile Scotland. During that discussion, Gojko also described a technique he call Impact Mapping. Since then has published a short book on Impact Mapping which I highly recommend.

An Impact Map can be thought of as a structured mind map, with the following levels being used to articulate the various aspects of an initiative:

  1. Why – The central node describes the goal of the initiative in a quantative manner such that it can be measured.
  2. Who – These are the people who can either be a help or a hindrance in achieving the goal.
  3. How – These are impacts that need to be had on the actors for them to either help achieve the goal, or minimise/avoid them being a hindrance.
  4. What – These are the deliverables which are hoped will create the impact on the actors to achieve the goal.

There are a number of reasons I like the approach and find it coherent with my experiences.

  • Impact Maps build on Simon Sinek’s Golden Circle, which I have written about in the past. The additional Who level helps bridge the gap and identify the different Hows .
  • Impact Maps also provides a framework against which to iterate and increment using story maps, feature injection and fidelity. In particular, having the SMART goal means that the development is more likely be stopped at the right time because the the deliverables have had the desired impact, or because they are not having the anticipated impact. Alternatively, development might even be avoided because alternative deliverables are identified which will generate enough impact to achieve the goal.
  • The language of Impact Maps is very close the language I use of Impacts, Outcomes and Outputs. For me, the Why is the Impact – it is the overall impact we want the initiative to have. The Who remains the people who can help or hindering achieving the Impacts. The How are the Outcomes which will help the actors achieve the Impact (or minimise/avoid hindrance), and the What are the Outputs required to create the Outcomes.

Regardless of the subtle differences of language, its still a great technique, and is one I’m looking forward to using in the future.

The Flow Impact

As I wrote yesterday about some upcoming Rallying adventures, I get to work on some exciting projects. A recent one is the “Agile for Business” book which is being put together in an iterative and incremental manner. Bob Gower, who is spearheading the initiative, wrote a blog post last month about the background to the book.

One of my contributions will be a short piece on flow, one of the three impacts I describe in Kanban Thinking. I am reproducing the current version below, although the final version may well change.

Flow is the result of doing the thing right. It is the regular and smooth progress of work from its initial concept to its final consumption.

Work that progresses in large chunks, in a stop-start manner, does not have flow. It’s the work that progresses in small pieces, in a continuous manner, that ultimately creates the kind of flow your organization needs. By reducing completion time and enabling greater predictability and reliability, it’s this kind of work that builds trust and fosters creativity and innovation. Moreover, reducing utilization and creating spare capacity, sometimes referred to as slack, allows a greater ability to respond to changes and surprises. After all, we don’t run our servers at 100%, and we know how well traffic flows on a grid-locked road! This spare capacity is what gives us time to spend on continuous improvement and innovation.

Working on smaller and fewer pieces of work helps minimize delays and generate faster feedback. Think about a slow, sluggish cargo tanker compared to a fast and nippy speedboat. Further, balancing demand against capability, and not starting more work than you can complete, means that work isn’t left hanging around and depreciating. Imagine the pileup caused by trying to push a chain of paperclips across a table versus the smooth flow created by pulling them across.

So how does an organization go about actually achieving flow? Focus on progressing and completing a smaller number of smaller pieces of work. Make that work, and its flow, visible in a physical shared place, and when work becomes blocked, encourage teams to resolve issues and concentrate on finishing it rather than starting something new. When aspects of the workflow are identified which mean that the work does not progress as quickly and smoothly as you would like, invest time in improving the workflow in order to develop future capability.

While this may appear to reduce the amount of time one is kept busy, it’s important to remember that busyness and productivity are not the same thing.

Measuring activity, in terms of utilization, will not create great results. Instead of focussing on the worker, focus on the work product, and measure work outcomes by things like throughput for productivity, lead-time for responsiveness, and due-date performance for reliability. These are all appropriate measures of flow.

Stop starting, and start finishing.

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.


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.

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.