The Evidence To Look For In A Successful Agile Transformation

Six forms of evidence which can indicate the sucess of an agile transformation.

I have recently been exploring in more detail how the X-Matrix might be used for an Agile Transformation. So far I have covered Aspirations, Strategies and Tactics. Following on from those, I will discuss Evidence in this post.

In some ways, this is probably the least controversial and builds on the work of two people who have influenced me greatly.

First is Larry Maccherone. I worked with Larry at Rally where he first published his research into The Impact of Agile Quantified. The second is Troy Magennis. Troy has built on Larry’s work and has written about the Six Dimensions of Team Performance. Consequently, it is these six dimensions that I use as the basis for describing evidence, albeit with some small tweaks in language. They describe important outcomes to look for as part of an Agile Transformation. The image to the right, which is one we use at TEKsystems Global Services, shows these dimensions.

Productivity

Evidence of productivity shows that work can be delivered in greater quantity. Throughput – the number of pieces of work per unit of time – is a good measure of productivity. For example, stories per week. Similarly, velocity can also be a proxy, although it can be too easily gamed. Additionally, the DORA metrics of deployment frequency can also correlate to productivity.

Predictability

Evidence of predictability shows that work can be delivered consistently and reliably. I talk about this in more detail in my post on how to measure the predictability of Agile. In that post, I recommend several measures. They include variability of cycle time, the amount of ageing work in progress or the number of blockers that are causing work to age.

Responsiveness

Evidence of responsiveness shows that work can be delivered quickly. Some form of cycle time is the most common way to measure responsiveness. That could be the full value stream cycle time. Or it could be a more qualified cycle time for a subset of the value stream. The DORA metric of lead time for changes is an example of this.

Quality

Evidence of quality shows that work is being delivered in the right way. The number of escaped defects that are reported after release is one simple way to measure quality. Additionally, some of the other DORA metrics are relevant here as well. Specifically, these are the mean time to restore and change failure rate. Finally, customer satisfaction can also correlate to quality, although this can also show evidence of value.

Sustainability

Evidence of sustainability shows that work can continue to be delivered in the long term. Two aspects of sustainability are important. Firstly, there is technical sustainability in terms of the state of the codebase and architecture. Code analysis tools which measure things like complexity, duplication or unit test coverage can be useful for this. A strong codebase and architecture will be more resilient to future changes. Secondly, there is human sustainability in terms of people’s ability to maintain their levels of performance. Employee or team engagement, or employee churn rates, can be useful measures for this. An unstable team with low morale runs the risk of losing valuable information and knowledge which will slow them down.

Value

Evidence of value shows that the right work is being delivered. Value as an aspiration overlaps somewhat with its use as evidence. Especially when it can often be very contextual and subjective for each organisation. However, strategic alignment can be a good indicator that the right work is being done. That is the percentage of the teams’ work that can be traced back to strategies, both intentionally and explicitly. Additionally, as noted earlier, customer satisfaction can also correlate to value.

It’s worth emphasising a few things for all these forms of evidence. Most importantly, none of these indicators are intended to be used as targets or incentives. As such, there needs to be a balance between them so that no single metric gets too much individual focus. Therefore, it is important to consider the impact of focusing too much on a metric, as well as focusing too little. There will have to be tradeoffs and they can’t all be perfect!

I haven’t given an exhaustive list here, and I’m always interested in learning about alternative indicators. So, if you have your favourites that I haven’t mentioned, please let me know!

The Sankey Diagram As A Simple Addition To The X-Matrix

The original 1898 Sankey Diagram showing the thermal efficiency of a steam engine

The Sankey Diagram can be a simple but powerful technique which can complement, and possibly enhance the X-Matrix. This post will show how.

What is a Sankey Diagram?

A Sankey Diagram is a visualisation technique which shows the flow between nodes. The link widths usually represent the magnitude of the relationship, and colour can also display other attributes. It’s named after Matthew Henry Phineas Rile Sankey who used the style in his 1898 diagram (on the right) showing the thermal efficiency of a steam engine .

How it can be helpful?

I first came across the Sankey Diagram from Troy Magennis who uses it in one of his spreadsheets to show the flow of work from strategies, to work, to teams. This is an example of his:

Planning Sankey Diagram from Troy Magennis
Planning Sankey Diagram by Troy Magennis

I find this visualisation extremely powerful and have recently been using the approach as a complementary technique alongside the X-Matrix.

A Simple Example

One of the powerful aspects of the X-Matrix is its ability to show all the elements, and the messy coherence between them, of the TASTE model for Strategy Deployment. However, the downside is that there is a lot to take in, and it can be overwhelming. A simple solution is to present each corner of the matrix separately (i.e. each corner matrix). Thus there opens up the possibility of visualising those separate relations more simply as well. Consequently, the Sankey Diagram becomes a useful approach.

Using the example of Aspirations and Strategies from a couple of recent posts, I have created an example shown on the X-Matrix as below. In doing so, I have suggested some plausible relationships between them with the typical full and empty dots. A full dots represent a strong and direct contribution of a Strategy to an Aspiration. Similarly, an empty dot represents a weak or indirect contribution of a Strategy to an Aspiration.

Converting this into a Sankey Diagram gives us the following (generated with SankeyMATIC). The dark red link is the equivalent of the strong and direct full dot. The light green link is the equivalent of the weak and indirect empty dot. I could also have used the width of the links to show relative strength and directness, and colour to represent the originating Strategy.

Future Potential

This opens up the possibility of visualising a full X-Matrix as a Sankey Diagram, with links instead of dots. It is possible for Sankey Diagrams to be circular and show loops. However, that’s not somethng I’ve explored in detail yet. The generators I’ve looked at so far don’t look like they will make it easy to get the right layout and the effort might outweight the benefit. I’d love to be proved wrong though!

Three Agile Strategies That Will Make A Strong Impact

The impact of something dropping into water, with splashes and ripples, representing agile strategies making an impact on a business
Impact by Walter-Wilhelm

Much of my recent writing about Strategy Deployment has been driven by the idea that Agility is a strategy while Agile is a Tactic. However, Agility is a very broad topic, and can easily slip into being a buzzword or platitude. In other words Bad Agile. This suggests that there are some more useful Good Agile strategies.

When I blogged about deploying strategies as choices I suggested that the Agile Manifesto could be interpreted as a set of strategies. They looked like this.

  • Enabling individuals and interactions even over common processes and tools
  • Developing working software even over providing comprehensive documentation
  • Collaborating with customers even over sticking to contractual obligations
  • Responding to change even over keeping to planned commitments

More recently, I’ve been wondering whether there is a better way of describing agile strategies in order to emphasise the core challenges that agile is addressing. That took me back to the Kanban Thinking Impacts that I described as part of the Kanban Thinking model I created. Those impacts are Flow, Value and Potential.

Flow

A “Flow” strategy is one which focuses on “doing the work right”. This involves organising people into cross-functional teams who can collaborate to deliver work quickly. In other words, work flows through teams rather than people being allocated to work. Further, this can mean a shift from an annual planning cycle where people juggle multiple short-lived initiatives. Instead, there are more frequent and dynamic investments in long-lived value streams. As a result, the business is able to respond to unforeseen challenges and take advantage of unanticipated opportunities.

Using the even-over format, I would describe this as a choice to “Organise for fast flow of change even over long-term certainty of plans“.

Value

A “Value” strategy is one which focuses on “doing the right work”. This involves structuring the work to be able to continuously understand and meet customer needs. As a result, there is usually a shift from projects to products. Projects often try to optimise the cost of work through separate technical or architectural solutions. Conversely, products try to optimise the benefits of the work by collectively prioritising collaborative solutions. As a result, products can be continuously validated and evolved to deliver what is most important to customers. After all, increasing value is infinite while reducing cost is zero-bounded.

Using the even-over format, I would describe this as a choice to “Maximise the value of products even over minimising the cost of projects“.

Potential

A “Potential” strategy is one which focuses on “doing the work sustainably”. This involves working in a way which enables long-term adaptability and learning. As a result, there is a shift from cutting corners and short-term solutions to building quality in and long-term investments. By creating fast feedback cycles, teams can learn more about their products and services and how they are being used. Further, that feedback enables people to have autonomy, mastery and purpose in their work which creates more potential in them. To paraphrase an expression used by Toyota, build people in order to build products.

Using the even-over format, I would describe this as a choice to “Create feedback for long-term potential even over making short-term gains“.

It should be obvious that these three strategies work together. Achieving flow requires organising around value, and delivering value requires achieving flow. Both require building long-term potential. However, they each emphasise something different and important in terms of organising for flow, delivering products of value, and creating potential through feedback.

These three strategies are just the way I think about the core challenges that Agile is addressing. Let me know if you have different strategies and what they leverage.

Abstracting Aspirations with a Value Framework

The end of a rainbow disappearing behind some trees, representing the aspirations which guide towards realising value.

In previous posts, I have described a high-level way of thinking about Agile Tactics for the TASTE model and the X-Matrix. This post follows them by introducing a generic way of thinking about Aspirations.

What are Aspirations?

On the X-Matrix template, I describe Aspirations as the “results we hope to achieve”. Aspirations are just hopes and desires, and that is an important point. They describe ambitions and the size of those ambitions. As such, aspirations are intended to help provide a sense of the magnitude and scale of the journey, along with the direction set by the True North. I sometimes ask the question, “at the end of the year (or another period), how will we know if we have been successful?” The goal is to be able to recognise progress and achievement. That may be subjective, and not have any specific numbers. Equally, it may be defined in relative terms rather than absolute numbers.

I have already discussed some considerations regarding measures with the X-Matrix to avoid the “tyranny of the explicit” and a “cliché of platitudes”. Additionally, we want to avoid Goodhart’s Law, often stated as “when a measure becomes a target, it ceases to be a good measure”. Thus, aspirations are not targets or specific goals and are not there to incentivise or reward people. Instead, they should help people recognise and focus on what is important.

A Value Framework

With those caveats dealt with, how can we identify aspirations? Typical examples I give tend to be around the nature of a specific business and its business model. For example, that might relate to markets, customers, products, or subscriptions. However, in general, I find that the aspirations can be tied back to a value framework described by Joshua Arnold. I’d recommend reading his post on understanding value which describes the framework in more detail.

In summary, there are four buckets:

  • Increase Revenue – Additional sales to new or existing customers, by delighting or disrupting to increase market share and size.
  • Protect Revenue – Improvements and incremental innovations, to sustain current market share and size.
  • Reduce Costs – Becoming more efficient with improved margins or contribution, to lower costs that are currently being incurred.
  • Avoid Costs – Improvements which sustain and do not increase the current cost base, or prevent costs that are not currently incurred but may be in the future.

Value Buckets as Aspirations

I think that this can be a useful framework to help organisations think through what their aspirations are for their agile transformations. It helps clarify what they hope to achieve through a transformation. For example, it could be that they want to be able to go after new customer segments or markets. i.e. Increase Revenue. Or they may want to improve quality and reduce customer churn. i.e. Protect Revenue. They may want to improve internal processes through automation. i,e. Reduce Costs. Or they may want to increase employee engagement and reduce employee churn. i,e. Avoid Costs.

Thus, the value framework can help articulate what success might look like, in terms of direction and magnitude. As a result, the challenges or opportunities that need to be addressed in order to meet the aspirations can start to be diagnosed and identified. That in turn allows coherent strategies for agile transformations to be explored. I plan to write about this more in a future post.

A crude metaphor might be that Aspirations, and this value framework, can be a guide towards the pot of gold at the end of the rainbow, and help determine when it has been found. However, the Aspirations don’t indicate exactly where that pot of gold is, or guarantee how much will be in it.

How to Distinguish Between Strategies and Tactics

Clipboard with football strategies and tactics

A regular discussion topic when working on Strategy Deployment with the X-Matrix and TASTE is the difference between strategies and tactics. It’s not unusual for items to bounce between the two as people debate the various relationships and characteristics. Similarly, strategies and aspirations get confused, as do tactics and evidence. A warning sign is often when people want to place the same thing in multiple places, which isn’t a helpful conversation.

Development and Deployment

Related to this is the difference between strategy development and strategy deployment. I’ve already described my definition of strategy deployment as “any approach where the solutions emerge from the people closest to the problem”. Given that, strategy development is the identification and articulation of the “problem” (where a problem could also be an opportunity!).

So at a high level, the Strategy is about focusing on a specific “problem” (and hence not focusing on others), and the Tactics are about the “solutions” that are implemented as a result. On the X-Matrix I describe strategies as “the guiding policies that enable choice”. I describe Tactics as “the coherent actions we should take”. Both of these are building on Richard Rumelt’s concept of the Strategy Kernel.

Another way of making the distinction is using Henry Mintzberg’s definition of strategy as a “pattern in a stream of decisions”. From this perspective, the strategy is the pattern (and the guiding policies that form it). Thus the tactics are the decisions (about coherence action) themselves.

In other words, a Strategy is Developed, and Deployed through Tactics. It’s also worth noting that all of those are entangled, it’s not a linear or a top-down process.

Going into a bit more detail, there are five factors which we can consider to help distinguish between strategies and tactics. These are all inspired by Russell Ackoff in his 1990 article on Strategy.

Scope

Strategies tend to be more global, while tactics tend to be more local. Therefore, a strategy is more likely to be at an organisational, or product scope. A tactic is more likely to be at a department or team scope.

Time

Strategies tend to be more long-term, while tactics tend to be more short-term. Therefore, a strategy is more likely to relate to change over years. A tactic is more likely to relate to change over weeks or months.

Magnitude

Strategies tend to be larger endeavours, while tactics tend to be smaller endeavours. Therefore, a strategy is more likely to involve more resources (people, money etc.). A tactic is more likely to involve fewer resources.

Outcome

Strategies tend to be more about effectiveness while tactics tend to be more about efficiency. Therefore, a strategy is more likely to focus on doing the right things. A tactic is more likely to focus on doing things in the right way.

Fractal

Lastly, strategies tend to be lagging while tactics tend to be leading, and like lagging and leading indicators, they are always relative. Something could be tactical at a team level because it is part of a larger, longer-term organisational strategy. At the same time, that could also be strategic for the team because it guides their smaller day-to-day decisions.

It’s this last point that means that Strategy Deployment can start anywhere in an organisation. As a team works out its strategy, it can look upwards and outwards to see how that relates to the wider strategies.

Strategy Deployment and Estuarine Mapping

Wyre Estuary representing Estuarine Mapping
Wyre Estuary

This is in part a follow-up to the two recent posts on a typology of tactics and the associated triads. I was initially inspired to write those posts while attending a series of training sessions on Estuarine Mapping. Having completed that training, I now want to reflect on what I learned and how it relates to Strategy Deployment.

Estuarine Mapping

First, a very quick review of the Estuarine Mapping process for context. For more depth, I’d recommend starting with this description by Dave Snowden, and this experience report by Tom Kerwin. There are three basic steps.

  1. Describe where you are now (the current state) using constraints and constructors. This generates a granular list of items that can be managed.
  2. Visualise these items in terms of the amount of time, and the amount of energy (resource, people, cost) required to make any changes.
  3. Decide which items to take immediate action on, and the type of action, based on that visualisation.

Insights

There were 3 key things that struck me about Estuarine Mapping:

  • It creates a collated view of both strategy and tactics. The positioning and clustering of items on the map inform a choice of ‘why’ to work on some things even over others (the strategy). At the same time, the chosen items represent ‘what’ work will be done (the tactics).
  • It’s a continuous process. There is never a final right answer, but there is an ongoing process of iteration and refinement. That happens across all three steps, and not necessarily linearly. Firstly, identifying and breaking down the constraints and constructors. Secondly, placing and moving them on the map. Finally, identifying and evolving the actions. I can imagine how an Estuarine Map might be a persistent artefact which is revisited and updated on a regular basis to explore what has changed and what the next actions should be.
  • It’s a collaborative effort. The level of engagement and conversation required to explore, identify and refine the elements in the various steps is extremely high. Further, a high diversity of participation will create richer discussions. However, even though it will be intensive and time-consuming, it will be well worth it given the deep insights and novel ideas generated.

Strategy Deployment

On the one hand, I think Esturaine Mapping is more about strategy “development” than “deployment”. The output is focused on identifying the strategic problems to be solved, as opposed to enabling the tactical solutions to emerge. On the other hand, given the collated, continuous and collaborative properties described above, I think it is a perfect fit for a Strategy Deployment. Additionally, Estuarine Mapping identifies many of the elements that can go on an X-Matrix. Specifically:

  • The choices of which items to take action on can easily be phrased as Strategies.
  • The actions themselves, with their types, naturally become Tactics.
  • Where actions require some indicator (e.g. monitoring, or conditional types), then those become the Evidence.

I’m looking forward to having the opportunity to explore Estuarine Mapping in more detail and I’m excited by the potential. Let me know if you’d be interested in being part of that!

Two Triads for the Terrific Typology of Transformation Tactics

Triads
Triads

I’ve joined an online training with Dave Snowden yesterday about his latest thinking on Estuarine Mapping. That is one of the ideas which inspired my last post on a Terrific Typology of Transformation Tactics. In particular, Estuarine Mapping uses two typologies with triads to “generate a list of things which can be managed” – constraints and constructors.

Estuarine Mapping Triads

I’m not going to go into any detail about those typologies here. I would recommend reading the latest posts from Dave on the subject. However, I will describe the general triad pattern Dave is using, and how it gave me a better idea of how to structure the typology.

A few thoughts on why I think this could be useful in relation to Strategy Deployment and the X-Matrix. I describe tactics are the “coherent action we will take”. Another way of saying that could be the “coherent things we will manage”, which is what Estuarine Mapping is designed to explore. Thus I’m curious how Estuarine Mapping can be a way of generating the Tactics. Given that, I wonder whether my typology of tactics might work as an alternative way of generating input for the exercise. On the one hand, the language might be more relatable. On the other hand, it might be too relatable in that preconceptions of the meaning behind those words might narrow people’s thinking.

Transformation Tactics Triads

A reminder of the typology:

  • People – related to roles or leadership
  • Plexuses – related organisational structures or networks
  • Processes – related to workflows or methods
  • Practices – related to techniques or skills
  • Products – related to customer or market deliverables
  • Platforms – related to enabling tools or technologies

Initially, I paired those up, into 3 sets of diads. However, the alternative pattern that Dave uses is to group them into two triads with an overarching diad. That could then look like this:

It’s not perfect, but I’m not sure it has to be. The goal is to trigger people into thinking about what coherent actions they might take, breaking them down into small enough (granular) tactics to decide what to do next and start running experiments.

A Terrific Typology of Transformation Tactics

An example of Transformation Tactics. A pitched melee and a frantically held formation in the second to last room of "The Keep On The Shadowfell."
Desperate Tactics

When I posted the Ultimate X-Matrix for your Agile Transformation, it was only an example because strategy is always contextual. The whole point of Strategy Deployment is that there are no pre-determined answers. Therefore, we cannot simply pre-define and implement transformation tactics.

Having said that, I have recently come around to the idea that I can describe something at a high level of abstraction which could be useful for Lean and Agile transformations.

Typology

I have previously written about Agility as a Strategy itself, with some slightly more granular possibilities. Additionally, I can imagine my earlier Kanban Thinking impacts of Flow, Value and Potential also being used as strategies. I may come back to that in a future post.

However, I have previously thought that Tactics would be too specific to define. That has changed and I now believe that there is a typology that can be used to explore tactics. I’m using typology in a specific way that Dave Snowden uses and describes well in his recent Cynefin St. David’s 2023 post. That is that typologies “stimulate people to think more broadly” as opposed to taxonomies which encourage “classifying things into types”.

The typology of tactics I have come up with is as follows:

  • People – related to roles or leadership
  • Plexuses – related organisational structures or networks
  • Processes – related to workflows or methods
  • Practices – related to techniques or skills
  • Products – related to customer or market deliverables
  • Platforms – related to enabling tools or technologies

Diads

That gives us 6 P’s, which can also be combined into related pairs.

  • People and Plexuses
  • Processes and Practices
  • Products and Platforms

As a result, we can use those pairs as the extreme ends of diads with which we can capture a range of possible tactics. There are two ways I can imagine describing these diads.

  1. More business focussed through to more technical focussed
  2. More social focussed through to more technical focussed (e.g. a socio-technical lens)

Neither of those is a perfect fit and I suspect I’ll need to see how that develops over time.

Usage

Using the typology in pairs like this means that we can lay out the 6 P’s relative to each other, and then start identifying tactics and laying them out relative to those types. I can imagine doing this using Hexis, and possibly even as an alternative input into Estuarine Mapping to decide what tactics are worth experimenting with, and what might be worth avoiding.

Note that this is all theoretical at the moment. I’ve not used the typology in anger yet, let alone explored its application as part of any larger facilitated exercises. However, it is something I do want to try and wanted to put it out here to get any feedback or comments. Let me know in the comments below, or via the usual other channels.

Tensegrity as a Fascinating Metaphor For Strategy Deployment

Tensegrity model
Tensegrity model

I recently came across the concept of Tensegrity. I alluded to this in my last post on Why Strategy Deployment when I referred to elasticity. In this post, I want to expand on that and describe why I think tensegrity might be relevant. I believe it provides an interesting way in which we can think about Strategy Deployment.

What is tensegrity?

The word tensegrity is a portmanteau of “tensional integrity”. A simple definition is that it is:

a way of designing structures that rely on tension, rather than compression for their integrity.

https://tensegrityworld.com/what-is-tensegrity/

This is an excellent video which visually explains the concept:

Tensegrity Explained

Why is tensegrity relevant?

Toward the end of the above video, the human body is given as an example of tensegrity. The fascia and muscle provide the tension and integrity around the skeleton which is in compression.

Some long-time readers of this blog might know that I am a regular runner. As a result, I have written the occasional post which is related to running. Therefore, I found this extremely interesting when I first came across the concept in the book “The Lost Art of Running” by Shane Benzie. Shane builds on the idea by suggesting that to run efficiently, we should take advantage of this tensegrity.

It was the fact of being a tensegrity system that helped us be more efficient. It allowed our bodies to be stretchy and even bouncy, a theory which is quite different from the image of the skeleton supporting us and moving by way of a mechanical lever system, which is the biomechanics view.

The Lost Art of Running by Shane Bezie

Similarly, many people treat organisations as mechanical structures with levers to be pushed and pulled. What if we treat organisations more as elastic systems, where we try to stretch and bounce dynamically, rather than push and pull harder?

How does tensegrity relate to Strategy Deployment?

It’s this idea of focusing on the dynamics rather than the structure that struck me about tensegrity. Consequently, it seemed to be relevant as a metaphor for Strategy Deployment. While I have previously written about the dynamics of strategy deployment and Catchball, tensegrity provides another way of thinking about this. Typically we focus on hierarchies which create integrity through structure and “compression”. Instead, we should grow informal networks which create integrity through elasticity and “tension”.

Thus, tensegrity helps explain how Strategy Deployment and Catchball can create resilience. Having tensional integrity in this way enables organisations to recover more quickly from the unknown and unexpected. The compression roles we typically see as hierarchy are still there, but they are no longer creating rigid structures and fragile organisations. Instead, the tension of the networks can stretch, absorb the change and bounce back again.

Why Strategy Deployment? Here Are Three Great Reasons

Why Strategy Deployment?
Why?

I’ve written a lot about the “what” and the “how” of Strategy Deployment, but never really about “why”. That is probably slightly ironic, given the reasons I’m so passionate about it. The “why” of strategy is often missing from most transformations I am asked to help with. In this post, I hope to address that. I will describe three reasons why you would want to use Strategy Deployment for a transformation, and what the challenges are that it addresses.

Strategy is not deterministic

Firstly, you can’t know everything upfront. Implementing a strategy is not simply a case of putting a plan together and executing it. There are generally too many factors at play. This means that neatly decomposing a problem down into small pieces, cascading it through an organisation, and hoping that all the elements will magically re-combine, doesn’t work.

Instead, Strategy Deployment consists of trying a variety of experiments and probes, which are all plausible and coherent with a sense of direction. The goal is to discover and learn what works and what doesn’t. This messy coherence, as opposed to a neat decomposition, is one of the aspects of the X-Matrix which can be very powerful.

Strategy is not static

Secondly, you can’t define a future state. Even if it was possible to neatly decompose a strategy into a perfect plan, it still probably won’t work. The chances are that by the time it gets implemented, the world will have changed. New competitors, technologies, or other dynamics may have emerged which couldn’t be predicted. Thus the plan soon becomes obsolete.

Strategy Deployment uses feedback and cadences to learn about what is working and not working. These cadences also enable learning about what is changing, evolving and emerging. What might have worked yesterday, might not work today. Rather than striving to implement an Ideal Future, Strategy Deployment focuses more on doing “the next right thing” towards an Ideal Present. As a result, a strategy can be realised step by step instead of a giant leap.

Strategy is not mechanistic

Finally, you can’t impose (or inflict) a transformation on people. Even when working towards an Ideal Present, you still need to engage the people closest to the problem. They are the people who have the best knowledge and experience to discover what to try. It’s not a case of senior leadership coming up with some ideas and telling the rest of the organisation to get them done. Rather than treating the organisation as a mechanical entity which just needs the cogs turning, we should treat is an elastic one which has flexibility, resilience and adaptability. (More on this in a future post).

Strategy Deployment includes Catchball to address just this. Invite people to take part in the transformation. Give them clarity of intent for the transformation. Allow them autonomy and agency to collaborate and be creative with how they meet the intent. I have found backbriefing to be a great way to achieve this.

What have I missed? What other reasons would you give?