Scaling Agile – it’s all about choices

FIVE years ago, when ING went for its Agile transformation, it chose to emulate the Spotify Model. I joined the bank soon after that, but very early on the limitations of the Spotify model for scaling it to a large organisation became apparent. Of course, Spotify is much smaller than a typical bank and has a relatively uniform, small product, where a handful of teams can manage all aspects of the product. Compare this to banking, where we sometimes have hundreds of products/variants, each with its own backends and complexities. This makes coordination between teams absolutely critical, but also a nightmare in practice.

At the time, we were also laying the foundations of our new digital banking platform. Relatively early on, we made the conscious choice that we wanted to become the Best Digital Bank in the world. Of course, no bank sets out to be a mediocre bank – but this ambition had a profound impact on how we scaled Agile at ING.

Coming back to how we hit issues with scaling the Spotify model, our immediate reaction was two to go back to Spotify, thinking they must have encountered and solved these issues. Alas, Spotify, though growing quickly, was just not large enough at the time to have encountered these issues.

So our next reaction was to look at the various scaled agile frameworks.  We looked at both Scaled Agile Framework (SAFE) and Large Scale Scrum (LESS). While both LESS and SAFE enable you to scale Agile across the organisation, one thing both frameworks have in common is that they are primarily geared towards delivering massive programs through Agile teams – where a visionary leader or a senior team knows what they want, and want it delivered in using Agile principles (sliced delivery, service design etc.). This is apparent in how they have central backlogs which are run by Product Area Lead or a Senior Manager, and the teams, while following Agile ceremonies deliver those.

In deciding which framework to adopt, the problem we were solving for became extremely important. As I mentioned, we wanted to be the best Digital Bank in the world. We just didn’t know what that might look like! Of course, everyone knows at a high level what that might look like. If you have ever been to a banking conference, you know that all the banks have mostly identical ideas and strategies. But what we knew was that in the end, it is the experience that makes the difference, rather than features – features are easy to emulate, experience isn’t. Those of you who have used both Android and iOS smartphones, you know what I am talking about. iPhone has long lagged behind Android in features (for example, iOS 14 is only introducing widgets now – something that Android has had for over 10 years) and hardware (you can buy an Android phone with more battery, more memory and more storage than iPhones, often for less money ). However, Apple just makes more thought out experiences – things just work, and the features that are present feel more polished. Of course, Android is successful in its own way too, but in a crowded banking industry, we wanted to stand out.

In my last post, I talked about how management needs to recognise that they don’t have all the answers. We were faced by the same dilemma – we knew the broad strokes, but not all the details of what it takes to create a great digital banking experience. Thus, instead of driving change top-down, we needed teams to build expertise in particular areas of banking, and use an experiment-led approach to continuously improve the experience. Consequently, we went for a squad model, which has been well documented.

Squads have a clear purpose, are specifically coached to develop mastery in that purpose, and are given the autonomy to execute that purpose. This does come at a cost, though. In SAFE and LESS, the agile teams are purely delivery entities – they hold generic skills that you need to build a journey. Thus once they have delivered a particular backlog item, say a Product Detail page, they may work on Payments functionality next – there is next to no specialisation. Consequently, if you have a fixed delivery scope, you need few teams to deliver the entire scope as the teams are all interchangeable. However, at ING, it is the squads that decide how long to keep their purpose – they keep it as long as they can keep improving the customer journey. This also means that they have significantly more attention to detail and can react quickly to what customers are saying and how they are using a feature. This attention to detail also insulates us partially against the Fintechs – you see, most Fintechs also have the same issue – few teams who need to deliver the entire cross-section of features, and thus lack of specialisation.

A consequence of this purpose-led approach is that we need more squads to deliver a given scope since squads don’t change their purpose for a program

Of course, programs are a matter of fact for ING as well – but how we deal with them is slightly different. Essentially, programs give a new dimension to the purpose, very often by increasing the scope of a feature – either by expanding the geography for whom the feature is intended, or by extending the segment, or the channel. However, the mastery remains within the squad. This means we can pivot more quickly, and link experiences across these new dimensions. If done right, this structure prevents silos. However, a consequence of this purpose-led approach is that we need more squads to deliver a certain scope since squads don’t just change their purpose when a program increment is complete, and if you are not careful, it can result in local bottlenecks. To get around some of these downsides, and to enable better collaboration between squads, we did, however, borrow several concepts from both Less and SAFE, such as scrum of scrums, ARTs etc., but we use them in very specific contexts while keeping the squad purpose as leading.

Now some of what I said would get my old MBA classmates and economist friends buzzing. What about the law of diminishing returns you ask? Basically, the law states that the return for effort reduces as you go up the curve, and beyond a certain point, the return on effort turns negative.

Yes, it is very real! The only way this model works is if squads have the discipline to measure the impact of their changes frequently, and the role of the senior management is to challenge the squads and hold them honest to the customer value they are adding. As someone once said, with great power comes great responsibility. But it is also true that most banks underestimate the compounding impact of digital customer experience. Essentially, what we noticed was that a better digital experience makes customers more engaged (logging in more frequently), and more engaged customers are also more likely to do everything else digitally – thus enabling us to save costs on call handling and servicing in branches. Suffice to say, we now have some of the most digitally engaged customers in the world at ING – and our experience keeps getting better every week.

So coming back where this post started – choosing the right problem to solve for, that is often the hardest step. It is a perfectly valid strategy to have just an okay digital banking experience. I used to work at Metro Bank, a branch centric bank in the UK, and that was indeed our strategy – keep digital costs to a minimum while delivering a good enough experience. Some other banks follow the strategy of being the first or fast follower. If that is the case, it might indeed make sense to centralise ownership of the digital experience and use SAFE or LESS to have the delivery discipline. I imagine the same would also hold true for a large scale migration project. However, if you want to be among the digital leaders, you need to let go of some control as senior management, and learn to trust the people with their ear closest to the ground. As usual, knowing what to solve for is the hardest part.

P.S. – This post is as much for my colleagues at ING, as others. Over time, with changes to top management, movement of people and other changes, we sometimes forget what we aimed to achieve and why we made certain choices. So I hope this post will act as a reminder for the times to come.