Introducing the Order of the X-Matrix

An Order of the British Empire Medal used as a fun reference to the Order of the X-Matrix.

This isn’t an announcement of a new certification or secret society! Rather, the Order of the X-Matrix is the way that I use it in practice. The order in which I introduce the X-Matrix is TASTE first, followed by the Correlations. However, when I work with a group to populate an X-Matrix, I work through it in a slightly different order.

The Order of the X-Matrix

This is the order I use in practice, as shown in the picture below.

  1. True North
  2. Aspirations
  3. Strategies
  4. Correlations of Strategies to Aspirations
  5. Evidence
  6. Correlations of Evidence to Aspirations
  7. Tactics
  8. Correlations of Tactics to Strategies
  9. Correlations of Tactics to Evidence

There are several reasons for doing this.

Avoiding Confirmation Bias

This is specifically about switching the order of Tactics and Evidence. The risk of discussing Tactics before Evidence is twofold. Firstly, it is easy to jump to the easy or obvious Tactics that have already been previously thought of. This reduces potential creativity and diversity. Secondly, the Evidence that is identified is biased towards confirming that those Tactics are working. In other words, they are specific to those Tactics.

Identifying the Evidence first leads to discussing it relative to the Strategies. Thus the Evidence is more about confirming the Strategies than the Tactics. That then opens up a wider discussion of the Tactics. The conversation becomes about exploring what Tactics might generate the Evidence, rather than what Evidence might validate the Tactics.

This is similar to Agendashift’s Meaning, Measure Method pattern. Strategy provides the meaning, Evidence provides the Measure, and Tactics provide the Method.

Quicker Feedback

By starting to work through the correlations at the first opportunity, the feedback from the discussion and debate happens sooner. Thus, any mismatch or misunderstanding of the correlations between Aspirations and Strategies can be identified quickly. As a result, the group is not wasting time working through the rest of the X-Matrix based on flawed initial assumptions or premises.

Earlier Understanding

Starting on the correlations early also helps participants understand how the X-Matrix works sooner rather than later. The format can appear too complicated and confusing. However, once people grasp the concept through this early hands-on experience, the exercise becomes much more tangible and productive.

Increased Engagement

Finally, quick feedback and early understanding generate increased engagement. I have had participants get genuinely excited by format, and the value it brings. This increased engagement makes the whole exercise much more meaningful, significantly improving the overall outcomes as a result.

This Order of the X-Matrix is how I prefer to run a workshop at the moment. Even with this order, it is still not a purely linear exercise. The feedback, understanding and engagement tend to mean that there is also an iterative nature to the process. As the discussion evolves, the generation of new learning and insights means that previous elements are revisited and the whole X-Matric is further improved.

The Provocative Pluralism of Strategic Agility

Slide from a workshop on Deploying Strategic Agility with the content:
Doing Agile is Tactical
Being Agile is Evidential
Having Agility is Strategic
All in order to be Aspirational

Last week Jose Casal posted on LinkedIn about how Agile and Agility are not the same thing. In that post, he includes a photograph of an old slide of mine with the words “Agility is a Strategy. Agile is a Tactic”. It created a fair amount of reaction so I thought it would be worth expanding on that and describing what I mean by Strategic Agility.

The slide was from a presentation “Turn Your Organisation Into A Laboratory with Strategy Deployment” from Lean Kanban Central Europe in 2015. I originally blogged about Agility is a Strategy, Agile is a Tactic the same year. Additionally, there is another related post which talks about Agility as a strategy. This is about Good Agile/Bad Agile and describes Agile in terms of Richard Rumelt’s Strategy Kernel i.e. Diagnosis, Guiding Policies and Coherent Action.

Chatting with Jose privately he reminded me of a talk from Jean Tabaka called “Tell Me Why: The Golden Circle of Agile Transformation”. We managed to find the slides from when she gave it at GOTO 2011. For me, that shows that these ideas have been around for a long time. Jean was certainly an inspiration for my interest in Strategy Deployment and Strategic Agility. (I miss Jean).

All this also reminded me that I have also used a fuller version of that slide. I found a version (above) in a workshop on Deploying Strategic Agility. I think expresses my intent more clearly.

  • Doing Agile is Tactical.
  • Being Agile is Evidential.
  • Having Agility is Strategic.
  • All in order to be Aspirational.

Let’s unpack that from the bottom up (or Left to Right as Mike Burrows would say).

All in order to be Aspirational

At the end of the day, organisations want to be successful, and they have aspirations for how that success might be realised. In terms of the Golden Circle model reference by Jean, it’s their Why. At this point, Agile is not directly relevant. It’s not the end goal.

Having Agility is Strategic

To achieve those aspirations, organisations often need to change or transform. In terms of Rumelt’s Strategy Kernel, they have a Diagnosis of a problem. Agility can be used as a basis for Guiding Policies to solve that problem. Admittedly, saying Agility is strategic can be considered a Bad Strategy in that it’s what Rumelt would call Fluff. However, Agile can used to identify more specific sources of power which can be leveraged as strategies. For example, I have previously written about Flow, Value and Potential as three agile strategies. Thus Agile guides decisions, and Strategic Agility can be a property that organisations possess and use for strategic advantage.

Being Agile is Evidential

When organisations are using Agility effectively and successfully, it will result in positive outcomes. These outcomes can be thought of as Evidence that Agile is having the desired effect. In other words, Agile can inform leading indicators. Using the definition from the Four Disciples of Execution, those leading indicators are influenceable and predict achieving the aspirations. Thus Agile informs ways of identifying whether organisations have the property of Strategic Agility and whether their strategies are working.

Doing Agile is Tactical

Finally, organisations need to actually implement Agile processes and practices. Thus Agile brings with it an ever-growing toolbox of techniques that organisations can use on their transformation journey. Those tactics are not predefined and prescriptive but need to be discovered based on the Guiding Policies and initial Diagnosis. One way to think about Tactics is in terms of a typology to encourage exploration and experimentation. Thus Agile provides tactics which can be experimented with, to enable organisations to achieve better outcomes which will indicate progress.

Conclusion

There are many arguments about what Agile is, but as I hope I have described above, I consider Agile to be pluralistic. There are many different ways of looking at what Agile means and I have provided just a few. Doing Agile tactically should lead to evidence of being Agile, which should result in having Agility, which should lead to achieving aspirations. Further, Strategic Agility enables Agile pluralism in more than one way! Not only can Agile be defined in multiple ways, but considering Agile to be strategic will result in multiple different incarnations.

Create your version of Agile, and don’t just copy someone else’s.

The Revolutionary Six Strategy Deployment Steps to Effective Change

An image based on one in Strategy Safari. Intended Strategy leads to Deliberate Strategy, which leads to Realised Strategy. However, Deliberate Strategy can also lead to Unrealised Strategy.  At the same time, Emergent Strategy, through many different paths, can also lead to Realised Strategy. The six Strategy Deployment steps are a way enabling Emergent Strategy.

I’ve been working my way through Strategy Safari by Henry Mintzberg, Bruce Ahlstrand and Joseph Lampel. My initial curiosity was around how they describe Emergent Strategy, as pictured to the right, as a way of characterising Strategy Deployment. In the end, my biggest takeaway was a set of six strategy deployment steps that I wasn’t previously aware of. Admittedly, they’ve been around since the 1990’s so arguably they’re not that revolutionary. However, they could have made a huge difference if they had been better known.

Strategy Schools

The book describes 10 “Schools” of strategy which I’ll list for completeness:

  1. The Design School: strategy formation as a process of competition
  2. The Planning School: strategy formation as a formal process
  3. The Positioning School: strategy formation as an analytical process
  4. The Entrepreneurial School: strategy formation as a visionary process
  5. The Cognitive School: strategy formation as a mental process
  6. The Learning School: strategy formation as an emergent process
  7. The Power School: strategy formation as a process of negotiation
  8. The Cultural School: strategy formation as a collective process
  9. The Environmental School: strategy formation as a reactive process
  10. The Configuration School: strategy formation as a process of transformation

I was expecting the Learning School to be the most relevant as being closest to my views on Strategy Deployment as an emergent process. However, I was most surprised by the Configuration school, which provided the big takeaway. Given I generally work in the context of Agile Transformations I found this a particularly interesting perspective, with transformations being between configurations

Managing Change

This view of transformation leads to the concept of managing change between configurations, and this quote jumped out at me:

the best way to ‘manage’ change is to allow for it to happen – to set up the conditions whereby people will follow their natural instincts to experiment and transform their behaviors.

Strategy Safari: Mintzberg, Ahlstad and Lampel

This particularly resonated with me because it reminded me of something Dave Snowden says. I’m probably paraphrasing slightly, but it’s something like “We need to change the energy gradient so that it is easier to do the right thing than do the wrong thing.”

Top-Down v. Bottom-Up

That is all context for the big takeaway. In a discussion of top-down versus bottom-up change, the authors mention two HBR articles that appeared around the same time. One is “Leading Change: Why Transformation Efforts Fail” by John Kotter. The other is “Why Change Programs Don’t Produce Change” by Russell Eisenstat, Bert Spector, and Michael Beer. I’m pretty sure most people have come across Kotter’s “Eight Steps to Transforming Your Corporation”. Especially because SAFe references it heavily. Additionally, I suspect that not many people will have heard of Eisenstat, Spector and Beer’s “Six Steps to Effective Change”. I certainly hadn’t.

What I found telling was that Kotter’s Eight Steps are identified as being more top-down transformation. That’s certainly how I see it played out in most cases. Conversely, Eisenstat, Spector and Beer’s Six Steps are identified as being more bottom-up transformation. As such, I find these more coherent with the way I think about Strategy Deployment. And as a result, they have the potential to be a set of Strategy Deployment steps.

The Six Strategy Deployment Steps

These are the six steps, with my thoughts on how I interpret them in terms of Strategy Deployment steps.

Mobilise commitment to change through joint diagnosis of business problems.

The language of diagnosis is consistent with Rumelt‘s Strategy Kernel of Diagnosis, Guiding Policies and Coherent Action. Therefore, starting with a diagnosis like this is equivalent to starting with Sensemaking and Situational Awareness (e.g. Estuarine Mapping and Wardley Mapping).

Develop a shared vision of how to organize and manage for competitiveness.

This is where the initial Strategy starts to emerge. Again referring to Rumelt’s Strategy Kernel, it’s the formation of the Guiding Policies.

Foster consensus for the new vision, competence to enact it, and cohesion to move it along.

This is the deployment of the strategy through Catchball. As an example, Backbriefing, with its two-way dialogue, is a great means to begin creating consensus, competence and cohesion.

Spread revitalization to all departments without pushing it from the top.

Treating the tactical implementation of the strategy as experimentation avoids top-down transformation. Thus the actual solutions emerge from the people closest to the problems.

Institutionalize revitalization through formal policies, systems, and structures.

This is the communication of the learning from the solutions as they emerge. Additionally, with that communication is the adoption of standards based on the learning. Note that by standards I mean a current best way, rather than the perpetual best way. In Cynefin terms, this is the dynamic which shifts from Complex to Complicated.

Monitor and adjust strategies in response to problems in the revitalization process.

This is Strategy Deployment as Continuous Strategy. Thus there remains a need to sustain the diagnosis, sensemaking and situational awareness. In other words, while these are described as six Strategy Deployment steps, they should be used in an ongoing and non-linear manner. There might be a shift back into Complex.

Conclusion

It’s notable that Kotter’s Eight Steps and Eisenstat, Spector and Beer’s Six Steps were both published around the same time and by colleagues at the Harvard Business School. And despite that, only one – the top-down one – has become popular. I can’t help wondering how different many SAFe transformations would be if it had been the other way around. Personally, I prefer these six Strategy Deployment steps.

Three Quick Tips for Better X-Matrix Communication

A lightbulb sitting on top of a book with some of the pages folded.  Chosen to represent storytelling shedding a light on X-Matrix communication.
Reading enlightens – Art seen at Guruke in Córdoba, Spain.

One of the challenges of the X-Matrix is that it can be initially confusing for people. Their eyes can glaze over when it is presented on its own. I’ve seen various attempts to try and address this with different X-Matrix flavours. However, I don’t think the format is the problem. These three tips are how I now approach the challenge of X-Matrix communication.

Use the X-Matrix for collaboration

The X-Matrix’s core strength is as a collaboration framework. When I work through the format, step by step, people intuitively pick it up as they go. When people are working through the process of completing one, they are building it up piece by piece. It also makes more sense because they are exploring their context and discussing their content.

However, there is a huge amount of information on an X-Matrix. It often takes many hours or days to come to the final coherent and consented content. People cannot be realistically expected to take in all this information in one go. Therefore, while it remains a great tool for collaboration, another approach to X-Matrix communication is required.

Only communicate one part of the X-Matrix at a time

The story behind why and how it was created is missing from the raw X-Matrix. One of my favourite quotes about A3s is that,

“it’s the memory of what was said and felt that creates alignment, not the final piece of paper”.

Thomas L. Jackson: Hoshin Kanri for the Lean Enterprise

Thus when addressing the challenge of X-Matrix communication, we want to tell that story and describe those memories.

Building up the X-Matrix, one element at a time helps introduce the thinking behind it. This allows people to understand the rationale and relationships more gradually. In today’s world of PowerPoint and video calls, this generally means spreading out the X-Matrix over several slides of a presentation. Each slide might focus on a different part of TASTE, or a different set of correlations. Equally, highlighting only some aspects of the X-Matrix, while hiding others, may also be appropriate if that prevents people from being confused or overwhelmed.

Add clarifying details when you communicate

The advantage of spreading out the X-Matrix communication over many slides like this is that it opens up more possibilities. The story can be complemented with additional detail and colour. For example, describing the background of the business landscape. Visualisation techniques and exercises from Agendashift can be useful here. I have previously blogged about Option Orientation with Reverse Wardley Mapping as one example. Alternatively, it could be adding more detail, such as specifics around people, scope or metrics and dashboards.

This also opens up the possibility of using alternative visualisation techniques which might enhance the story. Again, I have previously blogged about using Sankey Diagrams. Having said that, this may prove to be a different acquired taste. I’ve found some people find Sankey Diagrams useful, while others still prefer a simple table.

However, having a single slide per Tactic can form the basis of backbriefing to start getting people engaged in involved in the transformation work. Ultimately, it is this engagement through Catchball that will enhance communication.

The Remarkable Need for Decision-Making Capacity

A pair of decision-dice which might be used when there is no decision-making capacity at all.

Mike Burrows recently published a blog post From Flow to Business Agility where he introduced the idea of “increasing decision-making capacity“. This was in part a reaction to my earlier post on Strategy Deployment and Developer Experience which refers to cognitive load. I still support cognitive load as a useful concept, and I don’t think it’s the same as what Mike is proposing, although there is some relationship.

Having said that, this post is not a rebuttal to his post, but one supporting it. I do consider decision-making capacity to be a valuable idea, and something relevant to Strategy Deployment. Thus I would like to highlight and emphasise a few points that I think are particularly important.

Strategy Deployment and Decision-Making Capacity

As a recap, I define Strategy Deployment as:

Any form of organisational improvement in which solutions emerge from the people closest to the problem.

https://availagility.co.uk/2016/02/05/what-is-strategy-deployment/

A more long-winded way of saying this is that it is this. Strategy Deployment is any form of organizational improvement in which solutions emerge as a result of the people closest to the problem making local decisions about those solutions. Those decisions could be about what the solution looks like, how it is implemented, when it gets resolved, where it fits organisationally, who it involves etc.

In other words, Strategy Deployment requires increasing decision-making capacity.

Why Decision-Making Capacity is Important

Having all the elements of TASTE (True North, Aspirations, Strategies, Tactics and Evidence) might be necessary, but is by no means sufficient. Strategy Deployment needs to involve Continuous Strategy and people need to be willing and able to pivot. Too often strategy becomes a victim of Plan Continuation Bias because no one ever declares that the strategies and plans are not working.

Without this ability to adapt, Strategy Deployment just becomes Strategy Planning and Execution again. To use Mike’s language, without decision-making capacity, Strategy Deployment doesn’t generate organisational viability.

Enabling Decision-Making Capacity

How can we help ensure that organisations have sufficient decision-making capacity to make Strategy Deployment effective? Here are three primary ways (as another 3 Cs).

  1. Content. Specifically having too much content (i.e. WIP) at both the strategic and tactical levels. Too many Strategies lead to them becoming buckets to justify work. That in turn leads to too many Tactics. This unburdens people to have the decision-making capacity in the first place.
  2. Catchball. Having an inclusive and collaborative process which translates the strategies into daily tactical work – and back again. This includes Backbriefing and addressing the Curse of Knowledge. Thus, Catchball engages people’s decision-making capacity which is now freed up.
  3. Cadence. This creates the dynamics of a feedback cycle for planning, steering and learning. Cadence is what establishes the forum for people to frequently identify and acknowledge the results and impact of the decision-making capacity.

To summarise, just because you have all the pieces in place for Strategy Deployment, that’s no guarantee of success. People need the capacity to be able to engage in, make, and learn from local decisions about all aspects of their work. And the psychological safety, although that’s another post for the future probably!

Strategy Deployment and Developer Experience

Triangle depiciting the three Developer Experince dimensions of Feedback Loops, Cognitive Load and Flow State.  Each dimension is at a different corner of the triangle.

In a 2021 paper, Michaela Greiler, Margaret-Anne Storey and Abi Noda defined Developer Experience as “how developers think about, feel about, and value their work“. Subsequently in 2023, along with Nicole Forsgren, they published a follow-up paper titled: “DevEx: What Actually Drives Productivity“. In that paper, they describe three dimensions of DevEx; Feedback Loops and Cognitive Load and Flow State. This post, as part of the series that looks at Strategy Deployment and other approaches, explores how these DevEx dimensions can be applied.

Developer Experience Strategies

Essentially, the three dimensions can be interpreted as strategies themselves:

  • Shortening Feedback Loops
  • Reducing Cognitive Load
  • Increasing Flow State

Using them as guiding policies in this way means that they can inform more tactical investments and initiatives. For example, implementing tooling and automation (e.g. Continuous Delivery) might help shorten feedback loops. Reorganising around value streams and platforms (e.g. Team Topologies) might help reduce cognitive load. Aligning and limiting WIP to strategic portfolios (e.g. Flight Levels) might increase flow state. As an aside, I’m also curious how the current buzz around AI might also help deliver on these strategies by providing faster feedback, being an external augmentation of memory, or reducing interruptions.

Developer Experience Evidence

The paper also discusses measuring DevEx, and suggests both qualitative and quantitative metrics for the three dimensions. See the table below. When I describe the outcomes which would demonstrate Evidence of a successful agile transformation, one of those outcomes is Sustainability. That is being able to continue to deliver successfully over the long term. DevEx can be highly correlated with Sustainability. Developers who have good experiences are likely to be happier, more engaged and work in a way which produces results over an extended period. There are also strong arguments for correlations to many if not all of the other outcomes. As a reminder, they are Productivity, Responsiveness, Predictability, Quality and Value.

Table of metrics for the three dimentsions of developer experience.

Some of these metrics are also associated with DORA and SPACE, which is not surprising given the involvement of Nicole Forsgren in all this research. Those bodies of work provide additional areas to look for DevEx evidence. More traditional Flow metrics (e.g. Cycle Time, Throughput, WIP etc) are also relevant.

Conclusion

Thus, Developer Experience, and specifically these three dimensions, provide a useful lens through which to look at Strategy Deployment for an agile transformation with the X-Matrix. The dimensions can be used as the Strategies themselves and the related measures for the Evidence. The exercise for the organisations and teams is then to correlate those to their Aspirations and decide what Tactics are the right ones to start making improvements.

Strategy Deployment, Foxes and Hedgehogs

Graffiti artwork to visulasise foxes and a hedgehogs. A fox is sitting down in a forest looking to the left. Behind it is a hedgehog also looking to the left.

I recently came across the idea of foxes and hedgehogs in a Cautionary Tales podcast episode. It has inspired this post in my occasional series on Strategy Deployment and other ideas. Isaiah Berlin popularised the metaphor in an essay and subsequent book, which is based on an excerpt from a classic poem from ancient Greece.

“The fox knows many things, the hedgehog knows one big thing”.

Archilochus

Subsequently, numerous authors and academics have referenced it, including Philip Tetlock in his work on Superforecasting.

What are foxes and hedgehogs?

Telock argues that so-called experts can be considered to be hedgehogs, and are generally wrong in their predictions. Meanwhile, superforecasters can be considered to be foxes and are more likely to be correct in their predictions. The difference between the two types of people is that foxes explore many options and possibilities and are more likely to change their minds. However, hedgehogs focus on one big idea that they think is the right one and therefore don’t change their minds.

Why is this relevant?

While this distinction between two types of people is clearly an oversimplification, it does resonate with me. From a Cynefin perspective, hedgehogs tend to think the world is ordered (clear or complicated). Foxes tend to think the world is complex. Cynefin as a sensemaking framework is designed to recognise that there are different domains, that they are all equally valid in context, and that they require different approaches. In the same way, the analogy of foxes and hedgehogs recognises that people have different preferences and tendencies and that they are both valid in context. Thus neither is right or wrong, and it’s even possible to apply the two approaches in combination.

What’s this got to do with Strategy Deployment?

Strategy deployment requires a mix of both fox and hedgehog thinking. The hedgehog brings a clear sense of direction, while the fox brings flexibility and options for progressing on the journey. Using the TASTE model, having a clear True North and Aspirations is a hedgehog attribute. Strategy as an enabling constraint can be thought of as a liminal state. It provides both a hedgehog’s focus with guiding policies and a fox’s freedom to allow solutions to emerge. Using Tactics and Evidence in a portfolio of experiments and bets is a fox attribute.

The X-Matrix brings all of these elements together such that the fox and hedgehog can work together coherently.

A Simple Resolution to the Agile Transformation Conundrum

F22-Raptor accelerating up through the clouds as a metahof for strategic agility as an alternative to agile transformation.

I have been chatting with colleagues recently about our recent shift from offering Agile Transformation services to Strategic Agility services. Many years ago I posted about the Agile Transformation Conundrum, and this is a natural evolution of that thinking.

Agile Transformation

There is a lot of pushback against the word transformation, with many seeing it as a linear, one-off event, that can be completed. A bit like a caterpillar goes through a transformation into a butterfly. It’s a valid point, although alternative words, such as transition, or journey, have the same problem.

However, that’s not why I have a dilemma over the phrase. After all, when an Agile Transformation is successful, there is a significant change that happens. The issue I have is that it places the emphasis on the word Agile as the goal. In other words, the perception is that an Agile transformation is one which has a focus on doing Agile. This brings with it the risk of imposing and inflicting Agile on people.

Transformational Agile

When I talk about Transformation, I prefer to qualify it as Outcome-Oriented and Continuous Transformation. The perception now is that the transformation is one which is never done, and is always moving towards “uncovering better ways” rather than simply implementing new ways.

Thus, I prefer to place the emphasis on the word Transformation rather than Agile. The phrase Transformational Agile might be a better alternative. It suggests that Agile is a means to an end, rather than the end in itself. Even better still, Transformational Agility shifts the focus onto being agile in order to transform.

Strategic Agility

However, even Transformation is not an end goal. Rather, the transformation is required for an organisation to be competitive and adaptive. That leads to the idea of Strategic Agility. In other words, Agility is a strategy and Agile is a tactic. Thus Strategic Agility shifts the focus further to having Agility both as an organisational strategy itself and to enable Strategy Deployment. This brings with it the opportunity to invite and engage with people on how to do that.

This switch from talking about Agile Transformations to talking about Strategic Agility changes the conversation from just how to implement Agile practices, to how to get the many benefits that Agility promises. If you have gone through an Agile Transformation, but are not getting the benefits you had anticipated, then Strategic Agility might be the answer.

Nostalgia, Nirvana and Now Narratives for Navigating Change

Dua Lipa Future Nostalgia album cover used as a reference to narratives about the past present and future.

Nostalgia Narratives

Nostalgia Narratives are stories about how things were better in the past. In doing so, they suggest that we should go back to the good old days. Jason Feifer wrote an article about the phenomenon in which he describes them as stories about how “today’s changes ruined a glorious yesterday – that a golden age is ours to reclaim”. He goes back and researches various golden ages and makes an interesting discovery. Regardless of the golden age, there are always people telling their own nostalgia narratives. Thus we always recall our past as being better than today. All the way back to 3500 BC, when people first began writing down stories!

This explains one challenge with organisational transformations regarding people’s resistance to change. They often cling to how things were done in the past, remembering only the positive aspects and conveniently forgetting the negative ones. This behaviour reflects a form of retrospective coherence, where individuals construct a narrative about the past to align with their desired beliefs.

Nirvana Narratives

There is also an equivalent that I am going to call Nirvana Narratives, which are more focused on the future. (There is probably an established name for this already, but let’s go with the alliteration!). Thus Nirvana Narratives are about how today’s changes will create a glorious tomorrow – that a golden age is ours to attain.

This explains another challenge with transformations. People try and implement a future state which is not appropriate or achievable. In doing so they ignore the reality of the current situation and create resistance by imposing changes that won’t work. This is because the gap between the present and future states is too big to traverse in a single step.

Now Narratives

The alternative approach is to ask people to tell “Now Narratives” which are focused on the present. (Again, please humour me with the alliteration!). By sharing stories about what is happening at this time, we can more readily identify aspects of the here and now. Those are the things that we can target to change today. That could be identifying Obstacles with Agendashift‘s IdOO pattern. Or it could be identifying Constructors and Constraints as defined by Estuarine Mapping. Thus Now Narratives are about how today’s changes will create a more glorious today – that a golden age is ours to conceive.

In other words, Now Narratives help us work towards an Ideal Present. And in doing so, they address the three reasons why you should use Strategy Deployment. Namely, strategy is not deterministic, static or mechanistic.


The image above is the album artwork for Dua Lipa’s Future Nostalgia, which seems like a relevant concept for this post!

Strategy Deployment and Flight Levels

Visualisarion of the 3 flight levels with Flight Level 3 (tretegic level) at the top, then Flight Level 2 (coordination level) in the middle and Flight Level 1 (oprtaitonal level) at the bottom.

This is another post in the series that compares Strategy Deployment and other approaches. This one is about Flight Levels.

What are Flight Levels?

Klaus Leopold created Flight Levels as a way of enabling business agility by connecting team agility to strategy. It has its roots in the Kanban community.

Klaus has described it as “a thinking model that shows a systems architecture connecting all (agile) teams by means of 5 activities (visualize the situation, create focus, establish agile interactions, measure progress, initialize improvements) on 3 flight levels (strategic, coordination, operational).” This can be seen in the image on the right.

Thus at its heart, there are three levels,

  • Strategy
  • Coordination
  • Operation

with 5 activities which happen at every level, and continuously repeat.

  • Visualise the situation
  • Create focus
  • Establish agile interactions
  • Measure progress
  • Operate and improve

Flight Levels and Strategy

Flight Levels describes its mechanism for strategy as SOFI – Stories, Outcomes and Flight Items. It works as follows:

  1. Make Flight Items visible on Flight Level 3 (strategic level) boards
  2. Visualise long-, mid- and short-term Outcomes
  3. Connect your Outcomes with the Flight Items
  4. Provide context with Stories

Flight Levels and the X-Matrix

The above SOFI elements can be mapped on a TASTE X-Matrix quite easily. Firstly, the Flight Items are the Tactics that are being worked on. Then the long-term outcomes can be framed as Aspirations, the mid-term outcomes as Strategies, and the short-term outcomes as Evidence. Further, the various Correlations show the different connections between the Outcomes and the Flight Items.

Finally, the X-Matrix itself provides a lot of context on a single page. However, I would also suggest that using a technique such as Backbriefing will also help with providing additional context as a way of generating Stories.

Thus Flight Levels is a perfect fit for Strategy Deployment. I have said for a long time that “having agile teams does not make you an agile organisation”. In fact, I had this quote printed on a T-Shirt at Agile 2014. Subsequently, that shirt has been lost over time sadly. However, Flight Levels is effectively solving that same problem. Its different levels and activities, alongside SOFI, provide a way of visualising and managing the work, such that “solutions can emerge from the people closest to the problem”.