Agile Strategies

bobby schools

AgileatScale.pdf

Home >Business & Finance homework help >Management homework help >Agile Strategies

Magazine Article / Agile Project Management

Agile at Scale How to go from a few teams to hundreds by Darrell Rigby, Jeff Sutherland, and Andy Noble

From the Magazine (May–June 2018) / Reprint R1803F

MirageC/Getty Images

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.

For the exclusive use of R. Belviy, 2025.

This document is authorized for use only by Ronald Belviy in Copy of Copy of Industry 4.0 GSBA 590_MBA taught by Carsten Zimmermann, University of San Diego from Jul 2025 to Jan 2026.

https://hbr.org/archive-toc/BR1803

https://hbr.org/2018/05/agile-at-scale

Naturally, leaders who have experienced or heard about agile teams are

asking some compelling questions. What if a company were to launch

dozens, hundreds, or even thousands of agile teams throughout the

organization? Could whole segments of the business 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 appealing. 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 reorganized 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 entire 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 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 benefits. 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

HBR / Magazine Article / Agile at Scale

For the exclusive use of R. Belviy, 2025.

This document is authorized for use only by Ronald Belviy in Copy of Copy of Industry 4.0 GSBA 590_MBA taught by Carsten Zimmermann, University of San Diego from Jul 2025 to Jan 2026.

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 collaboration 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

models. They are small and multidisciplinary. Confronted with a large,

complex problem, they break it into modules, develop solutions to each

component through rapid prototyping and tight feedback loops, and

integrate 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 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 unclear, 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, purchasing, 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 development, marketing, and

even HR. (See “Embracing Agile,” HBR, May 2016, and “HR Goes Agile,”

HBR, March–April 2018.)

HBR / Magazine Article / Agile at Scale

For the exclusive use of R. Belviy, 2025.

This document is authorized for use only by Ronald Belviy in Copy of Copy of Industry 4.0 GSBA 590_MBA taught by Carsten Zimmermann, University of San Diego from Jul 2025 to Jan 2026.

https://hbr.org/2016/05/embracing-agile

https://hbr.org/2018/03/hr-goes-agile

Agile teams work differently from chain-of-command bureaucracies.

They are largely self-governing: Senior leaders tell team members

where to innovate but not how. And the teams work closely with

customers, both external and internal. Ideally, this puts responsibility

for innovation in the hands of those who are closest to customers. It

reduces layers of control and approval, thereby speeding up work and

increasing the teams’ motivation. It also frees up senior leaders to do

what only they can do: create and communicate long-term visions,

set and sequence strategic 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 initiatives: 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 organization 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 success. Leaders plunge in to solve problems and remove

constraints rather than delegate that work to subordinates. 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 operations in 60-plus countries,

took this approach. As leaders began to see that traditional top-down

management was no longer effective in a fast-moving, globalized

world, the company became an early adopter of agile methods. But

different business areas required different approaches, and Bosch’s first

attempt to implement what it called a “dual organization”—one in

HBR / Magazine Article / Agile at Scale

For the exclusive use of R. Belviy, 2025.

This document is authorized for use only by Ronald Belviy in Copy of Copy of Industry 4.0 GSBA 590_MBA taught by Carsten Zimmermann, University of San Diego from Jul 2025 to Jan 2026.

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 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 assignment the same

way Bosch managed most projects: with a goal, a target completion

date, and regular status reports to the board. But that approach

felt inconsistent with agile principles, and the company’s divisions

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 interactive.” The team compiled and rank-ordered a backlog of

corporate priorities that was regularly updated, and it focused on

steadily removing companywide barriers 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 fundamental

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.

HBR / Magazine Article / Agile at Scale

For the exclusive use of R. Belviy, 2025.

This document is authorized for use only by Ronald Belviy in Copy of Copy of Industry 4.0 GSBA 590_MBA taught by Carsten Zimmermann, University of San Diego from Jul 2025 to Jan 2026.

Getting Agile Rolling

At Bosch and other advanced agile enterprises, the visions are

ambitious. In keeping with agile principles, however, the leadership

team doesn’t plan every detail 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 address 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 agility (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 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, leadership 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 opportunities. Following agile’s modular approach, they may break

HBR / Magazine Article / Agile at Scale

For the exclusive use of R. Belviy, 2025.

This document is authorized for use only by Ronald Belviy in Copy of Copy of Industry 4.0 GSBA 590_MBA taught by Carsten Zimmermann, University of San Diego from Jul 2025 to Jan 2026.

the taxonomy into three components—customer 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 customer decisions,

behaviors, and satisfaction. These can usually be divided into a dozen

or so major experiences (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 payment 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

instance), 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 identify 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 taxonomy is that it encourages exploration

of a transformational 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.

HBR / Magazine Article / Agile at Scale

For the exclusive use of R. Belviy, 2025.

This document is authorized for use only by Ronald Belviy in Copy of Copy of Industry 4.0 GSBA 590_MBA taught by Carsten Zimmermann, University of San Diego from Jul 2025 to Jan 2026.

USAA has more than 500 agile teams up and running and plans to

add 100 more in 2018. The taxonomy 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 calling 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 product lines. The goal is to ensure

that managers responsible 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 accountable for business results. But those leaders rely on

customer-focused, cross-organizational teams to get much of the work

done. The company also depends 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

confusion. This kind of link is especially important when hierarchical

organizational structures do not align with customer behaviors. For

example, many companies have separate structures and P&Ls for online

and offline operations—but customers want seamlessly integrated

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

HBR / Magazine Article / Agile at Scale

For the exclusive use of R. Belviy, 2025.

This document is authorized for use only by Ronald Belviy in Copy of Copy of Industry 4.0 GSBA 590_MBA taught by Carsten Zimmermann, University of San Diego from Jul 2025 to Jan 2026.

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 capabilities and

constraints on the other. These determine 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, product

management, channel management, and marketing—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 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

commitment, a receptive culture, enough talented and experienced

agile practitioners to staff hundreds of teams without depleting other

capabilities, and highly prescriptive instruction manuals to align

everyone’s approach. They also require a high tolerance of risk, along

with contingency plans to deal with unexpected breakdowns. ING

continues to iron out wrinkles as it expands agile throughout the

organization.

HBR / Magazine Article / Agile at Scale

For the exclusive use of R. Belviy, 2025.

This document is authorized for use only by Ronald Belviy in Copy of Copy of Industry 4.0 GSBA 590_MBA taught by Carsten Zimmermann, University of San Diego from Jul 2025 to Jan 2026.

https://hbr.org/2018/03/one-banks-agile-team-experiment

Companies short on those assets are better off rolling out agile in

sequenced steps, with each unit matching the implementation of

opportunities to its capabilities. At the beginning of its agile 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, results 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 customer behavior and team problem solving

provide early signs that initiatives are on the right track. “Agile adoption

has already enabled accelerated product deliveries and the release of

a beta application six months earlier than originally planned,” says

Tammy Sparrow, a senior program manager at 3M Health Information

Systems.

Big-bang transitions are hard. It may be better to roll out agile in steps.

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 development 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 productivity gains from agile created more and more

HBR / Magazine Article / Agile at Scale

For the exclusive use of R. Belviy, 2025.

This document is authorized for use only by Ronald Belviy in Copy of Copy of Industry 4.0 GSBA 590_MBA taught by Carsten Zimmermann, University of San Diego from Jul 2025 to Jan 2026.

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 areas 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 systemic obstacles. Such coddling increases the odds

of a team’s success, but it doesn’t produce the learning environment

or organizational changes necessary to 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 decision 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

HBR / Magazine Article / Agile at Scale

For the exclusive use of R. Belviy, 2025.

This document is authorized for use only by Ronald Belviy in Copy of Copy of Industry 4.0 GSBA 590_MBA taught by Carsten Zimmermann, University of San Diego from Jul 2025 to Jan 2026.

• supported by senior executives who will address impediments and

drive adoption of the team’s work

Following this checklist will help you plot your sequence for the greatest

impact on both customers and the organization.

Master large-scale agile initiatives. Many executives 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 establish

“teams of teams” that work on related initiatives—an approach that is

highly scalable. Saab’s aeronautics business, for instance, has more than

100 agile teams operating 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 cannot be resolved within

that team. At 7:45 the impediments requiring coordination 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

development 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

HBR / Magazine Article / Agile at Scale

For the exclusive use of R. Belviy, 2025.

This document is authorized for use only by Ronald Belviy in Copy of Copy of Industry 4.0 GSBA 590_MBA taught by Carsten Zimmermann, University of San Diego from Jul 2025 to Jan 2026.

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 procedures

can be resolved through personal interventions and workarounds.

When a company launches several hundred agile teams, however, that

kind of ad hoc accommodation is no longer possible. Agile teams will

be pressing ahead on every front. Traditionally structured 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 enterprise, 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

HBR / Magazine Article / Agile at Scale

For the exclusive use of R. Belviy, 2025.

This document is authorized for use only by Ronald Belviy in Copy of Copy of Industry 4.0 GSBA 590_MBA taught by Carsten Zimmermann, University of San Diego from Jul 2025 to Jan 2026.

its IT architecture was designed to help developers make fast, frequent

releases without jeopardizing the firm’s complex systems. But many

large companies, no matter how fast they can code programs, can

deploy software only a few times a day or a week; that’s how their

architecture works.

Building on the modular approach to product development 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 improve the production and

performance of the Model S. Examples include new battery packs,

updated safety and autopilot hardware, and software that automatically

adjusts the steering wheel and seat for easier entry and exit.

Leadership teams need to instill agile values throughout the entire enterprise.

In the most advanced agile enterprises, innovative product and

process architectures are attacking some of the thorniest organizational

constraints to further 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 operate conventionally, such as facilities, finance, and

HR. Brandon Hsiung, the product lead for this ongoing initiative,

says it involves at least two key steps. One is shifting the functions’

definition of their customers. “Their customers are not their functional

HBR / Magazine Article / Agile at Scale

For the exclusive use of R. Belviy, 2025.

This document is authorized for use only by Ronald Belviy in Copy of Copy of Industry 4.0 GSBA 590_MBA taught by Carsten Zimmermann, University of San Diego from Jul 2025 to Jan 2026.

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 functions

to others and made it plain that dissatisfied customers 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 functions 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 philosophies, 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 organization charts of

support functions and routine operations generally look much as they

did before, though often with fewer management layers and broader

spans of control as supervisors learn to trust and empower people. The

bigger changes are in the ways functional departments work. Functional

priorities are necessarily more fully aligned with corporate strategies.

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 departments such as legal may need buffer capacity to

deal with urgent requests from high-priority agile teams.

HBR / Magazine Article / Agile at Scale

For the exclusive use of R. Belviy, 2025.

This document is authorized for use only by Ronald Belviy in Copy of Copy of Industry 4.0 GSBA 590_MBA taught by Carsten Zimmermann, University of San Diego from Jul 2025 to Jan 2026.

Over time even routine operations with hierarchical structures are likely

to develop more-agile mindsets. Of course, finance departments will

always manage 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 development 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

embedded 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

decisions, according to what is best for Riot players.”

Some companies, and some individuals, may find these trade-offs hard

to accept and challenging to implement. 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 statement about management than

with any other: “Today’s business leaders must trust and empower

people, not command and control them.” (Only 5% disagreed.)

Talent acquisition and motivation. Companies that are scaling up agile

need systems for acquiring star players and motivating them to make

teams better. (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 outcomes. 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 according to

whether they hit individual objectives; it now needs to look at their

performance on agile teams and at team members’ evaluations of

HBR / Magazine Article / Agile at Scale

For the exclusive use of R. Belviy, 2025.

This document is authorized for use only by Ronald Belviy in Copy of Copy of Industry 4.0 GSBA 590_MBA taught by Carsten Zimmermann, University of San Diego from Jul 2025 to Jan 2026.

one another. Performance assessments typically shift from an annual

basis to a system that provides relevant feedback and coaching every

few weeks or months. Training and coaching programs encourage

the development 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 compensation systems

to reward group rather than individual accomplishments. They need

recognition programs that celebrate contributions immediately. Public

recognition is better than confidential cash bonuses at bolstering agile

values—it inspires recipients to improve even further, and it motivates

others to emulate the recipients’ behaviors. Leaders can also reward

“A” players by engaging them in the most vital opportunities, 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 bureaucratic companies,

annual strategy sessions and budget negotiations are powerful tools for

aligning 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 innovation 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 procedures are different.

Funders recognize that for two-thirds of successful innovations, the

HBR / Magazine Article / Agile at Scale

For the exclusive use of R. Belviy, 2025.

This document is authorized for use only by Ronald Belviy in Copy of Copy of Industry 4.0 GSBA 590_MBA taught by Carsten Zimmermann, University of San Diego from Jul 2025 to Jan 2026.

original concept will change significantly during the development

process. They expect that teams will drop some features 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 relative 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 operations and support

functions, even if many routine activities remain. It leads to greater

efficiency and productivity 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 mistake incremental development

processes for incremental thinking. SpaceX, for example, aims to use

HBR / Magazine Article / Agile at Scale

For the exclusive use of R. Belviy, 2025.

This document is authorized for use only by Ronald Belviy in Copy of Copy of Industry 4.0 GSBA 590_MBA taught by Carsten Zimmermann, University of San Diego from Jul 2025 to Jan 2026.

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, people 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.

A version of this article appeared in the May–June 2018 issue of Harvard Business Review.

Darrell Rigby is a partner in the Boston office of Bain & Company, where he heads the firm’s global agile enterprise practice. He is a coauthor of Doing Agile Right: Transformation Without Chaos (Harvard Business Review Press, 2020).

Jeff Sutherland is a cocreator 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 & Company’s Organization practice and is located in the Boston office.

HBR / Magazine Article / Agile at Scale

For the exclusive use of R. Belviy, 2025.

This document is authorized for use only by Ronald Belviy in Copy of Copy of Industry 4.0 GSBA 590_MBA taught by Carsten Zimmermann, University of San Diego from Jul 2025 to Jan 2026.

https://hbr.org/archive-toc/BR1803

https://hbr.org/search?term=Darrell%20Rigby&search_type=search-all

https://www.amazon.com/Doing-Agile-Right-Transformation-Without/dp/163369870X/

https://hbr.org/search?term=Jeff%20Sutherland&search_type=search-all

https://hbr.org/search?term=Andy%20Noble&search_type=search-all

Agile at Scale

Leading Agile by Being Agile
Getting Agile Rolling

Create a taxonomy of teams.
Sequence the transition.
Master large-scale agile initiatives.

Building Agility Across the Business

Values and principles.
Operating architectures.
Talent acquisition and motivation.
Annual planning and budgeting cycles.

Conclusion

AUTHORS

Darrell Rigby
Jeff Sutherland
Andy Noble