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!

An Arbitrary Review and Reflection on 2023 Blogging

Brighton Pavillion reflected in water, with 2024 subly overlaod over the top.  Representing a review and reflection of 2023 and looking forward to 2024.
Photo by Robb Banks

I’m not a big fan of New Year’s Resolutions. Mostly because they assume a degree of certainty and predictability about the future that rarely plays out. But also, it seems like an arbitrary and infrequent time to review and reflect! Having said that, at the start of 2023, I did decide to make an intentional effort to blog more.

Reflections

In a review of 2022, I realised that I had only published 5 posts, and that was part of a longer trend. I wanted to get back into the habit of writing more. Therefore, I decided to make sure I scheduled 1-2 hours every week for writing. The idea was to try and get something publishable in that timebox. In general that proved to be successful. While it often took longer than that to make final edits and SEO updates, the timebox was enough of an enabling constraint to focus on getting a core idea out.

By the end of the year, I had published 23 posts – my most productive 12 months in 10 years! I’m aware that is a bit of a vanity metric, but I hope the quality was also good enough at least a few people found them useful! (My most productive year was 2009 with a massive 45 posts!). The strategy seems to have worked so while I still find it hard to get started, I need to keep going in 2024.

Top Posts Published in 2023

These are the top 5 posts I published last year. The #1 in particular struck a chord and was a runaway winner. I’m also surprised that #5 was so popular, but that’s the beauty of blogging regularly. You never know what will resonate and what will fall flat.

  1. The Only Useful Icebreaker Activity Anyone May Ever Need
  2. Strategy Deployment and Flight Levels
  3. Strategy Deployment and Estuarine Mapping
  4. The Evidence To Look For In A Successful Agile Transformation
  5. The Best Agile Accounting Approach To CapEx and OpEx

Top Posts Viewed in 2023

There are the top 10 posts overall last year, regardless of when they were published. It’s interesting to see the mix of newer posts from this year with much older posts from over 10 years ago. Having said that #3 will have been boosed by my recent presentations on the subject.

  1. The Only Useful Icebreaker Activity Anyone May Ever Need
  2. What is Backbriefing?
  3. Fidelity – The Lost Dimension of the Iron Triangle
  4. Strategy Deployment and Flight Levels
  5. Running the Ball Flow Game
  6. How to Measure the Predictability of Agile
  7. What is an X-Matrix?
  8. Portfolio Kanban
  9. Strategy Deployment and Estuarine Mapping
  10. Strategy Deployment, the X-Matrix and Kanban Thinking

There are also a couple of game pages which are still proving to be popular and would have been mixed into this top 10.

So that’s my review and reflection on 2023. It also makes the first post of 2024. That feels like a bit of a cheat, but the important thing for me was to get back into the rhythm and discipline as soon as possible. Hopefully next weeks the content will be more challenging!

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.

Teaming the Push and Pull of People and Projects

Four people gathered around a fifth person at a computer, representing teaming.

The Agile movement popularised a shift to teams which could pull their work, rather than having work pushed onto them. Practices such as Sprint Planning, or WIP Limits enable this. However, I’ve recently been thinking that rather than the people pulling the work, the work should be pulling the people. This seems counter-intuitive, and equivalent to going back to the traditional project-based approach of the past. To differentiate the different approaches, I will describe three basic teaming models.

Pushing People to the Work

This is the typical project teaming model. First, a central group (e.g. a PMO) defines the work up front as a project. Then they form teams and people are pushed to the work by allocating them to the projects. The diagram below visualises this, with the work at the centre, and people being pushed onto it. Apologies for the terrible artwork. I have tweaked the graphics from slides I used for Kanban presentations over 10 years ago!

A represention of teaming which pushes people to the work. Work is in the middle, surrounded by people being pushed towards it.

In reality, people are often pushed onto multiple projects, making things even worse. In the next diagram, notice the unlucky person in the middle who has been allocated across (pushed to) three projects. At the same time, once people have been pushed onto projects, the actual work is often pushed back onto them. Time, scope and cost are fixed, with no allowance for their actual capacity or capability to do the work.

A represention of teaming which pushes people to the work, with multiple projects. Some people are surrounding and being pushed to multiple projects.

People Pull the Work

This is the typical Agile teaming model. First, long-lived and stable teams are formed to align to some product or value stream. Then the work is defined as backlog items (or options) and the teams pull that work as their capacity and capability allow in order to deliver value.

A represention of teaming where people pull the work. Value is in the middle, surrounded by people, and those people are pulling work from a backlog.  There are two teams with two backlogs.

While this model is typically used with single agile teams, it can also be applied at scale with teams of teams. SAFe’s Agile Release Train structure usually consists of pre-formed and fixed teams that have a backlog of work to pull. As a result, PI Planning is often an exercise in managing dependencies between teams by adjusting the backlog and scheduling items into iterations.

Work Pulls the People

This is more of a Dynamic Reteaming model. First, a value stream is identified, and work is defined as backlog items (or options) to flow through the value stream. At the same time, a pool of people is also identified as part of that value stream. Then the people self-organise themselves into teams as necessary to deliver the highest value work, to the best quality, with the fastest flow. Thus, while the work is pulled into the value stream as capacity allows, it then pulls the people required to enable the flow. As new work is pulled in, the teams may reform to better match the skills and experience required by the changes in demand.

What this looks like in practice is a regular cadence where people can come together to review the current work and anticipate future work. In doing so they can re-organise themselves to deliver the highest value work, at the earliest date, to the best quality. A more general quarterly “Big Room Planning” (as opposed to SAFe’s PI Planning format) can be a good way of doing this.

A represention of teaming where the work is pulling the people. Work is in the middle, surrounded by people, with the work pulling those people. The work is part of a backlog with is being pulled to deliver value.

Also, notice that in the above diagram, not everyone is on a team. Sometimes, it makes sense for people to float between teams to enable them to get better. Or they may form an enabling team of their own as per Team Topologies. Similarly, there will realistically be some constraints around who should be on each team. This may be with respect to experience and continuity to maintain consistency and quality of what is being built. Effectively, this dynamic reteaming model shifts team formation away from governing constraints which are independent of the work context. Instead, it shifts towards enabling constraints which allow for the context of the work.