Project management agile

HOW TO GO FROM A FEW TEAMS TO HUNDREDS BY DARRELL K. RIGBY,

JEFF SUTHERLAND, AND ANDY NOBLE

AGILE AT SCALE

FEATURE AGILE AT SCALE

88  HARVARD BUSINESS REVIEW MAY–JUNE 2018

M A

N U

EL A

S C

H EW

E- BE

H N

IS C

H /E

YE EM

/G ET

TY IM

A G

ES

AGILE AT SCALE

the financial results sought by activist investors and the board of directors, and several senior executives recently resigned.

Our studies show that companies can scale up agile effectively and that doing so creates substantial bene- fits. But leaders must be realistic. Not every function needs to be organized into agile teams; indeed, agile methods aren’t well suited to some activities. Once you begin launching dozens or hundreds of agile teams, however, you can’t just leave the other parts of the business alone. If your newly agile units are constantly frustrated by bureaucratic procedures or a lack of col- laboration between operations and innovation teams, sparks will fly from the organizational friction, leading to meltdowns and poor results. Changes are necessary to ensure that the functions that don’t operate as agile teams support the ones that do.

LEADING AGILE BY BEING AGILE For anyone who isn’t familiar with agile, here’s a short review. Agile teams are best suited to innovation—that is, the profitable application of creativity to improve products and services, processes, or business mod- els. They are small and multidisciplinary. Confronted with a large, complex problem, they break it into mod- ules, develop solutions to each component through rapid prototyping and tight feedback loops, and inte- grate the solutions into a coherent whole. They place more value on adapting to change than on sticking to a plan, and they hold themselves accountable for

BY NOW MOST BUSINESS LEADERS ARE FAMILIAR WITH AGILE INNOVATION TEAMS. THESE SMALL, ENTREPRENEURIAL GROUPS ARE DESIGNED TO STAY CLOSE TO CUSTOMERS AND ADAPT QUICKLY TO CHANGING CONDITIONS. WHEN IMPLEMENTED CORRECTLY, THEY ALMOST ALWAYS RESULT IN HIGHER TEAM PRODUCTIVITY AND MORALE, FASTER TIME TO MARKET, BETTER QUALITY, AND LOWER RISK THAN TRADITIONAL APPROACHES CAN ACHIEVE.

Naturally, leaders who have experienced or heard about agile teams are asking some compelling ques- tions. What if a company were to launch dozens, hun- dreds, or even thousands of agile teams throughout the organization? Could whole segments of the busi- ness learn to operate in this manner? Would scaling up agile improve corporate performance as much as agile methods improve individual team performance?

In today’s tumultuous markets, where established companies are furiously battling assaults from start- ups and other insurgent competitors, the prospect of a fast-moving, adaptive organization is highly ap- pealing. But as enticing as such a vision is, turning it into a reality can be challenging. Companies often struggle to know which functions should be reorga- nized into multidisciplinary agile teams and which should not. And it’s not unusual to launch hundreds of new agile teams only to see them bottlenecked by slow-moving bureaucracies.

We have studied the scaling up of agile at hundreds of companies, including small firms that run the en- tire enterprise with agile methods; larger companies that, like Spotify and Netflix, were born agile and have become more so as they’ve grown; and companies that, like Amazon and USAA (the financial services company for the military community), are making the transition from traditional hierarchies to more-agile enterprises. Along with the many success stories are some disappointments. For example, one prominent industrial company’s attempts over the past five years to innovate like a lean start-up have not yet generated

90  HARVARD BUSINESS REVIEW MAY–JUNE 2018

FEATURE AGILE AT SCALE

2015 members of the board of management, led by CEO Volkmar Denner, decided to build a more unified approach to agile teams. The board acted as a steering committee and named Felix Hieronymi, a software engineer turned agile expert, to guide the effort.

At first Hieronymi expected to manage the assign- ment the same way Bosch managed most projects: with a goal, a target completion date, and regular sta- tus reports to the board. But that approach felt incon- sistent with agile principles, and the company’s divi- sions were just too skeptical of yet another centrally organized program. So the team shifted gears. “The steering committee turned into a working committee,” Hieronymi told us. “The discussions got far more inter- active.” The team compiled and rank-ordered a backlog of corporate priorities that was regularly updated, and it focused on steadily removing companywide barri- ers to greater agility. Members fanned out to engage division leaders in dialogue. “Strategy evolved from an annual project to a continuous process,” Hieronymi says. “The members of the management board divided themselves into small agile teams and tested various approaches—some with a ‘product owner’ and an ‘agile master’—to tackle tough problems or work on fun- damental topics. One group, for instance, drafted the 10 new leadership principles released in 2016. They personally experienced the satisfaction of increasing speed and effectiveness. You can’t gain this experience by reading a book.” Today Bosch operates with a mix of agile teams and traditionally structured units. But it reports that nearly all areas have adopted agile values, are collaborating more effectively, and are adapting more quickly to increasingly dynamic marketplaces.

GETTING AGILE ROLLING At Bosch and other advanced agile enterprises, the vi- sions are ambitious. In keeping with agile principles, however, the leadership team doesn’t plan every de- tail in advance. Leaders recognize that they do not yet know how many agile teams they will require, how quickly they should add them, and how they can ad- dress bureaucratic constraints without throwing the organization into chaos. So they typically launch an initial wave of agile teams, gather data on the value those teams create and the constraints they face, and then decide whether, when, and how to take the next step. This lets them weigh the value of increasing agil- ity (in terms of financial results, customer outcomes, and employee performance) against its costs (in terms of both financial investments and organizational challenges). If the benefits outweigh the costs, leaders continue to scale up agile—deploying another wave of teams, unblocking constraints in less agile parts of the organization, and repeating the cycle. If not, they can pause, monitor the market environment, and explore ways to increase the value of the agile teams already in place (for instance, by improving the prioritization

IN BRIEF

THE AMBITION To go from a handful of agile innovation teams in a function like software development to scores, even hundreds, throughout your company—to make agile the dominant way you operate

THE CHALLENGES Figuring out where to start and how fast and far to go, deciding which functions can and should be converted to agile teams and which should not, and preventing slow- moving bureaucracies from impeding those that do convert

THE SOLUTION Leaders should use agile methods themselves and create a taxonomy of opportunities to set priorities and break the journey into small steps. Workstreams should be modularized and then seamlessly integrated. Functions not reorganized into agile teams should learn to operate with agile values. The annual budgeting process should be complemented with a VC-like approach to funding.

outcomes (such as growth, profitability, and customer loyalty), not outputs (such as lines of code or number of new products).

Conditions are ripe for agile teams in any situation where problems are complex, solutions are at first un- clear, project requirements are likely to change, close collaboration with end users is feasible, and creative teams will outperform command-and-control groups. Routine operations such as plant maintenance, pur- chasing, and accounting are less fertile ground. Agile methods caught on first in IT departments and are now widely used in software development. Over time they have spread into functions such as product de- velopment, marketing, and even HR. (See “Embracing Agile,” HBR, May 2016, and “HR Goes Agile,” HBR, March–April 2018.)

Agile teams work differently from chain-of-com- mand bureaucracies. They are largely self-governing: Senior leaders tell team members where to innovate but not how. And the teams work closely with cus- tomers, both external and internal. Ideally, this puts responsibility for innovation in the hands of those who are closest to customers. It reduces layers of con- trol and approval, thereby speeding up work and in- creasing the teams’ motivation. It also frees up senior leaders to do what only they can do: create and com- municate long-term visions, set and sequence strate- gic priorities, and build the organizational capabilities to achieve those goals.

When leaders haven’t themselves understood and adopted agile approaches, they may try to scale up agile the way they have attacked other change ini- tiatives: through top-down plans and directives. The track record is better when they behave like an agile team. That means viewing various parts of the organi- zation as their customers—people and groups whose needs differ, are probably misunderstood, and will evolve as agile takes hold. The executive team sets priorities and sequences opportunities to improve those customers’ experiences and increase their suc- cess. Leaders plunge in to solve problems and remove constraints rather than delegate that work to subordi- nates. The agile leadership team, like any other agile team, has an “initiative owner” who is responsible for overall results and a facilitator who coaches team members and helps keep everyone actively engaged.

Bosch, a leading global supplier of technology and services with more than 400,000 associates and op- erations in 60-plus countries, took this approach. As leaders began to see that traditional top-down man- agement was no longer effective in a fast-moving, glo- balized world, the company became an early adopter of agile methods. But different business areas required different approaches, and Bosch’s first attempt to im- plement what it called a “dual organization”—one in which hot new businesses were run with agile teams while traditional functions were left out of the action— compromised the goal of a holistic transformation. In

MAY–JUNE 2018 HARVARD BUSINESS REVIEW 91 

of work or upgrading prototyping capabilities) and decrease the costs of change (by publicizing agile successes or hiring experienced agile enthusiasts).

To get started on this test-and-learn cycle, lead- ership teams typically employ two essential tools: a taxonomy of potential teams and a sequencing plan reflecting the company’s key priorities. Let’s first look at how each can be employed and then explore what more is needed to tackle large-scale, long-term agile initiatives.

Create a taxonomy of teams. Just as agile teams compile a backlog of work to be accomplished in the future, companies that successfully scale up agile usually begin by creating a full taxonomy of opportu- nities. Following agile’s modular approach, they may break the taxonomy into three components—cus- tomer experience teams, business process teams, and technology systems teams—and then integrate them. The first component identifies all the experiences that could significantly affect external and internal cus- tomer decisions, behaviors, and satisfaction. These can usually be divided into a dozen or so major expe- riences (for example, one of a retail customer’s major experiences is to buy and pay for a product), which in turn can be divided into dozens of more-specific experiences (the customer may need to choose a pay- ment method, use a coupon, redeem loyalty points, complete the checkout process, and get a receipt). The second component examines the relationships among these experiences and key business processes (improved checkout to reduce time in lines, for in- stance), aiming to reduce overlapping responsibilities and increase collaboration between process teams and customer experience teams. The third focuses on developing technology systems (such as better mobile- checkout apps) to improve the processes that will support customer experience teams.

The taxonomy of a $10 billion business might iden- tify anywhere from 350 to 1,000 or more potential teams. Those numbers sound daunting, and senior executives are often loath even to consider so much change (“How about if we try two or three of these things and see how it goes?”). But the value of a tax- onomy is that it encourages exploration of a transfor- mational vision while breaking the journey into small steps that can be paused, turned, or halted at any time. It also helps leaders spot constraints. Once you’ve identified the teams you could launch and the sorts of people you would need to staff them, for instance, you need to ask: Do we have those people? If so, where are they? A taxonomy reveals your talent gaps and the kinds of people you must hire or retrain to fill them. Leaders can also see how each potential team fits into the goal of delivering better customer experiences.

USAA has more than 500 agile teams up and run- ning and plans to add 100 more in 2018. The taxon- omy is fully visible to everyone across the enterprise. “If you don’t have a really good taxonomy, you get

redundancy and duplication,” COO Carl Liebert told us. “I want to walk into an auditorium and ask, ‘Who owns the member’s change-of-address experience?’ And I want a clear and confident response from a team that owns that experience, whether a member is call- ing us, logging into our website on a laptop, or using our mobile app. No finger-pointing. No answers that begin with ‘It’s complicated.’”

USAA’s taxonomy ties the activities of agile teams to the people responsible for business units and prod- uct lines. The goal is to ensure that managers respon- sible for specific parts of the P&L understand how cross-functional teams will influence their results. The company has senior leaders who act as general managers in each line of business and are fully ac- countable for business results. But those leaders rely on customer-focused, cross-organizational teams to get much of the work done. The company also de- pends on technology and digital resources assigned to the experience owners; the goal here is to ensure that business leaders have the end-to-end resources to deliver the outcomes they have committed to. The intent of the taxonomy is to clarify how to engage the right people in the right work without creating con- fusion. This kind of link is especially important when hierarchical organizational structures do not align with customer behaviors. For example, many compa- nies have separate structures and P&Ls for online and off ine operations—but customers want seamlessly in- tegrated omnichannel experiences. A clear taxonomy that launches the right cross-organizational teams makes such alignment possible.

Sequence the transition. Taxonomy in hand, the leadership team sets priorities and sequences initiatives. Leaders must consider multiple criteria, including strategic importance, budget limitations, availability of people, return on investment, cost of delays, risk levels, and interdependencies among teams. The most important—and the most frequently overlooked—are the pain points felt by customers and employees on the one hand and the organization’s ca- pabilities and constraints on the other. These deter- mine the right balance between how fast the rollout should proceed and how many teams the organization can handle simultaneously.

A few companies, facing urgent strategic threats and in need of radical change, have pursued big-bang, everything-at-once deployments in some units. For example, in 2015 ING Netherlands anticipated rising customer demand for digital solutions and increasing incursions by new digital competitors (“fintechs”). The management team decided to move aggressively. It dissolved the organizational structures of its most innovative functions, including IT development, prod- uct management, channel management, and mar- keting—essentially abolishing everyone’s job. Then it created small agile “squads” and required nearly 3,500 employees to reapply for 2,500 redesigned positions on

92  HARVARD BUSINESS REVIEW MAY–JUNE 2018

FEATURE AGILE AT SCALE

those squads. About 40% of the people filling the positions had to learn new jobs, and all had to profoundly change their mindset. (See “One Bank’s Agile Team Experiment,” HBR, March–April 2018.)

But big-bang transitions are hard. They require total leadership commit- ment, a receptive culture, enough tal- ented and experienced agile practitioners to staff hundreds of teams without de- pleting other capabilities, and highly prescriptive instruction manuals to align everyone’s approach. They also require a high tolerance of risk, along with con- tingency plans to deal with unexpected breakdowns. ING continues to iron out wrinkles as it expands agile throughout the organization.

Companies short on those assets are better off rolling out agile in sequenced steps, with each unit matching the im- plementation of opportunities to its capabilities. At the beginning of its ag- ile initiative, the advanced technology group at 3M Health Information Systems launched eight to 10 teams every month or two; now, two years in, more than 90 teams are up and running. 3M’s Corporate Research Systems Lab got started later but launched 20 teams in three months.

Whatever the pace or endpoint, re- sults should begin showing up quickly. Financial results may take a while—Jeff Bezos believes that most initiatives take five to seven years to pay dividends for Amazon—but positive changes in cus- tomer behavior and team problem solv- ing provide early signs that initiatives are on the right track. “Agile adoption has already enabled accelerated product deliveries and the release of a beta appli- cation six months earlier than originally planned,” says Tammy Sparrow, a senior program manager at 3M Health Information Systems.

Division leaders can determine the sequencing just as any agile team would. Start with the initiatives that offer potentially the greatest value and the most learning. SAP, the enterprise software company, was an early scaler of agile, launching the process a decade ago. Its leaders expanded agile first in its software de- velopment units—a highly customer-centric segment where they could test and refine the approach. They established a small consulting group to train, coach, and embed the new way of working, and they created a results tracker so that everyone could see the teams’ gains. “Showing concrete examples of impressive pro- ductivity gains from agile created more and more pull from the organization,” says Sebastian Wagner, who

was then a consulting manager in that group. Over the next two years the company rolled out agile to more than 80% of its development organizations, creating more than 2,000 teams. People in sales and marketing saw the need to adapt in order to keep up, so those ar- eas went next. Once the front end of the business was moving at speed, it was time for the back end to make the leap, so SAP shifted its group working on internal IT systems to agile.

Too many companies make the mistake of going for easy wins. They put teams into offsite incubators. They intervene to create easy workarounds to sys- temic obstacles. Such coddling increases the odds of a team’s success, but it doesn’t produce the learning environment or organizational changes necessary to

BIG-BANG TRANSITIONS ARE HARD. IT’S OFTEN BETTER TO ROLL OUT AGILE IN SEQUENCED STEPS, WITH EACH UNIT MATCHING THE IMPLEMENTATION OF OPPORTUNITIES TO ITS CAPABILITIES.

D O

R LI

N G

K IN

D ER

SL EY

/G ET

TY IM

A G

ES

MAY–JUNE 2018 HARVARD BUSINESS REVIEW 93 

scale dozens or hundreds of teams. A company’s early agile teams carry the burden of destiny. Testing them, just like testing any prototype, should reflect diverse, realistic conditions. Like SAP, the most successful companies focus on vital customer experiences that cause the greatest frustrations among functional silos.

Still, no agile team should launch unless and until it is ready to begin. Ready doesn’t mean planned in detail and guaranteed to succeed. It means that the team is: • focused on a major business opportunity with a lot

at stake • responsible for specific outcomes • trusted to work autonomously—guided by clear de-

cision rights, properly resourced, and staffed with a small group of multidisciplinary experts who are passionate about the opportunity

• committed to applying agile values, principles, and practices

• empowered to collaborate closely with customers • able to create rapid prototypes and fast feedback

loops • supported by senior executives who will address

impediments and drive adoption of the team’s work Following this checklist will help you plot your se-

quence for the greatest impact on both customers and the organization.

Master large-scale agile initiatives. Many exec- utives have trouble imagining that small agile teams

can attack large-scale, long-term projects. But in principle there is no limit to the number of agile teams you can create or how large the initiative can be. You can es- tablish “teams of teams” that work on related initiatives—an approach that is highly scalable. Saab’s aero- nautics business, for instance, has more than 100 agile teams operat- ing across software, hardware, and fuselage for its Gripen fighter jet—a $43 million item that is certainly one of the most complex products in the world. It coordinates through daily team-of-teams stand-ups. At 7:30 am each frontline agile team holds a 15-minute meeting to flag impediments, some of which can- not be resolved within that team. At 7:45 the impediments requiring co- ordination are escalated to a team of teams, where leaders work to either settle or further escalate issues. This approach continues, and by 8:45 the executive action team has a list of the critical issues it must resolve to keep progress on track. Aeronautics also coordinates its teams through a common rhythm of three-week sprints, a project master plan that

is treated as a living document, and the colocation of traditionally disparate parts of the organization—for instance, putting test pilots and simulators with de- velopment teams. The results are dramatic: IHS Jane’s has deemed the Gripen the world’s most cost-effective military aircraft.

BUILDING AGILITY ACROSS THE BUSINESS Expanding the number of agile teams is an important step toward increasing the agility of a business. But equally important is how those teams interact with the rest of the organization. Even the most advanced agile enterprises—Amazon, Spotify, Google, Netflix, Bosch, Saab, SAP, Salesforce, Riot Games, Tesla, and SpaceX, to name a few—operate with a mix of agile teams and traditional structures. To ensure that bureaucratic functions don’t hamper the work of agile teams or fail to adopt and commercialize the innovations developed by those teams, such companies constantly push for greater change in at least four areas.

Values and principles. A traditional hierarchical company can usually accommodate a small number of agile teams sprinkled around the organization. Conflicts between the teams and conventional proce- dures can be resolved through personal interventions and workarounds. When a company launches several

LEADERSHIP TEAMS NEED TO INSTILL AGILE VALUES THROUGHOUT THE ENTERPRISE, INCLUDING THE PARTS THAT DO NOT ORGANIZE INTO AGILE TEAMS.

YA M

A D

A T

A RO

/G ET

TY IM

A G

ES

94  HARVARD BUSINESS REVIEW MAY–JUNE 2018

FEATURE AGILE AT SCALE

hundred agile teams, however, that kind of ad hoc ac- commodation is no longer possible. Agile teams will be pressing ahead on every front. Traditionally struc- tured parts of the organization will fiercely defend the status quo. As with any change, skeptics can and will produce all kinds of antibodies that attack agile, ranging from refusals to operate on an agile timetable (“Sorry, we can’t get to that software module you need for six months”) to the withholding of funds from big opportunities that require unfamiliar solutions.

So a leadership team hoping to scale up agile needs to instill agile values and principles throughout the en- terprise, including the parts that do not organize into agile teams. This is why Bosch’s leaders developed new leadership principles and fanned out throughout the company: They wanted to ensure that everyone understood that things would be different and that agile would be at the center of the company’s culture.

Operating architectures. Implementing agile at scale requires modularizing and then seamlessly integrating workstreams. For example, Amazon can deploy software thousands of times a day because its IT architecture was designed to help developers make fast, frequent releases without jeopardizing the firm’s complex systems. But many large companies, no mat- ter how fast they can code programs, can deploy soft- ware only a few times a day or a week; that’s how their architecture works.

Building on the modular approach to product de- velopment pioneered by Toyota, Tesla meticulously designs interfaces among the components of its cars to allow each module to innovate independently. Thus the bumper team can change anything as long as it maintains stable interfaces with the parts it affects. Tesla is also abandoning traditional annual release cycles in favor of real-time responses to customer feedback. CEO Elon Musk says that the company makes about 20 engineering changes a week to im- prove the production and performance of the Model S. Examples include new battery packs, updated safety and auto pilot hardware, and software that automat- ically adjusts the steering wheel and seat for easier entry and exit.

In the most advanced agile enterprises, innovative product and process architectures are attacking some of the thorniest organizational constraints to fur- ther scaling. Riot Games, the developer of the wildly successful multiplayer online battle arena League of Legends, is redesigning the interfaces between agile teams and support-and-control functions that oper- ate conventionally, such as facilities, finance, and HR. Brandon Hsiung, the product lead for this ongoing ini- tiative, says it involves at least two key steps. One is shifting the functions’ definition of their customers. “Their customers are not their functional bosses, or the CEO, or even the board of directors,” he explains. “Their customers are the development teams they serve, who ultimately serve our players.” The company

instituted Net Promoter surveys to collect feedback on whether those customers would recommend the func- tions to others and made it plain that dissatisfied cus- tomers could sometimes hire outside providers. “It’s the last thing we want to happen, but we want to make sure our functions develop world-class capabilities that could compete in a free market,” Hsiung says.

Riot Games also revamped how its corporate func- tions interact with its agile teams. Some members of corporate functions may be embedded in agile teams, or a portion of a function’s capacity may be dedicated to requests from agile teams. Alternatively, functions might have little formal engagement with the teams after collaborating with them to establish certain boundaries. Says Hsiung: “Silos such as real estate and learning and development might publish philos- ophies, guidelines, and rules and then say, ‘Here are our guidelines. As long as you operate within them, you can go crazy; do whatever you believe is best for our players.’”

In companies that have scaled up agile, the organi- zation charts of support functions and routine opera- tions generally look much as they did before, though often with fewer management layers and broader spans of control as supervisors learn to trust and em- power people. The bigger changes are in the ways functional departments work. Functional priorities are necessarily more fully aligned with corporate strate- gies. If one of the company’s key priorities is improving customers’ mobile experience, that can’t be number 15 on finance’s funding list or HR’s hiring list. And depart- ments such as legal may need buffer capacity to deal with urgent requests from high- priority agile teams.

Over time even routine operations with hierarchi- cal structures are likely to develop more-agile mind- sets. Of course, finance departments will always man- age budgets, but they don’t need to keep questioning the decisions of the owners of agile initiatives. “Our CFO constantly shifts accountability to empowered agile teams,” says Ahmed Sidky, the head of develop- ment management at Riot Games. “He’ll say, ‘I am not here to run the finances of the company. You are, as team leaders. I’m here in an advisory capacity.’ In the day-to-day organization, finance partners are embed- ded in every team. They don’t control what the teams do or don’t do. They are more like finance coaches who ask hard questions and provide deep expertise. But ultimately it’s the team leader who makes deci- sions, according to what is best for Riot players.”

Some companies, and some individuals, may find these trade-offs hard to accept and challenging to im- plement. Reducing control is always scary—until you do so and find that people are happier and success rates triple. In a recent Bain survey of nearly 1,300 global executives, more respondents agreed with this state- ment about management than with any other: “Today’s business leaders must trust and empower people, not command and control them.” (Only 5% disagreed.)

MAY–JUNE 2018 HARVARD BUSINESS REVIEW 95 

Talent acquisition and motivation. Companies that are scaling up agile need systems for acquiring star players and motivating them to make teams bet- ter. (Treat your stars unfairly, and they will bolt to a sexy start-up.) They also need to unleash the wasted potential of more-typical team members and build commitment, trust, and joint accountability for out- comes. There’s no practical way to do this without changing HR procedures. A company can no longer hire purely for expertise, for instance; it now needs expertise combined with enthusiasm for work on a collaborative team. It can’t evaluate people accord- ing to whether they hit individual objectives; it now needs to look at their performance on agile teams and at team members’ evaluations of one another. Performance assessments typically shift from an annual basis to a system that provides relevant feed- back and coaching every few weeks or months. Train- ing and coaching programs encourage the develop- ment of cross- functional skills customized to the needs of individual employees. Job titles matter less and change less frequently with self-governing teams and fewer hierarchical levels. Career paths show how product owners—the individuals who set the vision and own the results of an agile team—can continue their personal development, expand their influence, and increase their compensation.

Companies may also need to revamp their compen- sation systems to reward group rather than individual accomplishments. They need recognition programs that celebrate contributions immediately. Public rec- ognition is better than confidential cash bonuses at bolstering agile values—it inspires recipients to im- prove even further, and it motivates others to emulate the recipients’ behaviors. Leaders can also reward “A” players by engaging them in the most vital opportuni- ties, providing them with the most advanced tools and the greatest possible freedom, and connecting them with the most talented mentors in their field.

Annual planning and budgeting cycles. In bu- reaucratic companies, annual strategy sessions and budget negotiations are powerful tools for align- ing the organization and securing commitments to stretch goals. Agile practitioners begin with different assumptions. They see that customer needs change frequently and that breakthrough insights can occur at any time. In their view, annual cycles constrain in- novation and adaptation: Unproductive projects burn resources until their budgets run out, while critical innovations wait in line for the next budget cycle to compete for funding.

In companies with many agile teams, funding pro- cedures are different. Funders recognize that for two- thirds of successful innovations, the original concept will change significantly during the development process. They expect that teams will drop some fea- tures and launch others without waiting for the next annual cycle. As a result, funding procedures evolve

to resemble those of a venture capitalist. VCs typically view funding decisions as opportunities to purchase options for further discovery. The objective is not to instantly create a large-scale business but, rather, to find a critical component of the ultimate solution. This leads to a lot of apparent failures but accelerates and reduces the cost of learning. Such an approach works well in an agile enterprise, vastly improving the speed and efficiency of innovation.

COMPANIES THAT SUCCESSFULLY scale up agile see major changes in their business. Scaling up shifts the mix of work so that the business is doing more innovation rel- ative to routine operations. The business is better able to read changing conditions and priorities, develop adaptive solutions, and avoid the constant crises that so frequently hit traditional hierarchies. Disruptive innovations will come to feel less disruptive and more like adaptive business as usual. The scaling up also brings agile values and principles to business opera- tions and support functions, even if many routine ac- tivities remain. It leads to greater efficiency and pro- ductivity in some of the business’s big cost centers. It improves operating architectures and organizational models to enhance coordination between agile teams and routine operations. Changes come on line faster and are more responsive to customer needs. Finally, the business delivers measurable improvements in outcomes—not only better financial results but also greater customer loyalty and employee engagement.

Agile’s test-and-learn approach is often described as incremental and iterative, but no one should mis- take incremental development processes for incre- mental thinking. SpaceX, for example, aims to use agile innovation to begin transporting people to Mars by 2024, with the goal of establishing a self-sustaining colony on the planet. How will that happen? Well, peo- ple at the company don’t really know…yet. But they have a vision that it’s possible, and they have some steps in mind. They intend to dramatically improve reliability and reduce expenses, partly by reusing rockets much like airplanes. They intend to improve propulsion systems to launch rockets that can carry at least 100 people. They plan to figure out how to refuel in space. Some of the steps include pushing current technologies as far as possible and then waiting for new partners and new technologies to emerge.

That’s agile in practice: big ambitions and step-by- step progress. It shows the way to proceed even when, as is so often the case, the future is murky.

HBR Reprint R1803F

DARRELL K. RIGBY is a partner in the Boston office of Bain & Company. He heads the firm’s global innovation and

retail practices and is the author of Winning in Turbulence. JEFF SUTHERLAND is a co-creator of the scrum form of agile innovation and the CEO of Scrum Inc., a consulting and training firm. ANDY NOBLE is a partner in Bain’s Boston office, specializing in retail and organization.

96  HARVARD BUSINESS REVIEW MAY–JUNE 2018

FEATURE AGILE AT SCALE

Harvard Business Review Notice of Use Restrictions, May 2009

Harvard Business Review and Harvard Business Publishing Newsletter content on EBSCOhost is licensed for the private individual use of authorized EBSCOhost users. It is not intended for use as assigned course material in academic institutions nor as corporate learning or training materials in businesses. Academic licensees may not use this content in electronic reserves, electronic course packs, persistent linking from syllabi or by any other means of incorporating the content into course resources. Business licensees may not host this content on learning management systems or use persistent linking or other means to incorporate the content into learning management systems. Harvard Business Publishing will be pleased to grant permission to make this content available through such means. For rates and permission, contact [email protected].