How we doubled our delivery using agile on a core banking replacement.

I am privileged to have a leading role in one of the largest transformations in European banking. Nordea is the consolidation of 300 Nordic banks and underpinning their simplification is a single new core banking platform. When I was given the opportunity in May last year to help reshape the delivery methods for this core banking program, I was keen to leverage the same agile principles I’d seen work in previous roles.

A lot of people told me, “You can’t use agile on a core banking replacement,” but that’s exactly what we are doing and within less than a year of making the following changes our throughput (# stories) had increased 50% and we reduced cost by 30%, effectively doubling our delivery efficiency (throughput/cost).

We also got our work in progress under control, established a predictable major release cycle and found ourselves with a much happier team.

But changing the delivery model of an agile core banking replacement with several hundred people is not an ordinary undertaking. We used the Scaled Agile Framework (SAFe) as exactly that, a framework. We were also pragmatic and willing to adapt based what we saw working in the teams in our unique situation. These are some of the things that worked.

We re-organised to remove dependencies

Core banking replacements are inherently complex, and I’d say that ours is more complex than most. We had cases where a single feature could require as many as ten hand-offs between teams.

We addressed this as best as we were able through creation of feature teams, federating integration teams and bringing some external teams inside the tent. We also removed product silos so that our new organisation could work from a single backlog.

We restructured our backlog and lengthened our planning horizon

Even after the re-organisation we still manage 150-200 external dependencies within each major release, some with long lead times. We had to extend our planning horizon. Two things helped us achieve that:

• We introduced SAFe capabilities and features. This provided the framework for defining requirements on different planning horizons at an appropriate level of detail.
• We created a new ‘look ahead’ team.

I don’t typically like dedicated ‘look ahead’ teams. They introduce hand-offs and potential issues of ownership and accountability, but it was one of those cases of needing to be pragmatic. This team provided a means to break out of our previous planning cycle without distracting from near-term commitments.

A year later we have a dramatically more defined roadmap and architectural runway and continuous exploration or ‘look ahead’ work is being brought into the agile release trains where it belongs.

We directed our focus towards architectural enablers, eliminating dependencies and reducing risk

We took stock of our roadmap and more often made decisions to focus on strategic integrations rather than tactically enabling product offerings. Our release train engineers and our architects became more influential in setting priorities and more ‘hands on’ in delivery management.

We got our work in progress (WIP) under control

This was the most critical shift, and three changes made it possible.

• In our new organisation there were no longer savings teams and lending teams. Instead we were a single solution train managing delivery from a single backlog.
• Our new backlog structure made it easier to communicate and manage scope. We started prioritising at a capability level and defining minimum viable product at a feature level.
• We accepted that over-commitment was causing us to finish less and so we resisted pushing top down ambition into the plan.

In combination, these had an immediate impact on WIP which in turn halved our cycle times and allowed us to get delivery under control.

We also chose to plan to full capacity in order to retain options

Having said that we avoid over-committing, when you’re dealing with external dependencies that have long lead-times it’s also costly to under-commit. So, we acknowledge when capabilities are near the edge of our capacity, but we plan them in and manage the external dependencies accordingly. Otherwise we risk finding capacity later but not delivering value because the necessary dependencies are not in place.

We didn’t make the changes by consensus

The changes we made were not agreeable to everyone, but we also knew that this sort of change could not be achieved through consensus. We had strong sponsorship, communicated a lot, did lots of training and took on feedback. Still many people were not convinced until they saw it working. Today those people are helping us make it better.

In conclusion…

Don’t be one of those people who say, “You can’t…”. So often we can. Even on a large core banking replacement we benefited from embracing agile principles, but we needed to be pragmatic in our adoption and focus on what worked for us at the time.

Finally, many people contributed to making this change a success, among them are Rolf H?s?nen and Joseph Edwin who both also contributed to this article, and despite best efforts it’s not possible to describe all the nuances of a change like this in few enough words that you might read it on your mobile. If you’ve done that then, “Thanks and sorry for under-estimating you!”. I’d be happy to discuss more, so tell me…

What works for you?