Agile development has largely become synonymous with digitization: senior business leaders have realized that their companies cannot take full advantage of digital tools and technologies without having new, amped-up processes for managing them. The value of these processes is immense.
Senior executives need only look at two recent examples in the banking industry to understand what’s at stake: ING and South Africa’s Standard Bank have both incorporated digital technologies and agile ways of working into their operations, and both are achieving positive results. ING is releasing software features to its web and mobile sites every two or three weeks rather than five or six times a year. As a result, the company’s customer-satisfaction scores are up by multiple points. Standard Bank has improved the quality of its new mobile applications by finding and fixing potential bugs earlier in the software-development process—building more trust with employees and customers in the process.
What may be less clear to senior executives is the role they can play in jolting their own business units and IT organizations to break from the status quo and realize similar advantages. “This was one of the toughest challenges,” says Mike Murphy, CTO at Standard Bank. “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.”
Stay current on your favorite topics
Senior executives often tend to assume that after they set overarching digital goals, it’s up to IT to deliver on them quickly through a range of initiatives. In their view, agility is something for R&D engineers and software developers only. The business units hold fast to tried-and-true methods for communicating with IT—throwing their requirements “over the wall” and waiting for IT to build and deliver finished products. The IT organization ends up operating with limited information from the business, the business units lose their opportunity to steer technology development toward desired goals, and agility stalls.
Agile development cannot be a priority solely for the technology organization. Senior business executives must include it on their agendas as well, thereby signaling the importance of making the required technology and cultural changes. The top team’s attention will make it clear that software development is a joint process. It entails frequent interactions between business and IT groups, and it requires widespread acceptance of a test-and-learn approach.
Senior executives need to actively promote agile concepts across business and technology teams and to link those concepts directly to business-related outcomes. Because of the unique perspective the CIO and other technology leaders have—with one foot in the C-suite and another among the technology stacks—they can help senior executives establish six work habits that promote joint ownership of the software-development process, daily collaboration among business and IT stakeholders, and a culture of continuous learning.
Would you like to learn more about our Digital McKinsey Practice?
Creating agile habits
In discussions in the boardroom, on the shop floor, and everywhere else, senior business and technology leaders should emphasize the following six habits, which are critical for companies to realize the promise of agile.
1. Put some skin in the game. In an agile environment, some business-unit leaders will be tapped as product owners—that is, the business-unit stakeholders most accountable for shaping the products. These leaders must make the development and success of a product their highest priority—and they must be given the leeway to do so. That might mean shifting schedules and commitments so product owners can attend key agile meetings: scrums, sprint reviews, and sprint planning sessions (see the sidebar “Speaking agile”). Additionally, senior management may need to redeploy resources so that business units can assign product owners to individual agile-development initiatives.
Product owners not only set the aspirations and vision for the product but also colead decision making about features and development goals with colleagues in IT. They should be able to live in two worlds. They must have some understanding of technology and the ways it is transforming their industries. They must also have a strong sense of market needs and the product features that would be most valuable to end users. (Typically, that’s not an issue for most product owners who come from the business, because they interact more frequently with end users than IT managers do.) Product owners can pair this market knowledge with the engineers’ feedback on the technical feasibility of specific product features to create a clear development plan.
2. Shape the product together. Under traditional approaches to product development, IT leaders interview business-unit leaders once to collect business requirements—for instance, what novel features are required in the new software or applications being created, and on which platforms will the new applications need to run? IT managers capture these requirements in jargon-filled documents, and the next time they reach out to the business unit, it’s with a mostly completed prototype in tow.
By contrast, agile product development is less about taking orders and more about sharing information. The business and the IT organization must codevelop products every day, side by side, in an ongoing process. Senior business leaders can establish this level of collaboration by investing in tools to improve interactions—for example, visual aids instead of lists of requirements.
At one company, a product owner from a business unit and a technology leader used sketches to trade feedback on software under development. IT professionals sketched a prototype that the product owner could page through. The product owner could circle what he liked or draw alternative versions of the elements he didn’t. The team refined the design together in a way that everyone could understand and contribute to.
3. Cheer for your own team. Leaders in the C-suite and the heads of business units have a critical role to play as evangelists for the software products they codevelop: they must hold product owners from the business units accountable for the successful rollout of any new release and its effect on the business. They should encourage product owners and IT engineers to educate their business colleagues about the benefits of new software and reasons to adopt it. Agile teams can share introductory videos at the launch of a product, demonstrate it at town-hall meetings for employees, and listen to their colleagues’ frustrations with and ideas about it. All the while, they should explain that this input is valued—and demonstrate that it is by incorporating feedback into product revisions. Such transparency, encouraged and modeled from the top down, can produce a culture in which joint efforts at problem solving, rather than complaints about IT, are the norm.
4. Think like a user. Sometimes, senior business leaders may very well be the users of the product they are shaping—if it’s an executive dashboard, for instance. But usually they are not. To help build software and products that transform the way a company operates or appeal to customers, product owners from the business must be unwaveringly committed to users’ needs. Senior executives can encourage this kind of outlook by asking targeted questions during product reviews. Who are the users? How are they using the product? Do they primarily work in an office or remotely? What are their biggest frustrations? Software-development teams should also think through these questions as they design tools and experiences to ensure that they are addressing the idiosyncrasies of end users.
5. Learn to live with ‘good enough.’ Senior executives are typically a risk-averse group. Traditional product-development models emphasize multiple check-ins at various stages of development—a time-intensive but comprehensive way to ensure that products include all the desired features and don’t contain bugs and other flaws. By contrast, agile development emphasizes a test-and-learn approach—for instance, releasing a minimally viable product that delivers value to end users in the short term but is expected to change on the fly.
In this case, chief information officers may need to help senior business executives come to terms with the release of a good-enough product by redefining their expectations and thresholds for risk. A CIO could, for example, highlight agile success stories—instances where a company released a good-enough product, shifted strategy midstream in response to feedback, and ultimately delivered a winning solution. In addition, the CIO can be open about accepting minimally viable releases refined by IT line managers—prompting similar behavior across the company. And at least initially, technology leaders could press for time-to-market schedules that give the business units no option but to pursue good-enough products.
The CIO should also help senior business leaders understand that even under a good-enough approach, agile teams will not deliver everything immediately. The process is actually more rigorous than most executives can see. Agile teams must work exhaustively to collect feedback to determine what’s working, what’s not, and how to make incremental improvements that will enhance the product or the customer’s experiences with it. And they must repeat this process over and over again.
6. Broaden the mandate. As scrum teams ramp up their performance and experience, they will inevitably bump up against slower teams and processes elsewhere in the organization. These slower teams, such as high-volume sales organizations, use more traditional, rigid work processes. To maximize the impact of agile methods, senior leadership must consider ways to transfer lessons from agile teams to different areas of the company. Working with the CIO and other technology professionals, senior business executives can identify the processes and products that are most critical for delivering business value to customers and consider which agile principles would help to speed things up (see the sidebar “Making the case for agile”).
An operating model for company-wide agile development
Closing the gap
Agile requires a commitment of time and attention, which can be jarring to business leaders already juggling many priorities. But with some guidance from CIOs and other technology professionals in the IT organization, senior business executives may gain a more digestible view of the shift from traditional to agile development processes. Senior business leaders will better understand the technical terms associated with agile, and can help identify the technologies and skill sets required to operate successfully under an agile model. Perhaps even more important, business executives can turn anecdotal evidence into hard metrics reflecting the ways agile work flows create positive business outcomes—for instance, a more engaging customer experience, streamlined internal processes, and a thriving, collaborative corporate culture.
There should be no order givers or takers, no “us versus them” dynamic between the business units and the IT organization. There should be just one team, building innovative software that transforms the work of those who use it and enables ever-closer connections to customers and business partners.
