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.

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

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!

Nine Surprising Strategy Deployment Books with Powerful Lessons

Strategy Deployment Bookshelf

In a recent post, I said I would put together a list of recommended books that have influenced my thinking on Strategy Deployment over the years. This post includes that list! Most of them I have previously blogged about in my series on Strategy Deployment And other approaches, and I have included links to those posts here as well.

Getting the Right Things Done: A Leader’s Guide to Planning and Execution by Pascal Dennis
  • A very accessible book from the LEI which introduces the basic concepts of Strategy Deployment. It includes sample A3 templates, although not the X-Matrix.
Hoshin Kanri for the Lean Enterprise: Developing Competitive Capabilities and Managing Profit by Thomas L. Jackson
  • A less accessible book, but one which introduces and describes the X-Matrix in great detail. While not an easy ready, and very manufacturing focussed, it contains a number of nuggets of gold.
The 4 Disciplines of Execution: Achieving Your Wildly Important Goals by Sean Covey and Chris McChesney and Jim Huling
Idealised Design: How to Dissolve Tomorrow’s Crisis. . .Today by Russell L. Ackoff
  • Another more general business book that puts the emphasis on setting a trajectory of change (the idealised design) rather than defining a target solution.
  • I referenced this book in Strategy Deployment and Idealised Design
Good Strategy Bad Strategy: The Difference and Why it Matters by Richard Rumelt
  • This is the best book on strategy I have read so far. Rumelt has great insights and practical recommendations on how to create a good strategy and how to avoid a bad strategy.
  • I referenced this book in Good Agile Bad Agile
Playing to Win: How Strategy Really Works by A. G. Lafley and Roger L. Martin
  • Another great book on how to define a good strategy which describes the Strategic Choice Cascade and a set of powerful questions to ask about a strategy.
  • I referenced this book in Strategy Deployment and Playing to Win
The Art of Action: How Leaders Close the Gaps between Plans, Actions and Results by Stephen Bungay
  • This book describes and introduces the concept of auftragstaktik from General Helmuth von Moltke, the Chief of the Prussian General Staff during the Franco-Prussian War. Bungay applies that to businesses with the Directed Opportunism model.
  • I referenced this book in Strategy Deployment and Directed Opportunism
Turn the Ship Around!: A True Story of Turning Followers into Leaders by L. David Marquet
Team of Teams: New Rules of Engagement for a Complex World by General Stanley McChrystal with Tantum Collins, David Silverman and Chris Fussell

That’s nine so far. I’m sure the list will grow and I’ll try and keep this page updated when it does.

Strategy Deployment and Team of Teams

This post is about Strategy Deployment and the book Team of Teams: New Rules of Engagement for a Complex World by General Stanley McChrystal, with David Silverman, Tantum Collins, and Chris Fussell. It’s another great book which has nothing to do with Lean or Agile explicitly. However, it contains some great, relevant stories and lessons from the post-9/11 war in Afghanistan and the Middle East.

It is another post comparing my views on Strategy Deployment and other approaches. This is because there are a couple of key points that jumped out at me in relation to Strategy Deployment. First, the description of what a Team of Teams actually is. Second, the description of the overall approach as an example of Strategy Deployment.

What is a Team of Teams?

The following diagram sums up the way the book defines a Team of Teams, compared to how I think many people think of it. This includes me before I read it!

Team of Teams Structure
Team of Teams Structure

In other words:

on a team of teams, every individual does not have to have an relationship with every other individual; instead the relationships between the constituent teams need to resemble those between individuals on a given team.

Team of Teams p128

The important element for me is the differentiation between a Team of Teams and a Command of Teams. I often see scaled agile structures (such as the SAFe Agile Release Train) referred to as a Team of Teams. In most cases, I would say they are actually a Command of Teams. Similarly, a Strategy Deployment structure can often be more of a Command of Teams. In hindsight, the visualisation I used in a previous post on the Dynamics of Strategy Deployment is guilty of this.

I recently came across a post on Creating Learning Organisations which included a picture of what Russell Ackoff called a Circular Organisation. While not exactly the same as what is described in Team of Teams, I think it is a closer representation of a possible way of creating that dynamic.

McChrystal describes that dynamic by saying “we didn’t need every member of the Task Force to know everyone else; we just needed everyone to know someone on every team.”

The Circular Organisation

How does this relate to Strategy Deployment?

Team of Teams introduces the concepts of empowered execution and shared consciousness. Shared consciousness is defined as a “state of emergent, adaptive organisational intelligence”. Empowered execution is described as when “officers, instead of handing the decision to me and providing guidance, were now entrusted with the responsibility of a decision”. The two go hand in hand as shown in the following diagram.

Team of Teams Dynamics

In other words:

The speed and interdependence of the modern environment create complexity. Coupling shared consiousness and empowered execution creates an adaptable organisation able to react to complex problems.

Team of Teams p245

This strikes me as very similar to the Alignment and Autonomy model described by Stephen Bungay. Autonomy is equivalent to Empowered Execution, and Alignment is equivalent to Shared Consciousness.

From this, we can use my definition of Strategy Deployment as “any form of organisational improvement in which solutions emerge from the people closest to the problem”. Empowered execution is what enables the solutions to emerge from the people closest to the problem. Shared consciousness is what creates a common understanding of what those problems are and their organisational context.

Team of Teams is another book which I’ll be adding to my list of top recommendations for people wanting to learn more about Strategy Deployment. I really need to publish that list somewhere!

3 Amazing Reasons Your Agile Transformation May Go South

The Antarctic expedition map (Amundsen - Scott) as a metaphor for Agile Transformation
Antarctic Expedition Map (Amundsen – Scott)

This is another post inspired by a podcast – this time Tim Hartford’s Cautionary Tale on The South Pole Race: David and Goliath on Ice. I believe that there are important lessons that we learn from that story that we can apply to agile transformation.

To set the scene, here is Tim’s summary of the story. I recommend listening to the whole podcast for more detail.

1910: Two men are racing one another to be the first to reach the South Pole. Captain Robert Falcon Scott heads a well-financed, technologically-advanced expedition – aiming to reach the pole in the “proper” and heroic way… on foot. Roald Amundsen’s effort is more modest, relying on cheap sled dogs to carry him to victory.

Scott – for all his money, for all his fancy equipment, for all his institutional-backing – is doomed to failure in the ice wastes of Antarctica. Why?

https://timharford.com/2022/07/cautionary-tales-south-pole-race-david-and-goliath-on-ice/

Was it poor leadership, or bad luck? Could Scott have simply implemented the plan better? My takeaway from the conclusion was that there were three reasons; Scott’s expedition was over-resourced, under-focussed and incoherent. Let’s unpack those slightly and explore what we might learn in terms of agile transformations.

Over-resourced

Firstly, Scott’s expedition was a big solution, with large investments from numerous stakeholders. As a result, this added unnecessary complexity, and set unreasonable expectations of the success of the mission. On the other hand, Amundson had a much smaller boat and crew and kept his mission low-key.

How effective are agile transformations that are set up with huge budgets, spent on a multitude of teams, with expensive training and consulting? Conversely, would a smaller, simpler and lower key approach deliver better results? Are there elements of your agile transformation that you could get rid of?

Under-focussed

Secondly, while Scott publicly said that the goal of the mission was to be the first to reach the South Pole (i.e. speed), his investors had other priorities. Therefore, while racing to the pole, they also wanted Scott to perform scientific research and experiment with new innovations. Both of these additional pursuits ultimately slowed him down. On the other hand, Amundson had the single focus of reaching the South Pole first.

How effective are agile transformations that have unclear goals, or multiple competing priorities? Conversely, would a single, clear intent deliver better results? Does your agile transnformation have a single, clear intent that everyone is aligned to?

Incoherent

Finally, the combination of the above two reasons resulted in a mix of big choices and decisions in advance. These ultimately contradicted each other and didn’t work together as a whole when put into action. Consequently, the desire for research meant that they landed further away from the pole. Similarly, the desire to innovate meant that they took equipment that slowed them down. On the other hand, Amundson was set up with just what he needed to get to the South Pole quickly, with all aspects complementing each other.

How effective are agile transformations that are pre-designed and pre-defined solutions which don’t fit the context? Conversely, would a more harmonious and flexible approach, which can better adapt to the context deliver better results? Does your agile transformation have just what is needed, with elements working together to achieve the goal without unnecessary conflicts or contradictions?

So what?

In conclusion, I believe these three lessons can help in thinking about how to take a Strategy Deployment approach to agile transformation (or any transformation). To summarise:

  1. Start small and simple with what you have and know now. (e.g. Present Thinking)
  2. Have clarity of intent which aligns everyone on a single common goal (e.g. a True North).
  3. Take small, compatible rational steps toward the goal and learn on the way. (e.g. Improvise)

It also strikes me, that these 3 heuristics are remarkably similar to how Mike Burrows describes a Wholehearted organisation. I don’t think that’s a coincidence!

Strategy Deployment and Idealised Design

RTF W38, 1952, Alemania Oriental

This post introduces Idealised Design, as described in the book Idealized Design: How to Dissolve Tomorrow’s Crisis…Today by Russell L. Ackoff, Jason Magidson and Herber J. Addison, and explores how it relates to Strategy Deployment.

The post is a continuation of the series on Strategy Deployment And other approaches.

What is Idealised Design?

The basic premise of Idealised Design is to imagine that the current system has been destroyed and to redesign the system for the present time. There are two key implications with this. Firstly, you are starting with a blank sheet of paper unconstrained by the past. Secondly, you are designing a system that will work today, not in a perfect future.

Alongside this premise, there are two constraints:

  1. The solution should be technologically feasible. That means it shouldn’t rely on science fiction fantasies or conceptual inventions which do not exist yet such as vapourware.
  2. The solution should be operationally feasible. That means that it can survive in the current environment, which may include any existing culture, structures, processes or policies.

Finally, there is one requirement

  • The solution is capable of being improved. That means that it is not final or perfect, but the first step in an evolution.

In other words:

“The product of an idealised design is neither perfect, ideal, nor utopian, precisely because it can be improved. However, it is the best ideal-seeking system its designers can imagine now.”

How does Idealised Design relate to Strategy Deployment?

As a reminder, my definition of Strategy Deployment is:

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

Idealised Design supports organisational improvement. By imagining the current system has been destroyed, the approach is not to tweak and locally optimise the current solution, but to consider the system as a whole.

Idealised Design is inclusive of the people closest to the problem. By imagining the current system has been destroyed, any expertise in that current system becomes irrelevant. This creates an opportunity to include all perspectives and invites a wider group to come up with new solutions.

Idealised Design is emergent. By creating solutions for the immediate present the focus is on doing “the next right thing” (to quote Anna in Frozen II), or as Dave Snowden puts it, “moving to the adjacent possible and then looking again”. Thus Idealised Design is based on setting a direction and gradually moving towards a True North.

How can Idealised Design implement Strategy Deployment?

Obviously, there is a huge amount of more detail about implementing Idealised Design in the book. However, one way of using the approach that I like is articulated in the Ideal Present Canvas (below) from Jabe Bloom and Ben Mosior. Working through these four sections is a great way to frame conversations about the elements of TASTE that can be used to populate an X-Matrix e.g.

  • True North – what is the orientation of the Ideal Future?
  • Aspirations – what do we want to achieve in the Ideal Future?
  • Strategies – what choices will guide us in how to solve the Present Mess, enable the Ideal Future, and avoid the Future Mess?
  • Tactics – what should we do today in the Ideal Present?
  • Evidence – what would indicate that the Ideal Present is (or isn’t) enabling the Ideal Future?
Idea Present Canvas for Idealised Design

The telephone image refers to the story told by Ackoff about the CEO of Bell Laboratories announcing, “Gentlemen, the telephone system of the United States was destroyed last night”.

Strategy Deployment and SAFe

This is a slightly different variation on my series of posts comparing Strategy Deployment and other approaches. SAFe is definitely not a form of Strategy Deployment, but it does include references to strategy, so this post is more an exploration of how SAFe could work alongside Strategy Deployment.

First, lets get the usual caveats out of the way. I’m not specifically pro or anti SAFe. It has lots of good ideas in it, and they’re not always appropriate. I did my SPC in 2013 and I’ve worked with organisations where it has been helpful, and where its been a disaster. My goal in this post is to try and help understand when and how SAFe can work well more often, by looking through a Strategy Deployment lens. I’m not interested in “No True Scotsman” (or “Deckard Defence” which I’ve just been introduced to) type arguments.

This post has been in draft for a long time as SAFe tends to be a divisive subject. It was only while attending the recent virtual European SAFe Summit and watching talks and chatting with people about strategy, that I came to enough clarity to describe what has been bothering me.

Strategic Themes

Lets first look at where Strategy sits in the SAFe Big Picture.

SAFe includes Strategy at the Portfolio Level as a set of Strategic Themes which guide the Portfolio Vision, and thus the Portfolio Backlog and the Lean Budgets. As such, SAFe uses Strategy to define and fund Value Streams, and the Epics that flow through them. In other words, in SAFe the Value Streams are Tactical investments, and Strategy is implemented through product delivery. As such the usual iterative and incremental techniques work well to allow the products to evolve and emerge based on feedback.

That’s fine when strategy is directly related to the product or service that you are delivering, and when you already have the capability to effectively deliver it. However, what happens when your strategy is more about organisational transformation? What happens if SAFe itself is the Tactical investment, and Strategy is implemented through agile transformation?

I don’t think there is anything explicitly in SAFe which addresses this scenario, even though it is probably the case that most SAFe stories are about the transformation, rather than the product delivered. Experienced coaches will adapt to context and adjust SAFe so that it too can evolve and emerge iteratively and incrementally, aligned to strategy. Without that, however, SAFe easily becomes just another process to be implemented by the book.

Strategy Deployment

What I believe SAFe is missing is an Inspect and Adapt (I&A) cadence at the portfolio level. It’s all very well having I&A cadences in the teams and value streams, but what if the strategy itself is not having any business impact? How does an organisation know if SAFe is helping meet strategic goals, and how does it steer towards better outcomes if necessary?

While SAFe includes the feedback cadences to treat product development as a hypothesis to be tested, it does not contain any feedback cadences to treat SAFe, organisational change, or the strategy itself as a hypothesis to be tested. There are no dynamics of strategy deployment with collaborative exploration of ideas across the whole organisation and nested PDSA cycles around the whole transformation.

I’m slightly wary of suggesting adding even more into SAFe, but given the effort that’s gone into the “Big Picture” and all the other detail in there, I’d prefer to have the strategy and strategy deployment cadence explicit, such that all the other ideas can be treated as options to be experimented with.

I should note that SAFe does now include the Measure & Grow element as “the way a portfolio of value streams evaluates its progress towards business agility”. However, it is also to “determine improvement steps”, so while I can see how the assessments can be used to provide evidence of progress, if I”m being cynical, it feels generic (i.e. not context specific) and more like a SAFe Maturity Model. There is an expectation that SAFe will provide Business Agility, where’s in fact that is just a hypothesis.

There are also KPIs for each Value Stream which are informed by the Strategic Themes, although these still seem to be delivery focused.

Conclusions

In conclusion, it seems to me that SAFe’s focus is on the strategic delivery of a portfolio, but not on the strategic transformation of the organisation. There is no explicit strategy deployment cadence, and as a result any transformation is likely to be treated as a plan to executed rather than being allowed to emerge through experimentation and feedback.

My recommendations for anyone using SAFe for their agile transformation would be to answer the follow questions:

  1. What is the business True North you are heading towards?
  2. What Aspirations do you hope that SAFe will help you achieve?
  3. What Strategies have led you to choose SAFe?
  4. What SAFe Tactics help implement those Strategies?
  5. What Evidence will you regularly review to give feedback on how well SAFe is serving you?

Of course, those are the elements of TASTE and can be visualised on a X-Matrix! By overlaying an X-Matrix on top of a SAFe Transformation, I believe there is a greater chance of adapting the framework as necessary to help an organisation itself adapt to its unique context and situation.

Comparing Strategy Alignment Frameworks

Mattias Skarin has recently posted a comparison of three strategy alignment frameworks – OKRs, Spotify Rhythm and Art of Action Strategy Briefing. I have already posted about these approaches in the past (OKRs, Spotify Rhythm, Directed Opportunism), as well as others, and I liked the way Mattias compared them side by side. In this post I want to add another two into the mix – Four Disciplines of Execution (4DX) and my own TASTE X-Matrix.

I’d recommend going and reading Mattias’s post if you haven’t already so you’re familiar with the context for this one. I’m also assuming that you are familiar with both 4DX and what I call the TASTE X-Matrix as I won’t be explaining them in any detail. Note that when Mattias refers to strategy alignment, I would generally refer to strategy deployment, but I’m pretty sure we mean the same thing!

The Overview

First the summary table. I have kept Mattias’s assessment and added 4DX and the TASTE X-Matrix to the right. I have also added a new Capability (visualisation of status and progress) to the bottom.

CapabilitiesOKRsSpotify RhythmStrategy Briefing4DXTASTE X-Matrix
Setting of goalsyyyyy
Measurabilityyyyyy
Prioritisation(y)yyyy
Identifies main effortyyy
Communicating intent and whyyyy
Transparent “line of sight” to the topyyy
“Is it achievable” feedbackyyy(y)
Self-assessment of achieved objectiveyyy(y)
Situational awarenessy(y)
Freedom/boundaries conversationyy(y)
Has plenty of easy-to-access material in the topicyy
Visualisation of status and progressy

Rationale

4DX

I think of 4DX as an advanced version of OKRs so that’s what my comparison is most similar to. The Wildly Important Goal (WIG) sets the goal, and that WIG and the Lead Measures are by definition measurable. Identifying the Lead Measures brings with it prioritisation and the Cadence of Accountability is around identifying the main effort. The Cadence of Accountability is also the forum for “is it achievable” feedback, the self-assessment of the achieved objective, and freedom/boundary conversations. Finally the Compelling Scoreboard is something I find unique to 4DX and the reason I added the new capability of visualising status and progress.

TASTE X-Matrix

Mattias refers to Hosin Kanri as a framework he could have included, and I think what I am calling the TASTE X-Matrix is close to what I think he means by that. I should also add that with the TASTE X-Matrix, I am not just referring to the X-Matrix A3 on its own, but in combination with Backbriefing and Experiment A3s. Given that the Brackbriefing A3 is heavily influenced by Stephen Bungay’s Strategy Briefing work, then my comparison is very similar to that.

With the TASTE X-Matrix, the Aspirations set the goals, Evidence is measurable, Tactics are prioritised in accordance with Strategy, and the True North and Strategy identify the main effort. The whole matrix, with the various correlations, provides transparent line of sight to he top. The remaining capabilities I have marked as (y) are because they are more associated with the Backbriefing and Experiment A3s than they are with the X-Matrix A3.

Undesirable Consequences

I’d probably frame the undesirable consequences more as risks and challenges, and many are shared by all the approaches. With regard to 4DX and the TASTE X-Matrix specifically I would add:

  • 4DX’s focus on a single Widly Important Goal (WIG) can drive undesirable behaviour with such a narrow focus. The example in the book about Lance Armstrong hasn’t aged well given what we now know if the way he cheated to achieve his WIG.
  • The nature of the TASTE X-Matrix as an A3, along with its related Backbriefing and Experiment A3s, can lead to a focus on the documents rather than the conversations around them. A3s can easily become yet another instruction that get handed down.

Summing Up

I was say that the Pros and Cons of 4DX are more like those of OKRs. 4DX is relatively easy to get started with, and adds some elements which address the communication weaknesses of OKRs.

Similarly, the Pros and Cons of the TASTE X-Matrix are more like those of the Art of Action Strategy Briefing – not surprising considering its influence for Backbriefing. Given it is just my take on the topic, its not surprising that there are not a lot of examples or supporting materials.

Going back to Mattias’s post, what I liked about it was the way it looked at the various approaches from difference perspectives as a way of thinking about strengths and weaknesses, similarities and differences. Hopefully I have added something to that so that, in Mattias’s words you can:

“steal the best ideas and improve […]. Mastery is the craft of continuously upping your game.”