The X-Matrix Strategy Deployment Model

There is a model for Strategy Deployment that sits behind the X-Matrix that is worth explaining in more detail as a way of understanding why it is designed the way it is, and how to use it. It is built around describing four types of elements – which I call results, strategies, outcomes and tactics – and how they fit together.

Before we start, lets get the George Box aphorism out of the way:

All models are wrong; some models are useful

Results represent the organisational impact you want to have. They are lagging indicators, success or failure only being declared at the end of the journey. They usually reflect the nature of the business and its economics.

The Results are implemented by Strategies

Strategies are constraints which guide how you achieve the results. They are enabling, allowing a range of possible solutions (as opposed to governing, limiting to a specific solution). Thus they guide decisions on where to focus attention (and hence also where not to focus attention).

The Strategies lead to Outcomes

Outcomes provide evidence that the strategies are working. They are leading indicators of whether the results can be achieved ahead of time. They describe the capabilities that the organisation requires in order to be successful.

The right Outcomes will generate the successful Results.

Screen Shot 2016-05-25 at 20.47.46

Of course the Strategies don’t directly lead to Outcomes. Some form of action has to take place. Thus the Strategies are actually implemented by Tactics.

Tactics are the activities that take place to implement change. They are experiments which test hypothesis on how to achieve the outcomes. The represent the investments in the improvement work that is being done.

Therefore, it is the Tactics that generate the Outcomes and ultimately lead to the Results.

Screen Shot 2016-05-25 at 20.48.11

For change to be successful, there should be a correlation between the various elements in this model (and it should be remembered that correlation is not causation). Each element will have some level of contribution to another. This will range from strong or direct, to weak or indirect, or there may sometimes be none. You could also say that the correlations are Probable, Possible, or Plausible. All together there should be coherence (albeit messy) to the way all the elements fit together.

Screen Shot 2016-05-25 at 20.48.32

By starting with Results, moving on to Strategies and Outcomes and leaving Tactics until last, there is a greater chance that the Tactics chosen are ones which do implement the Strategies and generate the Outcomes. The intent is to avoid premature convergence or retrospective coherence when identifying the Tactics. It is very easy to hastily jump to the wrong conclusions about what the Tactics should be, and then justify them based on the Strategies.

Even if you don’t use the X-Matrix explicitly, understanding this model can be useful for asking questions about change and improvement.

  • What end results are you hoping to achieve?
  • What are your strategies to deliver them?
  • What intermediate outcomes will show you are on the right path?
  • What tactics are you using to move forward?
  • How do all these pieces fit together?

If you can answer these questions, then you should be able to populate an X-Matrix. I will work through an example in an future post.

X-Matrix Simple

Alignment and Autonomy in Strategy Deployment

Following on from my previous What is Strategy Deployment and Dynamics of Strategy Deployment posts, there is a model I like which I think helps to show how the mechanics and the dynamics work together.

In The Art of Action, Stephen Bungay describes how Field Marshall Helmuth von Moltke, Chief of Staff of the Prussian Army for 30 years from 1857, had an important insight regarding Alignment and Autonomy. Previously these two had been viewed as extremes at the end of a single scale. Having high alignment meant having no autonomy because alignment could only be achieved through defining detailed plans which everyone should follow. Equally, high autonomy meant having no alignment because autonomy would result in everyone doing their own thing with no regard for each others actions.

Von Moltke’s insight was that alignment and autonomy are not a single scale requiring a tradeoff between the two ends, but two different axis which can actually reinforce each other. Thus not only is it possible to have both high alignment and high autonomy, but high alignment can enable high autonomy.

Alignment and Autonomy

They key to making this possible is differentiating between intent and action. Alignment is achieved by clearly stating intent centrally, such that autonomy can be achieved by allowing action to be decentralised in support of the intent. This requires mechanisms to both clarify and amplify intent, and enable and encourage local action. Thus using the definition of Strategy Deployment as “any form of organisational improvement in which solutions emerge from the people closest to the problem”, solving the problem is the intent, and the emerged solution is the action.

Using this model we can now describe two mechanisms necessary to make this happen. Alignment can be achieved with the X-Matrix, which enables the conversations about intent and summarises and visualises the results of those conversations. In other words, the X-Matrix shows how results, strategy, outcomes and tactics align and reinforce each other. Autonomy can be achieved through Catchball (Bungay describes the equivalent as back-briefing), which enables the X-Matrix to be passed around the organisation such that everyone can reflect, give feedback, and improve it, helping focus action on meeting the intent.

X-Matrix and Catchball

Viewing Strategy Deployment in this light also highlights a symmetry with the Autonomy, Mastery and Purpose model of intrinsic motivation described by Dan Pink in his popular book Drive. Autonomy is a direct match in both models and purpose is equivalent to intent. Mastery is then the result of improving capability autonomously with strong alignment to intent.


What this way of looking at Strategy Deployment shows is that both the X-Matrix and Catchball are necessary components. Just using the X-Matrix with out Catchball will probably result in it being used as just another top-down document to command and control employees. Similarly, just using Catchball without an X-Matrix will probably result in collaboration around local improvements with no overall organisational improvement.

Dynamics of Strategy Deployment

Following on from my last post, and based on the feedback in the comments, I want to say more about the dynamics of Strategy Deployment.

The first point is to do with the directionality. Strategy isn’t deployed by being pushed down from the top of the organisation, with the expectation that the right tactics simply need to be discovered. Rather, the strategy is proposed by a central group, so that decentralised groups can explore and create feedback on the proposal. Thus information flows out and back from the central group. Further, the decentralised groups are not formed down organisational structures, but are cross-organisational so that information also flows between groups and divisions. The following picture is trying to visualise this, where colours represent organisational divisions. Note also that some individuals are both members of a “deployed from” group, and a “deployed to” group – the deployment isn’t a hand-off either.

Strategy Deployment Directionality

This means that a Strategy Deployment can begin anywhere in the organisation, in any one of those groups, and by widening the deployment to more and more groups, greater alignment is achieved around common results, strategies, indicators and tactics.

That leads to the second point about emergence. In the same way that the tactical initiatives are hypotheses with experiments on how to implement the strategies, so the strategies themselves are also hypotheses. Tactics can also be viewed as experiments to learn whether the strategies are the best ones. In fact Strategy Deployment can be thought of as nested experimentation, where every PDSA “Do” has its own PDSA cycle.

Nested PDSA Cycles

With regular and frequent feedback cycles from the experiments, looking at the current indicators and results, strategy can emerge as opportunities are identified and amplified, or drawbacks are discovered and dampened. In this way Strategy Deployment explores the evolutionary potential of the present rather than trying to close the gap towards a forecasted future.

These dynamics are often referred to as Catchball in the lean community, as ideas and learnings are tossed around the organisation between groups, with the cycle “Catch, Reflect, Improve, Pass”.

Catch, Reflect, Improve, Pass cycle

I also like the LAGER mnemonic I mentioned in Strategy Deployment as Organisational Improv, which is another way of thinking about these dynamics.

What is Strategy Deployment?

Japanese Ship in a Storm

I’ve been writing about Strategy Deployment a lot recently but realised that I haven’t properly defined what I mean by the term. Actually, I sort of did in my last post, so I’m going to repeat, expand and build on that here.

In a nutshell, Strategy Deployment is any form of organisational improvement in which solutions emerge from the people closest to the problem.

The name comes from the Japanese term, Hoshin Kanri, the literal translation of which is “Direction Management”, which suggests both setting direction and steering towards it. A more metaphorical translation is “Ship in a storm going in the right direction”. This brings to my mind the image of everyone using all their skills and experience to pull together, with a common goal of escaping turbulence and reaching safety.

Lets look at the two elements, strategy and deployment, separately.


Wikipedia defines strategy as

“a high level plan to achieve one or more goals under conditions of uncertainty”.

The emphasis is mine as these are the two key elements which indicate that a strategy is not a detailed plan with a known and predictable outcome.

Strategy to me is about improving and making significant breakthroughs in certain key competitive capabilities. I like Geoffrey Moore’s Hierarchy of Powers from Escape Velocity as a guide for exploring what those capabilities might be. This hierarchy is nicely summarised as

“Category Power (managing the portfolio of market categories in which a company is involved), Company Power (your status relative to competitors), Market Power (market share in your target segments), Offer Power (differentiation of your offering), and Execution Power (your ability to drive strategic transformation within your enterprise).”

As an aside, in this context, Agility as a Strategy can be thought of as primarily (although not exclusively) focussed on improving Execution and Offer Powers.

Determining Strategy as “a high level plan to achieve one or more goals under conditions of uncertainty”, therefore, involves setting enabling rather than governing constraints. Strategy should guide the creation of new solutions, and not control the implementation of existing solutions. It defines the how and not the what, the approach and not the tools.


Mirriam-Webster defines deploy as

“to spread out, utilize, or arrange for a deliberate purpose”.

In this context it is the strategy that is being utilised for the deliberate purpose of improving organisational improvement. Given that the strategy is “a high level plan to achieve one or more goals under conditions of uncertainty”, this means that the deployment is not the orchestration and implementation of a detailed plan.

Instead it requires a shift in the way organisations operate, from a mindset where management knows best, and tells employees what to do without thinking or asking questions, to one where they propose direction and ask for feedback and enquiry. Instead of assuming that managers know the right answers as a facts, the deployment of strategy assumes that any suggestions are simply opinions to be explored and challenged. Employees are allowed, and encouraged, to think for themselves, allowing for the possibility that they may turn out to be wrong, and making it acceptable for people to change their mind.

As another aside, this brings to mind a great Doctor Who quote from the latest season:

Strategy Deployment

Back to my original definition of “any form of organisational improvement in which solutions emerge from the people closest to the problem.”

Strategy Deployment is the creation of a high level plan for organisational improvement under conditions of uncertainty (the strategy), and the utilisation of that strategy by employees for a deliberate purpose (to achieve one or more goals). Clear communication of both the goals and the strategy, and constant collaboration across the whole organisation to use all the skills, knowledge and experience available, allows the appropriate tactics emerge. In this way Strategy Deployment enables autonomy of teams and departments while maintaining alignment to the overall strategy and goals.

Note that I say any form. I don’t see Strategy Deployment as a specific method, or framework, but more as general approach or style. My preferred approach at the moment uses the X-Matrix, but I would also describe David Snowden’s Cynefin, David Anderson’s Kanban Method, Mike Burrows’ Agendashift and Jeff Anderson’s Lean Change Method as forms of Strategy Deployment. I’m hoping to explore the synergies more at Lean Kanban North America and the Kanban Leadership Retreat.

Agility is a Strategy, Agile is a Tactic

Agile Manifesto

Ron Jeffries recently blogged about his reflections on the Agile Manifesto, and what he wished the authors had done and said differently with hindsight. His conclusion was that he would have rather focussed on practices.

I have a different perspective.

My concern with an even stronger focus on practice is that it would lead to even more Cargo Culting than we see already. People simply copying practices they see and hear about in the hope that implementing them by the book will magically lead to them being Agile. We would end up with more teams using the autonomy encouraged by Agile to choose the way they work, but with no alignment to the original goal of improving business results.

Worse still would be even more conversations about things “not being Agile” than we see today. As Jabe Bloom recently tweeted: ‘the statement “X isn’t Agile” fills me with meh‘.

I much prefer Joshua Kerievsky’s take on what he calls Modern Agile. I think he has taken the opposite approach by trying to take what we have learned over the last 20 years and describe the intent. I would describe what he calls disciplines as strategies, and I believe the transformation of an organisation to have greater agility to be an example of what the Lean community call Strategy Deployment.

Let me explain.

Strategy Deployment, like most Lean ideas, has its roots in a Japanese term, Hoshin Kanri. The literal translation is “Direction Management”, but a more colourful translation “Ship in a storm going in the right direction”. This brings to my mind the image of everyone using all their skills and experience to pull together, with a common goal of escaping turbulence and reaching safety. Thus Strategy Deployment is an approach to organisational improvement which engages he entire workforce in figuring out how the business can survive and thrive.

Significantly, this means a shift from organisations operating on the basis that senior management knows best, and tells employees what to do without thinking or asking questions, to one where they propose direction and ask for feedback and enquiry. Instead of assuming that they know the right answers as a facts, Strategy Deployment assumes that any suggestions are opinions to be explored and challenged, with the possibility that they may turn out to be wrong, and making it acceptable for people to change their mind.

What leadership proposes, therefore, is strategy, using it as a form of enabling constraint to guide and open up possibilities of what could be achieved. This is as opposed to defining tactics as a form of governing constraint, dictating action and closing down any alternatives that could be explored. A useful metaphor here is the one used by Dave Snowden of types of skeleton. An enabling constraint is like an endo-skeleton (e.g. humans) – formed on the inside, maintaining coherence and allowing growth. A governing constraint is like an exoskeleton (e.g. crabs) – formed on the outside, protecting and limiting growth.

By being clear on strategy, and allowing and encouraging the whole organisation to use their skills, knowledge and experience to discover appropriate tactics, it is possible to enable autonomy while maintaining alignment. In this light, all the various Agile practices are simply tactics (and very good ones) to help organisations achieve greater agility as a strategic goal.

In other words, Agility is a Strategy, Agile is a Tactic.

Although obviously its not quite a simple as that! I’m not sure that many executives would actually say that greater agility was a strategic goal. However, some of the primary outcomes that agility enables are relevant as strategic goals. I like to use the dimensions identified by Larry Maccherone as a starting point:

  • Productivity – amount of delivery
  • Responsiveness – speed of delivery
  • Predictability – consistency of delivery
  • Quality – delivering the thing right
  • Customer Satisfaction – delivering the right thing
  • Employee Engagement – delivering sustainably

And all of these would help achieve more general strategic goals such as focussing on new markets, regions, technologies, business models etc.

What’s all this got to do with the Agile Manifesto?

It seems to me that what the Manifesto authors had identifies was a different set of strategies to deliver successful software, and a thought experiment, I wondered what the Manifesto might it have looked like if it had been written as a set of strategies. I’m not suggesting actually rewriting it but it seems like an useful idea to explore. This is what I came up with:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work, our strategies have become to:

  • Empower teams around economies of flow
  • Reduce the batch size of value delivery
  • Explore the evolutionary potential of solutions
  • Sense and respond to feedback

Why did I choose those?

Empower teams around economies of flow – “Individual and interactions” is about people, working together as part of a value stream, using their collective expertise to maximise the flow of delivery.

Reduce the batch size of value delivery – “Working software” is about those teams  delivering valuable software early and often in smaller batches, using incremental and iterative approaches.

Explore the evolutionary potential of solutions – “Customer collaboration” is about working closely with customers to discover how to meet their needs through empathy and experimentation.

Sense and respond to feedback – “Responding to change” is about using the smaller batch size for knowledge discovery as well as value delivery, and using that information to create feedback for continuous change.

What would you choose?

This is just one interpretation. It was not an easy exercise deciding what to include, and what to leave out, and its at least the 3rd version I have some up with. I’m sure people will have different opinions. I’d love feedback on what they are! Please leave a comment on what your strategies are to achieve greater agility.

Agile Manifesto Strategies

Are we tabby cats trying to emulate cheetahs?

Credit: Dennis Church

Credit for the title of this post goes to Sam Murphy, Section Editor at Runners World UK. Those of you who have seen me recently we will probably know that as well as being an advocate of Lean and Agile, I also have a passion for running, and I subscribe to Runners World. Sam used this title for an article of hers in the September issue, which struck me as having lots of overlaps with how I go about coaching and consulting in businesses. The gist of it was that when training, rather than trying to copy what elite athletes do, we should find out what works for ourselves. Sound familiar?

Here’s some quotes:

Dr Andy Franklyn Miller … concluded that ‘a very unique and customised strategy is used by each swimmer to excel’. And if that’s the case, is looking at what the elites are doing and aiming to replicate it the best way to maximise our own sporting success? Or are we tabby cats trying to emulate cheetahs?

Is a very unique and customised strategy used by each successful organisation to excel? Is looking at what these organisations are doing and aiming to replicate it the best way to achieve success? Or are we tabby cats trying to emulate cheetahs?

Dr George Sheehan, runner and philosopher, said “We are all an experiment of one.’


Ultra runner Dean Karnazes … writes “I always encourage people to try new things and experiment to find what works best for them.’

It seems athletic training is not so dissimilar to building a successful organisation! Rather than just copying what we may have seen or read about working elsewhere, we should encourage organisations to try new things and be experiments of one. That’s what Strategy Deployment is all about!

Or (to close with the same quote Sam closed her article with) as Karnazes also said:

‘Listen to everyone, follow no-one.’

Kanban Deployment with the X-Matrix

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

Let me explain…

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

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

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

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

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

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

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

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

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

Strategy Deployment as Organisational Improv

IMG_0159At Agile Cymru this week Neil Mullarkey gave a superb keynote, introducing his rules of improv (left). He suggested that businesses can apply these rules to be more creative and collaborative, and that there is a lot of synergy with Agile. Like all the best keynotes, it got me thinking and making connections, in particular about how Strategy Deployment could be thought of as form of Organisational Improv.

I’ve blogged about Strategy Deployment a couple of times, in relation to the X-Matrix and Kanban Thinking, and Is Agile Working. Essentially it is a way for leaders to communicate their intent, so that employees are able decide how to execute. This seems just like an improv scene having a title (the intent), allowing the performers to decide how to play out the scene (the execution).

The title, and rules of the improve game, provide enabling constraints (as opposed to governing constraints) that allow many different possible outcomes to emerge. For example, we tried a game where in small groups of 4-5 people, we told a story, each adding one word at a time. The title was “The Day We Went To The Airport”. That gave us a “True North”, and the rules allowed a very creative story to emerge. Certainly something that no one person could have come up with individually!

B_SEWU8XIAIXsC5However, given our inexperience with improv, the story was extremely incoherent. I’m not sure we actually made to the airport by the time we had been sidetracked by the stewardesses, penguins and surfing giraffes (don’t ask). It was definitely skimming the edge of chaos, and I can’t help thinking some slightly tighter constraints could have helped. As an aside, I saw these Coyote/Roadrunner Rules recently (right). Adam Yuret pointed out that they were enabling constraints and I wonder if something like this would have helped with coherence?

What’s this got to do with Strategy Deployment? It occurred to me that good strategies provide the enabling constraints with which organisations improvise in collaborating and co-creating tactics to meet their True North. Clarity of strategy leads to improvisation of tactics, and if we take Neil’s Rules of Improv we can tweak them such that an offer is an idea for a tactic, giving:

  • Listen actively for ideas for tactics
  • Accept ideas for tactics
  • Give ideas for tactics in return
  • Explore assumptions (your own and others’)
  • Re-incorporate previous ideas for tactics

How Do I Know If Agile Is Working?

Moving the queen

Moving the queen, Gabriel Saldana, CC BY-SA

“How do I know if Agile is working?” This is a question I’ve been asked a lot recently in one form or another. If not Agile, its Scrum, or Kanban or SAFe or something similar. My usual response is something along the lines of “How do you know of anything is working?” And there generally isn’t a quick and easy answer to that!

I’ve come to the view that Lean and Agile practices and techniques are simply tactics. They are tactics chosen as part of a strategy to be more Lean and Agile. And becoming more Lean and Agile are seen as important to make necessary breakthroughs in performance in order to deliver desired results.

With that perspective, then the answer to “How do I know if Agile is working?” is that you achieve the desired results. That’s probably a long time to wait to find out, however, as it is a trailing measure. It is necessary, therefore, to identify some intermediate improvements which might indicate the results are achievable, and leading measures can be captured to give hat earlier feedback.

The lack of a quick and easy answer to “How do you know if anything is working?” is often because Lean and Agile have been introduced as a purely tactical initiative, without any thought to how they relates to strategy, what measurable improvements they might bring, and how any strategy and improvements will lead to desirable results. In fact very few people (if any) know exactly what those desirable results are!

I’m increasingly trying to work the other way – what the Lean community call Strategy Deployment. For any transformation to work, everybody in the organisation needs to know what results are being strived for, what the strategic goals are that will enable the necessary changes to get there, and what measurable improvements will indicate progress. Then the whole organisation can be engaged in designing and implementing tactical changes which might lead to improvement. Everything becomes a hypothesis and an experiment, which can be tested, the results shared and adjustments made.

In other words, Strategy Deployment leads to organisations becoming laboratories, where Lean and Agile can inform hypothesis on strategies, improvements and tactics. I think its the secret sauce to any transformation, which is why I’ll be talking about it more at various conferences over the rest of the year.

The first one is Agile Cymru in a couple of weeks. There’s a few tickets left, and considering the line-up of speakers, and the ticket cost, its incredible value. I highly recommend going, and I hope to see you there!


Strategy Deployment, the X-Matrix and Kanban Thinking

Strategy Deployemnt

Kanban Systems are an enabler of evolutionary change. And so is Strategy Deployment. Strategy can be defined as how you will make a positive impact, and this implies change. As the saying goes, “hope is not a strategy”, and neither is doing nothing. Deploying that strategy, as opposed to defining and imposing a tactical plan, enables the evolution of the tactics by the people implementing them.

I have found that putting Strategy Deployment in place is my preferred approach to starting off any change initiative, and that as suggested above, there is a strong synergy with a kanban-based approach. (This is not surprising, given the roots of both in Toyota and Lean). In particular, I have been using a format known as the X-Matrix to setup Strategy Deployment.

The X-Matrix

The X-Matrix is a cornerstone of Strategy Deployment. It is an A3 format that provides a concise and portable shared understanding of how strategy is aligned to the deployed tactical initiatives, alongside leading indicators of progress and anticipated end results. I learned about the X-Matrix from the book “Hoshin Kanri for the Lean Enterprise” by Thomas L. Jackson, and I have previously blogged about how we used the approach at Rally.

CD Form 1-2_A3-X X-matrix

The X-Matrix has 5 primary sections, all of which are connected. At the bottom, below the X, are the results that we hope to achieve. To the left of the X are the key strategies that will get us to those results, and to the immediate right of the X are the measures of improvement that indicate how well we are doing. (Note that this is labelled process as it refers to process improvements). At the top, above the X, are the tactics that we will use to implement the strategy. Finally, on the far right are the teams that will be involved in the work. To link these together, the corners of the X-Matrix are used to show the strength of correlation or contribution between the different elements.

Thus it becomes easy to visualise and explore how a strategy, or a measure, correlates to achieving results. Similarly, it is easy to see and discuss how a tactic will correlate to achieving a strategy, or how it will contribute to moving the needle on a measure. And it is clear who is accountable or involved in each tactic. Having all this on a single page helps creating clarity and alignment on the why, how, what and who of the work.

Kanban Thinking

This works well because it wraps all the elements of Kanban Thinking nicely. The results are equivalent to Impacts, the process improvement measures are ways to Sense capability, the strategies can be derived from exploring various Interventions and the tactics are the experiments created to Search the landscape. (Note: While all the examples I have seen have financial results, focussing on value based impacts, there is no reason why flow and potential based impacts could not be forecast with alternative results).

What I really like about Strategy Deployment, and the way Jackson describes it in his book, is that it is a form of nested experimentation. From an organisations long-term vision, through its strategy, to tactics and day to day operations and action, each level is a hypothesis of increasing granularity. As each experiment is run, the feedback and learning is used by the outer levels to  steer and adjust direction. Thus a learning organisation is created as the learning is passed around the organisation in a process known as ‘catchball’, and within this context, Kanban Thinking (and the Kanban Method) provides a synergistic means to running experiments and creating learning.

Do you know what results your organisation are aiming for? Do you know the strategies being used and how they should lead to the results? Do you know what improvement measures should indicate progress towards the results? Do you know how your tactical work implements the strategy and which indicators it should improve? Are all these elements treated as hypothesis and experiments to create feedback and learning with which to steer and adjust?

If you’d like help answering these questions, using the X-Matrix, let me know!