Progress (and performance) over perfection: a pragmatic agile transformation

Written January 2024 in my role as Executive, Domain Operations at NAB

One thing is for sure in 2024, the hype of agile is well and truly past. Looking back on a decade of scaled agile, myself and my colleagues Kirsten Lange and Chris Tansey want to to reflect on the value of these operating models, and especially share some learnings from National Australia Bank’s transition.

Numerous enumerations of principles to make scale agile work, do’s and don’ts and key actions have already been provided by scores of advisors and experts. In this brief article we’ll therefore focus on how we defined our own brand of agile, and how we made it work for us.

As a background it should be noted that NAB never had a dramatic impetus for adopting a new model. We didn’t use it as a vehicle for dramatic cost cutting or substantial organisational restructure. Instead, it was used as a tool to speed up delivery for the bank by improving the clarity on accountabilities for delivery, growing the right capabilities and further improving our colleagues’ motivation to deliver.

Our learnings from changing our operating model are threefold:

1. Tie the implementation of the model to resolving actual organisational impediments.
2. Evolve the model quickly and provide decentralised degrees of control over it.
3. Make things measurable and hold leaders to account for their metrics and their implementation of the model.

1. Solve organisational impediments

As the many experts have noted, scaled agile for its own sake is rarely a success. This is why one-size-fits-all models such as SAFe are useful as a toolbox, but never as a precise recipe.

Starting with the organisation’s pain points helps create groundswell, achieves tangible improvements and keeps us focused on things that need changing.

Some of the impediments we addressed were:

• Distance between our engineers and our banking product people created by our old project-based ways of working as well as lack of ‘tech-savvy’.
• Low speed of delivery and high volume of orchestration type roles

By aligning our product people directly to persistent technology squads in value chain specific ‘Domains’, we truly addressed these pain points to a significant extent. We were able to pick up the speed of delivery by over 20% in terms of features delivered and saw simplification in the number of delivery roles required to get value to customers.

Our capability improvement is still a work in progress. Different to other major Australian organisations adopting similar models, we never sought out tech aligned product people in the project world, instead opting for banking product people in many cases. In some of these cases our banking product people working directly with technology people, getting up to speed with the practice of software delivery as well as their specific digital and tech context proved to be a stretch. Where people were able to make the leap though, we forged true ‘run and change’ product leaders who understand both their banking and engineering products.

2. Evolve the model quickly and with decentralised decision power

Throughout this journey, our core team was looking enviously at other organisations that had big change teams, hordes of consultants and dazzling events to accelerate their transformation. NAB did start off with some support and events to kickstart the transformation, but with the benefit of hindsight, a small and mostly internal team of about 25 people to carry the bulk of the transformation is a blessing.

It forced us to be creative in bringing change to nearly 11.000 colleagues, using the advocacy and implementation power of the Domain leadership and change teams, building on automation and our agile toolset to the maximum extent and catering for different degrees of maturity.

A cynical view would be that our model is now a patchwork of practices loosely coupled by shared principles and only few rigorously defined enterprise processes. A more amenable view is that we have allowed for diversity of approach with an underlying basis of consistency in: persistent teams with product and technology, quarterly planning, scrum practices and a single instance backlog and flow tool. Three years in, the model is now championed by our Domain leads rather than by a central team.

There is a lot more work to do in integrating experience design, process ownership, non-technology change teams and traditional aspects of banking product management into the model. Still, with our Domain leads shaping a lot of this and the central team supporting interventions based on metrics and impediment resolution, we’re confident we’ve turned a corner.

3. Make things measurable and hold leaders accountable for their metrics and implementation of the model

Beyond a CEO-led strategic refresh, NAB lacked a burning platform to accelerate a transformation like this from a technology and capability perspective. We still have a lot of technology modernisation to do before approaching a true ‘BusDevOps’ way of working, so pragmatism was key.

One significant starting advantage was a very consistent approach to how we managed and tracked the technology development work happening in our squads. By being able to measure the effects of the new model from almost day one, we were able to use these metrics as a tool to both convince leaders of the benefits of these ways of working as well as urge them into action by drawing comparisons between domains.

Integrating adjacent objectives such as the effective use of our India and Vietnam based colleagues with core agile metrics such as percentage of break ins, committed versus delivered, epic delivery cycle time and squad utilisation, we were able to create a regular and holistic performance dialogue with and between our Domain leaders.

We were also able to use data to drive further change to the model, for instance when we noticed through our quarterly cross-domain prioritisation that the sheer amount of new work was strongly outpacing our delivery of value to customers. As a response to this, we worked with our leaders to tighten controls around starting new work and pacing our ‘idea factory’ by taking available capacity into account.

Yet also in the field of metrics there is much to improve still. We have only just started looking at squad and domain composition metrics and triangulating them with delivery output and quality. We also haven’t made the work before and after technology delivery as visible, considering that this work has only recently been brought into our single agile toolset.

In conclusion

There is a lot more to be said about why the new ways of working have been successful at NAB. The pragmatism, lack of fanfare and overly fancy new language as well as the strong leadership buy-in and support from the CEO and executive leadership team should be noted for instance. The transformation being incremental and not a ‘big bang’ also contributed to its success.

As far as substantial and potentially replicable good practices go though, our three learnings of focusing on impediments, using decentralised decision power to improve buy in and making things measurable go a long way.