The Ultimate X-Matrix For Your Agile Transformation Is Here

Whenever I’ve described the X-Matrix I’ve always had to resort to trivial and made-up examples. This is because real examples are difficult to share due to some form of NDA, and the content means that they need to remain confidential.

However, I have recently finished working on a transformation where the X-Matrix was close to something I could publish. Thus with some simplification and anonymisation, I feel safe to be able to use it. That means that when I say it’s the ultimate one, I mean I’ve finally got around to creating it as an example 🙂

To re-iterate, this is still edited and is still somewhat generic. However, I hope it’s close enough to its original form to be helpful and demonstrate how the X-Matrix might be used. It is not intended to be an exemplar to be copied. In fact, I hope that people question the content, and even find fault with it. After all, as Thomas L Jackson says in Hoshin Kanri for the Lean Enterprise, “it’s the memory of what was said and felt that creates alignment, not the final piece of paper”.

The Example

Given those caveats, here it is, followed by some explanation.

True North

“Instantaneous development and deployment”

The intent of this True North was to describe a future where development teams could implement and release a customer request as soon as it came in. This gave the teams a clear sense of direction and met my 3C’s of a good True North. It was challenging in that the teams were a long, long way from being able to achieve it. Next, it was compelling, in that it was something the teams wanted to be able to achieve. Finally, it was concrete, in that the teams knew what it would take to achieve.

Aspirations

• More releases
• Fewer defects
• Less waste

These were existing measures the organisation was already using for their overall transformation, with defined metrics in place. In this case, waste was considered to be work that was an unnecessary overhead or burden. Using these existing measures as aspirations meant that we could connect what we were doing with the wider organisational effort.

Strategies

• Prioritisation
• Collaboration
• Flow

There was much discussion and debate in coming up with these three strategies. The actual wording was more verbose and more explicitly described the choices we were making. We settled on them as the three main guiding policies that would help us focus. When deciding on any actual changes we were going to make, they should help to improve one or more of these areas in some way. Put another way, these three strategies represented the key challenges we were addressing after the initial diagnosis.

Tactics

• Cross Skilling
• Automation
• Agile Fundamentals
• Product Management

These tactics were the four main areas and workstreams we felt would help make a positive change. They are more specific that the strategies, while still enabling teams to explore different solutions and approaches. In fact, we ended up prioritising Agile Fundamentals, before moving on to Product Management. The other two were longer-term goals and linked to other work that was going on that the teams were able to contribute to.

Evidence

• Productivity
• Responsiveness
• Predictability
• Quality
• Value

The first three of these used standard flow metrics, which we introduced to the teams. Building on this, quality and value both looked at the nature of the work flowing through the teams using simple demand analysis.

Correlations

Having come to an agreement on the different elements of the X-Matrix, the coaching and transformation team discussed the correlations. There was a rich discussion about how the various pieces contributed to and reinforced each other (or not). Inevitably, this led to multiple iterations and evolutions before we settled on this version. In fact, the whole X-Matrix was a result of multiple working sessions where we refined our understanding of what the current situation was, what our approach was going to be, and what we were going to do. Our understanding of the X-Matrix continued to change as we progressed with the work, and we did revisit it a number of times, although we never formally updated it.

Conclusion

I hope that gives a sense of how I use the X-Matrix in my work as part of an agile transformation. I’m also always interested in how other people use it, although I understand how difficult that can be. If you do have something you can share, please let me know. Maybe we can create a collection of examples and show a wider variety of approaches.