[[DownloadsSidebar]]

Several years ago, Standard Bank, one of South Africa’s largest and oldest financial-services groups, found itself facing significant challenges from digital competitors. These banks were operating at a much lower cost while still offering customers innovative products and engaging experiences. “We felt like we were investing in all the right technologies, but we didn’t have the right processes in place to get the most from those technologies,” recalls Mike Murphy, chief technology officer and head of Group Technology Build for Standard Bank.

As a result, the 154-year-old bank embarked on a multiyear digital transformation. The centerpiece of this plan was a shift to agile software development, an approach that emphasizes quick product iteration, test-and learn approaches, and frequent collaboration among teams. In this interview with McKinsey’s Sven Blumberg and Christian Stüer, Murphy talks about financial institutions’ increasing need for and reliance on digital channels, as well as the new technologies and strategies Standard Bank has deployed to position itself for long-term business development and revenue growth.

[[Sidebar Mike Murphy biography]]

McKinsey: Most global banks are pursuing some form of digital or mobile strategy—why is it so critical?

Mike Murphy: We’re seeing a new, younger generation of consumers who are technologically savvy and highly adapted to the online world. This is particularly true in emerging markets, where 90 percent of the population is under age 30. In Africa, for instance, nearly half the population is under 19, and most young adults have mobile phones. It used to be that banks were always chasing “credible” digital-banking solutions. Now those solutions are here. We’re already seeing banks differentiate themselves through digital innovation. They are offering customers single-click access to loan applications and account information. They are tailoring their products to individual customers’ needs. In particular, mobile adoption of these kinds of services will be breathtakingly fast, and no one wants to be left behind.

McKinsey: What role can the IT organization play in facilitating digital and mobile innovation?

Mike Murphy: Most banks just can’t match the customer experiences provided by pure-play Internet companies—but it’s not for lack of trying. It’s more about arriving late to the game. IT has a huge role to play in helping companies get up to speed, but only if it can move beyond serving as the executor of business specifications. Look at the IT function in pure-play Internet companies. You see that IT is more of a partner with the business and with the user community, codeveloping software applications with these stakeholders. You see more automation across software development and delivery in those companies. And you see empowered IT developers who can respond quickly to changing customer needs and desires, instead of requiring consensus every time there is a feature-deployment decision. Overall, you see more of an agile approach to software development.

McKinsey: How did Standard Bank decide to switch to agile software development?

Mike Murphy: Our ADM [application development and maintenance] group had been using traditional approaches to software development, including waterfall. But these weren’t fast enough. We saw what was happening in Silicon Valley and elsewhere, and we talked with executives in other banks and in other industries, and we wanted to capture the same performance and cost advantages those companies were. So we examined how digital-native companies were doing agile software development. We weighed the trade-offs between adapting some of those companies’ best practices and the specific requirements in our organization. Our initial focus was on applying agile approaches to mobile applications and Internet-banking software, two areas that the business side was particularly excited about. Now we’re using agile across a broad section of the ADM organization, covering 15 product-management teams and comprising a total of 150 full-time employees. By the end of 2016, we’re aiming to have the remainder of the ADM organization using agile development.

McKinsey: How have your software-development processes changed?

Mike Murphy: Overall, there is much more emphasis on collaboration and co-location. Every product-management team has a product owner, developers, and testers, and they all sit together. Any number of individual product teams might work together depending on product requirements—so if a new application needs to be made compatible with an existing one, team members may come together to create a plan for synchronizing the two. We emphasize with business leaders and with IT leaders this idea of codevelopment and joint problem solving. That way, we can accurately capture the business requirements for the software application or service feature and build in accountability from all parties involved. We schedule lots of discussions about prototypes so both sides can refine their ideas—constantly clarifying the requirements while testing the software. We invite customers into the process, often before a single line of code has been written. And we build informal relationships with customers through online forums and social-media interactions rather than formal focus groups. If a customer proposes a new feature, we will share early mock-ups with the person to get input. Our testers are fully involved at all stages of product development, not just at the end, so they have a much better understanding of what the software is trying to do. They’re not only flagging errors but also finding new solutions to problems. And we now use automated testing to speed up what used to be a very labor-intensive process.

McKinsey: How did you gain buy-in for this approach?

Mike Murphy: This was one of the toughest challenges. A lot of staffers at the bank were comfortable with the ways things were. They didn’t want to change their daily routines. They were focused on simply getting the job done. We broke people out of those comfort zones by making agile a top priority for the whole ADM unit. We convened town halls for product-management teams, explaining the logic behind the change and setting explicit targets for improvement. We reinforced these messages with formal mechanisms—for instance, by co-locating work-team members, so they would collaborate more. We gave teams autonomy to make decisions on how to go about their day-to-day functions, but we did ask that they schedule regular team meetings to provide everyone with status updates, set a maximum length of time for sprint activities, and hold retrospectives regularly to discuss what teams might want to do differently during the next product sprint. People have responded favorably to this sort of loose-tight structure.

McKinsey: How have your talent-management practices changed?

Mike Murphy: Cost pressures definitely put a limit on the type and number of new hires we could bring on board. So we’ve focused on training existing employees in agile techniques and principles. We rely on the “train the trainer” concept—colleagues who attend trainings and workshops, or who visit with Silicon Valley companies, are expected to formally pass their knowledge and observations to their own teams. Each team member goes through multiday training on agile software development; we also have a dedicated group of agile coaches who are always reaching out to product groups. They might sit in on retrospectives and suggest ways the team could improve its practices. Most important, we have instituted a number of “interest groups” or guilds within the application-development unit. These groups meet every two weeks or so to encourage knowledge exchange—there is an iOS guild, a cloud guild, and so on. This is a terrific way to ensure cross-team and cross-functional communication.

[[Disruptor1UP dis1]]

McKinsey: What does all of this change look like on the ground?

Mike Murphy: The way that business groups interact with IT has changed significantly. I’ll give you an example: a tablet application we developed before we moved to agile took 2,500 pages of documentation to explain. Many of those pages contained duplicate information about requirements and, after all that, still left the developers struggling to understand what the outcome should be. Now when we develop tablet applications, we rely on a few refined use cases that were cocreated by the IT group, the business, user-interface experts, and end customers. The business feels more in control, and the IT group is no longer operating in the dark. In fact, the IT group feels more empowered under this model. The team can release new online features every month, and because it is incorporating customer feedback into products early on, the amount of rework required has dropped significantly. Before agile, our developers might log thousands of defects relating to a new app and post a 38 percent testing-failure rate. After agile, those numbers are more like 100 defects and a 3 percent failure rate. The overall development process has become much more efficient. And there is more trust among colleagues and functions. In the past, some basic tests would be run twice, once by developers and once by testers who did not trust the developers’ results. Today, testers immediately accept developers’ results and can move on to more complex tests.

McKinsey: What challenges have you faced in making all these changes, and how have you addressed them?

Mike Murphy: I can’t overstate the importance of breaking down silos and breaking people out of their comfort zones, particularly when you’re talking about established companies in established industries such as banking. It’s one thing to state a desire to adopt agile development; it’s another thing completely to get buy-in from the business units. We learned this early on. We had to put a halt to one of our first pilot projects, because the leaders in affected business units were uncomfortable with the amount of time and resources that were being taken away from day-to-day IT operations and support. In theory, the business leaders understood the potential benefits of agile. But when we took initial steps in that direction, they realized just what was involved and how reluctant they were to compromise stability for the sake of innovation.

We knew they would need to see positive proof, quickly. To get everyone on the same page, we created new communication channels—a newsletter, a web page, and regular town-hall meetings—for presenting our successes and challenges in agile product development and delivery. These forums have helped build team motivation and sustain the momentum for change. We now have a number of “agile evangelists” among business-unit leaders. Likewise, our participation in industry events has helped our team members understand where we are with our digital journey compared with our peers—in many cases, we are quite far ahead, and that piece of knowledge can be very motivating.

McKinsey: What can other companies take away from your experience?

Mike Murphy: Our first pilots have demonstrated tangible benefits—productivity increases of up to 50 percent and unit-cost reductions of up to 70 percent per function point. But, you know, we’re still early in this transformation. We face a number of challenges—how to scale agile to teams outside ADM, for instance, and how to ensure that our IT architecture, infrastructure, and operating model evolve as the digital opportunities do. This requires a huge change in mind-set and organizational planning—for instance, figuring out how to break up teams of 80-plus people into smaller groups focused on specific application features or customer experiences and determining who the dedicated product owners from the business should be. We’re learning to reconcile the trade-offs between respecting individual teams’ autonomy and accepting varying quality levels across product teams, given the different ways they choose to work. We also have the long-running challenge of any change effort—how do we make it stick?

The most important thing for us, or for any company moving to agile, is to remember that this isn’t just about reducing costs. It’s about streamlining the way we work and delivering the best services to our customers through whatever channel they choose to interact with us