A discussion on Agile in banking: Beyond buzzwords
McKinsey: Why is the agile operating model relevant for banking?
Santiago Comella-Dorda, Partner, Boston: The main reason is that change in the industry has been accelerating. Banks need to make changes very quickly to their priorities and operating processes. The banking industry is also digitizing very quickly, and increasingly competing with pure digital players.
In addition, banks have grown tremendously complex and functionally siloed, especially given regulatory changes and the diversity of channels. Agile is a way of simplifying and creating more accountability at the front-line level.
Francesco Di Marcello, Partner, Moscow: Another point is that “agile” de-risks the digital angle of your strategy. For years, banks have been trying to “value assure” the results of large IT programs, after experiencing large and expensive failures. Now, the paradigm has shifted. Market and client behavior is changing so fast that it is very difficult to plan all of it before you get started, to detail the content of a five-year project right from the start. An agile approach allows banks to solve pain points in the client journey in a micro fashion, and to build on these changes incrementally.
Belkis Vasquez-McCall, Partner, New Jersey: I agree. Senior executives in the banking industry are taking a step back and asking, How do we serve our customers differently? What is that North Star for where we want to go, and how do we get there?[1]
And to enable that type of bold idea and change, you need to be flexible, and your organization needs to be able to reconfigure as quickly as it can. And agile allows you to engrain a new culture in your organization, to rewire your DNA, to be nimble and customer-centric.
Deepak Mahadevan, Partner, Brussels: I would add that talent is an important element as well. Banks realize they need great digital and tech talent, but historically they have not been viewed as fantastic employers for this next generation of talent. Banks need to become less hidebound by processes and policies, less bureaucratic. They should be fun places to work where talented people are empowered, can grow professionally, and are coached for better performance—and these are hallmarks of an agile organization.
McKinsey: “Agile” has become a bit of a buzzword. What do we mean by “agile,” really?
Comella-Dorda: In simple terms, agile organizations create teams that feel ownership of a particular mission or business outcome, and can deliver on that mission more or less autonomously. Teams are dynamic, their priorities change constantly, and the mission and team composition may change as well—although hopefully more slowly.
Those dynamic teams are supported by a more stable backbone, including governance and performance management, and capabilities that are empowering. In the end, an agile organization is composed of a large number of high-performing, small teams, each with a clear mission that they can deliver end to end.
Vasquez-McCall: That’s a great point. When I think about agile, it’s about changing the hearts and minds of the employees and of the leaders. It’s about shifting to a culture where everyone is welcome to give their opinions and their ideas, and can come to the table and solve problems together.
So there’s this autonomy in an agile environment, coupled with empowerment to co-own a solution from end to end. That’s partly cultural, but it is also organizational. So the question becomes, How do you organize differently as a team, so that it feels like one voice?
Agile organizations are also, of course, more nimble in how they think about the problems they need to solve, the opportunities, and how they create and apply the solutions.
Deepak Mahadevan: Agile is indeed a buzzword, and a confusing and often misunderstood one at that. Many people still think of it as a software development methodology, as it was in the early 2000s. Some people think it’s a lot of “tree huggers” who talk about culture and empowerment. Some people think it is mainly a process, and some think it’s a philosophy.
I think that to describe agile accurately, you have to include five crucial elements--strategy, structure, people, process, and technology. You really need to address all of these areas to become agile—and not just “do” agile.
McKinsey: Is there a single winning agile model? Or are there multiple winning formats?
Deepak Mahadevan: Well, there is no one truth out there. Don’t believe anybody that tells you that there is. There is no one-size-fits-all answer.
Comella-Dorda: I would also say that organizations should avoid any formulaic implementations of agile, or “copying and pasting’” generic frameworks. Too often this approach is used as a way to avoid fundamentally rethinking how your people and organization need to operate—to change the names of approaches and processes, but not actually change the approaches and processes themselves. A true agile approach requires thinking through the underlying core beliefs and objectives in your organization and designing something that makes sense in that context.
Of course, this not to say you should avoid looking for inspiration in other companies or approaches. Companies that have faced similar issues may have developed tools or frameworks that you can leverage.
Di Marcello: I think there is a spectrum of models, with two clear archetypes. In one archetype, you use agile only in one part of your operational model to get results—a “spot initiative,” like developing new digital products.
The other archetype is going full-fledged into what we call “enterprise agility.”[2] As Deepak mentioned earlier, you don’t do agile, you become agile, you are agile. So in a bank, you would think about the branches, people in operations, support functions, HR—the whole organization.
McKinsey: Does agile work everywhere in a bank? How does agile work with large-scale programs and platform build-up work? Can you do both?
Deepak Mahadevan: I think that's a relatively straightforward one. The answer is yes. Agile principles apply for software development teams, they apply for marketing teams, people in a call center, an HR function. If you think about the real meaning behind the principles, these are universally applicable.
But the practices are probably going to be very different in a team of IT professionals maintaining or developing digital services, compared to a group of people in the branches greeting customers.
Quentin Jadoul, Associate Partner, Brussels: I think questions about whether an agile approach applies typically arise in large programs, which are generally one-off things. Banks sometimes prefer not to even think about agile in these cases, because they assume it’s going to be inefficient, risky, or slow. For those large programs, it requires practical judgement to know when to apply agile.
Essentially, I think applying a sequential (or waterfall) approach makes sense under 3 conditions: firstly, you know exactly what you want to do; secondly, you know exactly how to do it, and thirdly, between the time you actually start doing it and the time of delivery, the world has not changed completely. In our experience however, these conditions are rarely met, and agile and iterative ways of working should be applied.
I think agile really adds value when you actually do something that is new, where you need to bring value fast to get customer feedback or ensure your solutions are working appropriately.
Vasquez-McCall: But I do think that even for complex, transactional systems, there are principles that you can incorporate to find efficiency and apply a more iterative way to deliver to your customers. But the practices would look different, depending on where you’re applying them.
McKinsey: So, where and how does one start an agile journey? Do these transformations follow a similar route?
Comella-Dorda: I’ve seen two ways of beginning an agile transformation. The first is to begin with your IT department and—after succeeding there, look at the wider organization to speed up decision making. Then maybe moving on to the customer-facing areas like marketing and financial product design, before moving on to the support functions.
The second way to start is a bit more aggressive. If a bank understands what their landing point is, and perhaps can take examples from other players in the industry, they can roll out agile end-to-end in one area of a business. This could be a product, a service, or a customer journey. I should be clear that it is rare to see a “big bang” approach where a whole organization is flipped on a Monday morning. In most cases it is a phased approach.
Quentin Jadoul: Yes. I think the best approach really depends on a bank’s starting position. Some organizations are further advanced on the IT journey, others less so. Some companies will start in a business line. Others start in an IT project. These are all very good starting points, as long as the bank is clear about why it is starting where it is, and what the roadmap is.
McKinsey: What are the key pitfalls to avoid and the lessons learned?
Di Marcello: There are two things for me. The first is: Don’t start if you don’t understand why you want to do it. Agile is an instrument to implement your strategy.[3]
The second thing is: Don’t copy. Take time to understand what agile really means for you and how deep and how wide you want to go with the transformation.
Deepak Mahadevan: I can think of a few more lessons. We have seen real benefits kick in only when you have been reasonably holistic in your thinking. Which is not to say that you can’t get very far by “cherry picking.” You can get to a decent place that way. But there is a significantly higher value once you’ve got a critical mass across all processes.
The other important lesson is on leadership. It does require significant alignment and conviction by the leaders who are role models.[4] For executives, going agile requires a fundamental change in how they manage a company—from managing by input to managing by output.
This means empowering your team and helping them to reach their goals. This agile way of working may mean frequent touchpoints with the teams, to understand what impact they are generating. But you don’t micro-manage or impose on them what they need to do.
It is very easy to get stuck into a boxes-and-lines organization design exercise. But that is only a fraction of what we’re talking about. And in fact, a lot of the focus needs to be on the people, on the culture, and on all the processes that you need to redesign and reinvent, as an organization.
Quentin Jadoul: on this topic, I would also emphasize the necessary shift in the role of managers[5][6]. Traditional organizations are steered top-down both on the WHAT and on the HOW, They are top-down, hierarchical, and there is limited collaborated between siloed teams. In this paradigm, middle managers are waiting for instructions from the top and feel they did a great job when they implemented what they were asked to do. On the other hand, agile organizations are steered on the WHAT and less on the HOW: teams are multi-disciplinary, less hierarchical and product owners and tribe leads need to be much more entrepreneurs, they are fully accountable to steer teams on HOW they want to achieve the results while the WHAT is defined in collaboration with the top. This is a fundamental shift for many managers and they need to re-invent how they behave. This requires a lot of attention in the transformation (change management, recruiting, incentive systems, performance management, etc.).
[5] https://www.mckinsey.com/business-functions/organization/our-insights/the-agile-manager