[[DownloadsSidebar]] [[MostPopularArticles 5]]

Agile transformations have helped many financial institutions work and innovate more quickly. However, as the Dutch bank ABN AMRO learned, there is still much room for improvement. The bank moved to build on its success in agile by both embracing an enterprise-wide adoption of DevSecOps—an approach that combines software development, security, and IT operations practices—and employing a hybrid-cloud approach (a combination of external and on-premises cloud) to further improve speed and flexibility. Karel Bosse, ABN AMRO’s program director of IT transformation, spoke to McKinsey’s Christoph Fuchs and Tom Pluym about the bank’s decision and the benefits and challenges of this broad and ongoing transformation.

McKinsey: Why did ABN AMRO embark on the journey to hybrid cloud and DevSecOps? Was there a specific challenge that needed to be resolved?

Karel Bosse: Our enterprise-wide agile transformation in 2016 significantly improved alignment between the business and IT development. While agile led to a significant acceleration of our digital innovation, we ran into new sources of friction.

As our business and IT teams became more fluent with agile, we discovered new inefficiencies. These included monolithic application architectures, insufficiently automated infrastructure platforms, and multiple handoffs between teams. As a result, we increasingly found ourselves running at different speeds along the delivery chain.

We decided to combine hybrid cloud and DevSecOps, since it was very clear to us from the beginning that to capture the full benefits of transformation, we needed to evolve both our way of working and our technology. Through the hybrid-cloud and DevSecOps transition we initiated in 2018, we’ve further accelerated innovation for our customers, improved our delivery efficiency, and created an environment to attract the best digital talent.

[[disruptor1up readnext]]

McKinsey: What does the adoption of hybrid cloud and DevSecOps look like in practice? How do you structure that process? Who needs to be involved?

Karel Bosse: We chose a domain-by-domain approach, which combines different types of interventions in a single implementation wave. During each wave, we aim to significantly increase the level of autonomy and independence of the teams.

To achieve this, teams modularize their architectures, automate significant portions of application and infrastructure logistics (such as automating testing and deployment), work together in smaller and more skilled onshore and offshore teams, and migrate applications to the private or public cloud, with a preference for platform as a service (PaaS).

The interventions are led and executed as much as possible by the teams themselves. But we provide hands-on support and coaching from engineers who have a deep expertise in architecture, automation, public cloud, security, and other key disciplines for the duration of the wave.

McKinsey: What part of this transformation has been more challenging than you anticipated?

Karel Bosse: A DevSecOps and cloud transformation is particularly hard, as it combines many disciplines and moving parts and requires a significant capability increase. So we’ve encountered a number of challenges we’ve had to address along the journey.

First off, the effort required to bring a public-cloud platform up to the production grade required for a financial institution was more significant than we expected. So we set up a dedicated cloud product team comprising cloud engineers from ABN AMRO and the cloud service provider. This team is tasked with defining all required standards and templates. We also enabled the DevSecOps teams to propose cloud templates, which are matured and managed by the cloud product team.

Secondly, the magnitude of the mindset change and reskilling challenge was substantial among our own people and our outsourcing partners. So we introduced new IT engineering career pathways that encourage people to increasingly grow and combine software development and operations skills. The career redesign also recognizes deep skills, which we call “spikes,” such as cloud engineering and test automation. This way, team members begin their mindset change and skill-building curriculum before their team enters the transformation process.

The maturity of our teams is very diverse in terms of specific capabilities. We addressed this by designing a tailored transformation journey for each of the teams, based on a maturity assessment across eight capabilities, such as continuous integration and delivery (CI/CD), automation, and security.

Once we determined a team’s starting point, we shaped a personalized journey in terms of ambition level and the duration of that journey. We learned that creating transparency about the teams’ maturity levels across the eight capability levels motivates the teams to start preparing—and improving—even before the transformation wave kicks off.

Also, our teams are already very busy with delivery work, and the transformation just adds to their workload. To ensure we don’t exert too much pressure on them, we take pains to align realistic expectations on business delivery up front. This means a team can reduce business delivery to a minimum for a few weeks or months, or we lengthen the transformation journey for that individual team to accommodate everyone’s needs. It sounds easy, but it often leads to difficult but necessary trade-off decisions.

We’ve also learned how highly intertwined disciplines and practices are. For example, some operating-model changes could be done effectively only if we also changed architecture, which in turn required a change in the way we deal with security. This is why supporting the transformation requires a truly multidisciplinary team approach.

[[ceros cloud]]

McKinsey: How did you get the employees on board and engage them?

Karel Bosse: We knew a deep cultural change was needed. Giving teams autonomy and independence requires a shift from control through documentation and process to trusting automation, among other changes. This shift requires time and education.

Initially, we focused on the skills and mindsets in the DevSecOps teams. We introduced a framework that clearly defines which skill mastery is required for a team to earn a level of trust and independence to carry out certain specified tasks, such as production deployments.

But as an increasing number of teams acquired greater independence, we noticed that the broader organization had a tendency to reintroduce new ways to control the teams, curbing their independence and reintroducing friction.

We learned that putting a risk-control framework in place simply isn’t enough, so we increased our efforts to engage with the broader organization to create awareness and build trust.

McKinsey: What level of impact have you achieved so far?

Karel Bosse: Some benefits are easier to measure than others. We already see a very clear impact from automation. For example, some of our teams used to spend two days per sprint on regression testing. Now that it’s fully automated, we’ve reduced the running time to just two hours.

Another example is the reduction in infrastructure costs thanks to the introduction of infrastructure as code. Software-output productivity is harder to measure, as we often lack sufficient baseline data.

When running a DevSecOps and cloud transformation, it’s also extremely important, in order to resist the constant temptation to redirect investments to other urgent business priorities, to keep proving the benefits to the entire organization.

We do this by creating transparency on a set of key team-level metrics such as mean time to detect, mean time to restore, release frequency, change failure rate, and availability. Overall, we’ve seen teams that are 20 to 30 percent smaller delivering the same output as before.

McKinsey: What advice would you give to anyone considering or already running a DevSecOps and cloud transformation?

Karel Bosse: Be clear about your goals. Are you optimizing for cost, speed, or productivity? Closely involve the business and make sure there’s a good understanding of the benefits as well as the needed investments, which often come in the form of team capacity and compete with change delivery.

You also need to create a high level of commitment from your organization’s top management. Enterprise-wide IT transformation is tough and requires many years of follow-through. Overinvest in building the capabilities of the teams and throughout the wider organization. And lastly, plan well, but don’t plan too long. The real learning happens when you actually begin the implementation.