Strategy Deployment and Spotify Rhythm

This is the third in what has turned into a mini series exploring the relationship between Strategy Deployment and other approaches (see Strategy Deployment and Fitness for Purpose and  Strategy Deployment and AgendaShift).

Last month, Henrik Kniberg posted slides from a talk he gave at Agile Sverige on something called Spotify Rhythm which he descibes as “Spotify’s current approach to getting aligned as a company”. While looking through the material, it struck me that what he was describing was a form of Strategy Deployment. This interpretation is based purely on those slides – I haven’t had a chance yet to explore this more deeply with Henrik or anyone else from Spotify. I hope I will do some day, but given that caveat, here’s how I currently understand the approach in terms of the X-Matrix Model.

Spotify Rhythm: Taxonomy

The presentation presents the following “taxonomy” used in “strategic planning”:

Company Beliefs – While this isn’t something I don’t talk about specifically, the concept of beliefs (as opposed to values) does tie in nicely with the idea that Strategy Deployment involves many levels of nested hypotheses and experimentation (as I described in Dynamics of Strategy Deployment). Company Beliefs could be considered to be the highest level, and therefore probably strongest hypotheses.

North Star & 2-Year Goals – A North Star (sometimes called True North) is a common Lean concept (and one I probably don’t talk about enough with regard to Strategy Deployment). It is an overarching statement about a vision of the future, used to set direction. Decisions can be made based on whether they will move the organisation towards (or away from) the North Star. Strategy Deployment is ultimately all in pursuit of enabling the organisational alignment and autonomy which will move it towards the North Star. Given that, the 2-Year Goals can be considered as the Results that moving towards the North Star should deliver.

Company Bets – The Company Bets are the “Big Bets” – “large projects” and “cross-organisation initiatives”. While these sound like high level tactics, I wonder whether they can also be considered to be the Strategies. As mentioned already, Strategy Deployment involves many levels of nested hypothesis and experimentation, and therefore Strategy is a Bet in itself (as are Results , and also Beliefs).

Functional & Market Bets – If the Company Bets are about Strategy, then the Functional and Market Bets are the Tactics implemented by functional or market related teams.

DIBB – DIBB is a framework Spotify use to define bets and “make the chain of reasoning explicit” by showing the relationships between Data, Insights, Beliefs and Bets. Part of that chain of reasoning involves identifying success metrics for the Bets, or in other words, the Outcomes which will indicate if the Bet is returning a positive payoff.

While this isn’t an exact and direct mapping it feels close enough to me. One way of checking alignment would be the ability for anyone to answer some simple questions about the organisations’ journey. I can imagine how Spotify Rhythm provides clarity on how to answer these questions.

  • Do you know where you are heading? North Star
  • Do you know what the destination looks like? 2 Year Goals (Results)
  • Do you know how you will get there? Company Bets (Strategies)
  • Do you know how you will track progress? DIBBs (Outcomes)
  • Do you know how you will make progress? Functional & Market Bets (Tactics)

One final element of Spotify Rhythm which relates to Strategy Deployment is implied in its name – the cadence with which the process runs. Company Bets are reviewed every quarter by the Strategy Team (another reason why they could be considered to be Strategies) and the Functional and Market Bets – also called TPD (Tech-Product-Design) Bets – are reviewed every 6 weeks.

I’d be interested in feedback on alternative interpretations of Spotify Rhythm. Or if you know more about it than I do, please correct anything I’ve got wrong!

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

Strategy Deployment and Agendashift

Agendashift is the approach used by Mike Burrows, based on his book Kanban from the Inside, in which he describes the values behind the Kanban Method. You can learn more by reading Mike’s post Agendashift in a nutshell. As part of his development of Agendashift, Mike has put together a values based delivery assessment, which he uses when working with teams. Again, I recommend reading Mike’s posts on using Agendashift as a coaching tool  and debriefing an Agendashift survey if you are not familiar with Agendashift.

After listening to Mike talk about Agendashift at this year’s London Lean Kanban Day I began wondering how his approach could be used as part of a Strategy Deployment workshop. I was curious what would happen if I used the Agendashift assessment to trigger the conversations about the elements of the X-Matrix model. Specifically, how could it be used to identify change strategies, and the associated desired outcomes, in order to frame tactics as hypotheses and experiments. Mike and I had a few conversations, and it wasn’t long before I had the opportunity to give it a go. This is a description of how I went about it.

Assessment & Analysis

The initial assessment followed Mike’s post, with participants working through individual surveys before spending time analysing the aggregated results and discussing strengths, weaknesses, convergence, divergence and importance.

Strategies

Having spent some time having rich conversations about current processes and practices, triggered by exploring various perspectives suggested by the survey prompts and scores, the teams had some good insights about what they considered to be their biggest problems worth solving and which required most focus. Getting agreement on what the key problems that need solving are can be thought of as agreeing the key strategies for change.

Thus this is where I broke away from Mike’s outline, in order to first consider strategies. I asked the participants to silently and individually come up with 2 to 3 change strategies each, resulting in around 20-30 items, which we then collectively grouped into similar themes to end up with 5-10 potential strategies. Dot voting (with further discussion) then reduced this down to the 3 key change strategies which everyone agreed with.

To give some examples (which I have simplified and generalised), we had strategies around focussing collaboration, communication, quality, product and value.

Outcomes

Having identified these key strategies, the teams could then consider what desired outcomes they hoped would be achieved by implementing them. By answering the questions “what would we like to see or hear?” and “what would we measure?”, the teams came up with possible ways, both qualitative and quantitative, which might give an indication of whether the strategies, and ultimately the tactics, were working.

Taking the 3 key strategies, I asked small groups of 3-5 people to consider the outcomes they hope to achieve with those strategies, and then consolidated the output. One reassuring observation from this part of the workshop was that some common outcomes emerged across all the strategies. This means that there were many-to-many correlations between them, suggesting a messy coherence, rather than a simplistic and reductionist relationship.

Some examples of outcomes (again simplified and generalised) were related to culture, responsiveness, quality, understanding and feedback.

Hypotheses

Once we have strategies and outcomes, the next step is to create some hypotheses for what tactics might implements the strategies to achieve the outcomes. To do this I tweaked Mike’s hypothesis template, and used this one:

We believe that <change>

implements <strategies>

and will result in <outcomes>

With this template, the hypotheses are naturally correlated with both strategies and outcomes (where the outcomes already consist of both subjective observations and objective measures).

I asked each participant to come up with a single hypothesis, creating a range of options from which to begin defining experiments.

For example (vastly simplified and generalised!):

We believe that a technical practice

implements a quality related strategy

and will result in fewer defects

Actions

This as far as we got in the time available, but I hope its clear that once we have hypotheses like this we can start creating specific experiments with which to move into action, with the possibility that each hypotheses could be tested with multiple experiments.

Results

While we didn’t formally go on to populate an X-Matrix, we did have most of the main elements in place – strategies, outcomes and tactics (if we consider tactics to be the actions required to test hypotheses) – along with the correlations between them. Although we didn’t discuss end results in this instance, I don’t believe it would take much to make those explicit, and come up with the correlations to the strategies and outcomes.

On a recent call with Mike he described Agendashift in terms of making the agenda for change explicit. I think that also nicely describes Strategy Deployment, and why I think there is a lot of overlap. Strategy Deployment makes the results, strategies, outcomes and tactics explicit, along with the correlations and coherence between them, and it seems that Agendashift is one way of going about this.

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

Strategy Deployment and Fitness for Purpose

David Anderson defines fitness for purpose in terms of the “criteria under which our customers select our service”. Through this lens we can explore how Strategy Deployment can be used to improve fitness for purpose by having alignment and autonomy around what the criteria are and how to improve the service.

In the following presentation from 2014, David describes Neeta, a project manager and mother who represents two market segments for a pizza delivery organisation.

As a project manager, Neeta wants to feed her team. She isn’t fussy about the toppings as long as the pizza is high quality, tasty and edible. Urgency and predictability is less important. As a mother, Neeta want to feed her children. She is fussy about the toppings (or her children are), but quality is less important (because the children are less fussy about that). Urgency and predictability are more important. Thus fitness for purpose means different things to Neeta, depending on the market segment she is representing and the jobs to be done.

We can use this pizza delivery scenario to describe the X-Matrix model and show how the ideas behind fitness for purpose can be used with it.

Results

Results describe what we want to achieve by having fitness for purpose, or alternatively, they are the reasons we want to (and need) to improve fitness for purpose.

Given that this is a pizza delivery business, its probably reasonable to assume that number of pizzas sold would be the simplest business result to describe. We could possibly refine that to number of orders, or number of customers. We might even want a particular number of return customers or repeat business to be successful. At the same time operational costs would probably be important.

Strategies

Strategies describe the areas we want to focus on in order to improve fitness for purpose. They are the problems we need to solve which are stopping us from having fitness for purpose.

To identify strategies we might choose to target one of the market segments that Neeta represents, such as family or business. This could lead to strategies to focus on things like delivery capability, or menu range, or kitchen proficiency.

Outcomes

Outcomes describe what we would like to happen when we have achieved fitness for purpose. They are things that we want to see, hear, or which we can measure, which indicate that the strategies are working and which provide evidence that we are likely to deliver the results.

If our primary outcome is fitness for purpose, then we can use fitness for purpose scores, along with other related leading indicators such as delivery time, reliability, complaints, recommendations.

Tactics

Tactics describe the actions we take in order to improve fitness for purpose. They are the experiments we run in order to evolve towards successfully implementing the strategies, achieving the outcomes and ultimately delivering the results. Alternatively they may help us learn that our strategies need adjusting.

Given strategies to improving fitness for purpose based around market segments, we might try new forms of delivery, different menus or ingredient suppliers, or new alternative cooking techniques.

Correlations

I hope this shows, using David’s pizza delivery example, how fitness for purpose provides a frame to view Strategy Deployment. The X-Matrix model can be used to tell a coherent story about how all these elements – results, strategies, outcomes and tactics – correlate with each other. Clarity of purpose, and what it means to be fit for purpose, enables alignment around the chosen strategies and desired outcomes, such that autonomy can used to experiment with tactics.

VN:F [1.9.22_1171]
Rating: 4.0/5 (1 vote cast)

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
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
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
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
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

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

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.

Drive

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.

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

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.

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

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.

Strategy

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.

Deployment

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.

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

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

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

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.’

and

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.’

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

Kanban Deployment with the X-Matrix

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

Let me explain…

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

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

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

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

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

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

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

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

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

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