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)

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
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

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!

 

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

Understanding SAFe PI Planning with Cynefin

3128266497_077f9144af_z

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

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

Let me explain.

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

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

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

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

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

Dates For Your Diary

I’ve just updated my Calendar page with a couple of conferences coming up, as well as a new date for my Kanban Thinking course.

LeanUX15, New York, April 15-19

This is going to be a great event, with a fantastic line-up of speakers, covering a wide range of topics. I’m going to be talking about my current ideas on Strategy Deployment. If you use the code LeanUXSpeaker you’ll get 20% off. Prices go up on March 21st!

Agile Cymru, Cardiff, July 7-8speaker graphic-01

Another great event,  with another fantastic line-up of speakers! I’m particularly looking forward to this one because I get to go back to Cardiff, where I grew up and went to school.

Kanban Thinking Course, London, May 30-April 1

I’m running another training course with agil8 again in London. Here’s some feedback from the last one I ran:

  • Really engaging.
  • Found it fascinating and to be honest that surprised me.
  • It felt like a university lecture, in a good way! Very insightful and complete.

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

Kanban Thinking Workshop in London

Kanban-thinking-banner

I have another public Kanban Thinking workshop coming up in London (March 5-6), in collaboration with Agil8, and to fill the last few places, I can offer a discount! Book now, using the code KS25 to get 25% off the standard price, and get 2 days of fun, discover how to design a kanban system by populating a kanban canvas, and learn how to make system interventions which have a positive impact.

To wet your appetite, here’s a couple of photos from a recent workshop. (Click for larger versions).

IMG_1371IMG_1370

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

A Kanban Thinking Pixar Pitch

I’ve been using the Pixar Pitch as a fun way for teams to discuss and explore the problem they are trying to solve by telling a story about what has been happening that led to the need for a kanban system. I thought it might be useful to use the formula to tell a dramatised story of what led me to first try using a kanban approach, and why that led to Kanban Thinking.

The Pixar Pitch

Once upon a time there was a team who were using Scrum to manage their work. They were cross-functional, with a ScrumMaster and Product Owner, developing and supporting a suite of entertainment websites for a global new-media organisation.

Every Sprint they prioritised and planned the next couple of weeks, developed and tested functionality, fixed live issues, released updates when ready, and reviewed and retrospected their work.

And every Sprint the team was unhappy with the way they were working. The Product Owner felt that the developers could be more productive, and the developers felt that the Product Owner could be giving more guidance on what build. Stories were completed, but features took a long time to release as the team thrashed to get the functionality right, meet commitments and increase velocity.

So every Sprint they inspected and adapted. The Spring length was shortened to get quicker feedback. The style of User Stories was adjusted to try and focus more on value. And yet things did’t improve significantly.

One day they decided to stop focussing on doing Scrum, and start using ideas from Kanban, experimenting with some different approaches that they hadn’t previously tried.

Because of that they stopped using Sprints and de-coupled their cadences, reprioritising their ready queue every week, planning only when they had capacity to start new work, releasing and reviewing every fortnight, and retrospecting every month.

And instead of breaking work down into small User Stories that would take less than 2 weeks, they focussed on finishing larger MMFs, which might take months in some cases.

And they paid more attention to their Work in Process, in particular making sure they only worked on one large new feature at a time.

And instead of the Sprint Burndown they tracked their work using a Cumulative Flow Diagram, Parking Lot and Lead Time report.

Because of that the whole team became more focussed on delivering valuable features, were more collaborative in how they figured out what the details of those feature were, and were more reliable in when they delivered them.

Until finally everyone was working well together as a much happier group, delivering much more value, and in a good place to continue to improve.

Kanban Thinking

The point of this story is not to try and make one approach sounds better than another, or to suggest that any approach can be a bad choice in some way. Rather it is that the team learned about what would and wouldn’t work by asking questions about their process and experimenting with all aspects of it. The end result might have ended up being exactly what an expert or consultant might have recommended or coached. That’s OK, because what is important is the understanding that was created about why things are as they are. This capability to solve problems, as opposed to implement solutions, sets a team up to continually evolve and improve as their context changes.

This principle – helping teams to solve problems rather than implement solutions – is what fascinated me about kanban when I first came across it and started exploring how it could be used. Its what ultimately led to the emergence of Kanban Thinking as a model for helping achieve this, and the Kanban Canvas as a practical tool.

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