2 pages memo single space

using the attached article as reference

Another references must be scholar 

Your Scrum project was such a success, your Vice Presidents want to start exploring scaling Agile enterprise wide. They  have asked you to draft 2 page memo using scholarly articles attached here. You should not use any blogs, news outlets, this should be scholarly based memo.

Your memo should address: 

· How the VPs should assess if Lizard Farm is ready to embrace Agile?

· What are some lessons learned that Lizard Farm should apply from previous Agile scale initiatives? 

· Do you recommend Scaling Agile? 

. Yes, but with some limitations. Explain those limitations. 

. Yes, absolutely. Explain why you are certain.

. No. Explain why you don’t think scaling Agile is a good idea.

Lizard Farm – We’re working to keep your money…

Insurance Management System (IMS)
Project
Description
New system needed within a year or so, to handle all aspects of our company’s insurance business. We

operate in all 50 states. We handle auto insurance and home insurance, and offer discounts if you use

us for both together. We do not do life insurance: apparently, everyone dies at some point.

The system must do at least the following:

 Claim recording

o For Example: If I have a car accident or a storm destroys the roof of my home I need to

alert Lizard Farm.

 Claim tracking

o For Example: Lizard Farm needs to track that car accident or destruction to my home, so

different people in the company have access to it.

 Claim payments

o For Example: Lizard Farm must pay me for the damage caused to my car in a reasonable

amount of time.

 Customer tracking

o For Example: Lizard Farm must be able to track customers, so they can determine if a

customer is “high risk” – such as constant car accidents.

 Premium tracking

o For Example: Lizard Farm needs to know if customers are paying their premiums.

General Assignment Notes
You will be expected to do some research here into the nature of Insurance companies and what they

do, but you are not expected to become an expert in software of that type. You should be able to

identify with and perhaps enhance the list above, but that is primarily to give you a fertile field for

picking User Stories for the project. I am more interested in how you communicate your thinking, both

to me, to your fictional team, and to the senior organization people that need convincing that Agile is

viable.

Remember the marking standards! If you do exactly what the assignment asks for, you will get a good

solid B+ (85%). To get an A, you must exceed expectations without going beyond the assignment

boundaries – for example, if you include a detailed project schedule with the first assignment, you will

probably lose points!

Below is the general assignment breakdown – each week will contain details on the specific assignment.

All weeks will be open, so you are welcome to “look ahead” to see what the upcoming assignment will

be about.

Assignment 1
Produce Agile Justification Memo

Assignment 2
High-Level Product Plan and Epics

Assignment 3
Completed Sprint Plan and Backlog.

Assignment 4
Relative Estimation and Task Board

THE BIG IDEA

Darrell K. Rigby is a
partner in the Boston
office of Bain & Company.
He heads the firm’s global
innovation and retail
practices. Jeff Sutherland
is a cocreator of the scrum

form of agile innovation
and the CEO of Scrum Inc.,
a consulting and training
firm. Hirotaka Takeuchi
is a professor in the
strategy unit of Harvard
Business School.

embracing
agile

How to master the process
that’s transforming management
BY DARRELL K. RIGBY, JEFF SUTHERLAND, AND HIROTAKA TAKEUCHI

agile innovation methods have revolutionized information technology. Over the past 25 to
30 years they have greatly increased
success rates in software development,
improved quality and speed to market,
and boosted the motivation and
productivity of IT teams.TODD

S
T.

J
O

H
N

HBR.ORG

May 2016 Harvard Business Review 41

Now agile methodologies—which involve new
values, principles, practices, and benefits and are a
radical alternative to command-and-control-style
management—are spreading across a broad range of
industries and functions and even into the C-suite.
National Public Radio employs agile methods to
create new programming. John Deere uses them
to develop new machines, and Saab to produce
new fighter jets. Intronis, a leader in cloud backup
services, uses them in marketing. C.H. Robinson, a
global third-party logistics provider, applies them in
human resources. Mission Bell Winery uses them for
everything from wine production to warehousing to
running its senior leadership group. And GE relies
on them to speed a much-publicized transition from
20th-century conglomerate to 21st-century “digital
industrial company.” By taking people out of their
functional silos and putting them in self-managed
and customer-focused multidisciplinary teams, the
agile approach is not only accelerating profitable
growth but also helping to create a new generation
of skilled general managers.

The spread of agile raises intriguing possibilities.
What if a company could achieve positive returns
with 50% more of its new-product introductions?
What if marketing programs could generate 40%
more customer inquiries? What if human resources
could recruit 60% more of its highest-priority tar-
gets? What if twice as many workers were emotion-
ally engaged in their jobs? Agile has brought these
levels of improvement to IT. The opportunity in
other parts of the company is substantial.

But a serious impediment exists. When we ask
executives what they know about agile, the re-
sponse is usually an uneasy smile and a quip such
as “Just enough to be dangerous.” They may throw
around agile-related terms (“sprints,” “time boxes”)
and claim that their companies are becoming more
and more nimble. But because they haven’t gone
through training, they don’t really understand the
approach. Consequently, they unwittingly continue
to manage in ways that run counter to agile princi-
ples and practices, undermining the effectiveness of
agile teams in units that report to them.

These executives launch countless initiatives
with urgent deadlines rather than assign the high-
est priority to two or three. They spread themselves
and their best people across too many proj ects. They
schedule frequent meetings with members of agile
teams, forcing them to skip working sessions or send

substitutes. Many of them become overly involved
in the work of individual teams. They talk more than
listen. They promote marginal ideas that a team has
previously considered and back-burnered. They rou-
tinely overturn team decisions and add review layers
and controls to ensure that mistakes aren’t repeated.
With the best of intentions, they erode the benefits
that agile innovation can deliver.

Innovation is what agile is all about. Although the
method is less useful in routine operations and pro-
cesses, these days most companies operate in highly
dynamic environments. They need not just new
products and services but also innovation in func-
tional processes, particularly given the rapid spread
of new software tools. Companies that create an envi-
ronment in which agile flourishes find that teams can
churn out innovations faster in both those categories.

From our work advising and studying such com-
panies, we have discerned six crucial practices that
leaders should adopt if they want to capitalize on
agile’s potential.

1 Learn How Agile Really Works
Some executives seem to associate agile with
anarchy (everybody does what he or she wants
to), whereas others take it to mean “doing what I
say, only faster.” But agile is neither. (See the side-
bar “Agile Values and Principles.”) It comes in
several varieties, which have much in common
but emphasize slightly different things. They in-
clude scrum, which emphasizes creative and adap-
tive teamwork in solving complex problems; lean
development, which focuses on the continual elimi-
nation of waste; and kanban, which concentrates
on reducing lead times and the amount of work in
process. One of us (Jeff Sutherland) helped develop
the scrum methodology and was inspired to do so in
part by “The New New Product Development Game,”
a 1986 HBR article coauthored by another of us
(Hirotaka Takeuchi). Because scrum and its deriva-
tives are employed at least five times as often as the
other techniques, we will use its methodologies to
illustrate agile practices.

The fundamentals of scrum are relatively simple.
To tackle an opportunity, the organization forms and
empowers a small team, usually three to nine people,
most of whom are assigned full-time. The team is
cross-functional and includes all the skills necessary
to complete its tasks. It manages itself and is strictly
accountable for every aspect of the work.

42  Harvard Business Review May 2016

THE BIG IDEA EMBRACING AGILE

The team’s “initiative owner” (also known as a
product owner) is ultimately responsible for deliv-
ering value to customers (including internal custom-
ers and future users) and to the business. The person
in this role usually comes from a business function
and divides his or her time between working with
the team and coordinating with key stakeholders:
customers, senior executives, and business man-
agers. The initiative owner may use a technique
such as design thinking or crowdsourcing to build
a comprehensive “portfolio backlog” of promising
opportunities. Then he or she continually and ruth-
lessly rank-orders that list according to the latest
estimates of value to internal or external customers
and to the company.

The initiative owner doesn’t tell the team who
should do what or how long tasks will take. Rather,
the team creates a simple road map and plans in de-
tail only those activities that won’t change before ex-
ecution. Its members break the highest-ranked tasks
into small modules, decide how much work the
team will take on and how to accomplish it, develop
a clear definition of “done,” and then start building
working versions of the product in short cycles (less
than a month) known as sprints. A process facilita-
tor (often a trained scrum master) guides the process.
This person protects the team from distractions and
helps it put its collective intelligence to work.

The process is transparent to everyone. Team
members hold brief daily “stand-up” meetings to
review prog ress and identify roadblocks. They re-
solve disagreements through experimentation and
feedback rather than endless debates or appeals to
authority. They test small working prototypes of part
or all of the offering with a few customers for short
periods of time. If customers get excited, a prototype
may be released immediately, even if some senior
executive isn’t a fan, or others think it needs more

bells and whistles. The team then brainstorms ways
to improve future cycles and prepares to attack the
next top priority.

Compared with traditional management ap-
proaches, agile offers a number of major benefits,
all of which have been studied and documented. It
increases team productivity and employee satisfac-
tion. It minimizes the waste inherent in redundant
meetings, repetitive planning, excessive documenta-
tion, quality defects, and low-value product features.
By improving visibility and continually adapting to
customers’ changing priorities, agile improves cus-
tomer engagement and satisfaction, brings the most
valuable products and features to market faster and
more predictably, and reduces risk. By engaging team
members from multiple disciplines as collaborative
peers, it broadens organizational experience and
builds mutual trust and respect. Finally, by dramati-
cally reducing the time squandered on micromanag-
ing functional proj ects, it allows senior managers to
devote themselves more fully to higher-value work

Idea in Brief
THE PROBLEM
Agile methods such as scrum,
kanban, and lean development
are spreading beyond IT to
other functions. Although some
companies are scoring big
improvements in productivity,
speed to market, and customer
and employee satisfaction,
others are struggling.

THE ROOT CAUSE
Leaders don’t really
understand agile. As a result,
they unwittingly continue
to employ conventional
management practices that
undermine agile proj ects.

THE SOLUTION
Learn the basics of agile.
Understand the conditions in
which it does or doesn’t work.
Start small and let it spread
organically. Allow “master”
teams to customize it. Employ
agile at the top. Destroy the
barriers to agile behaviors.

some executives
seem to associate
agile with anarchy.

HBR.ORG

May 2016 Harvard Business Review 43

work can be modularized; close collaboration with
end users (and rapid feedback from them) is fea-
sible; and creative teams will typically outperform
command-and-control groups.

In our experience, these conditions exist for
many product development functions, marketing
proj ects, strategic-planning activities, supply-chain
challenges, and resource allocation decisions. They
are less common in routine operations such as plant
maintenance, purchasing, sales calls, and account-
ing. (See the exhibit “The Right Conditions for
Agile.”) And because agile requires training, behavio-
rial change, and often new information technologies,
executives must decide whether the anticipated pay-
offs will justify the effort and expense of a transition.

Agile innovation also depends on having a cadre
of eager participants. One of its core principles
is “Build proj ects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.” When the ma-
jority of a company, a function, or a team chooses
to adopt agile methodologies, leaders may need
to press the holdouts to follow suit or even replace
them. But it’s better to enlist passionate volunteers
than to coerce resisters.

OpenView Venture Partners, a firm that has
invested in about 30 companies, took this path.
Having learned about agile from some of the com-
panies in its portfolio, Scott Maxwell, the firm’s
founder, began using its methodologies at the firm
itself. He found that they fit some activities more
easily than others. Agile worked well for strategic
planning and marketing, for instance, where com-
plex problems can often be broken into modules
and cracked by creative multidisciplinary teams.
That wasn’t the case for selling: Any sales call can
change a representative’s to-do list on the spot, and
it would be too complicated and time-consuming
to reassemble the sales team, change the portfolio
backlog, and reassign accounts every hour.

Maxwell provided the companies in OpenView’s
portfolio with training in agile principles and prac-
tices and let them decide whether to adopt the ap-
proach. Some of them immediately loved the idea of
implementing it; others had different priorities and
decided to hold off. Intronis was one fan. Its market-
ing unit at the time relied on an annual plan that fo-
cused primarily on trade shows. Its sales department
complained that marketing was too conservative
and not delivering results. So the company hired

that only they can do: creating and adjusting the cor-
porate vision; prioritizing strategic initiatives; simpli-
fying and focusing work; assigning the right people to
tasks; increasing cross-functional collaboration; and
removing impediments to prog ress.

2 Understand Where Agile
Does or Does Not Work
Agile is not a panacea. It is most effective and easiest
to implement under conditions commonly found
in software innovation: The problem to be solved
is complex; solutions are initially unknown, and
product requirements will most likely change; the

agile innovation
depends on
having a cadre of
eager participants.

THE BIG IDEA EMBRACING AGILE

Richard Delahaye, a web developer turned marketer,
to implement agile. Under his guidance the mar-
keting team learned, for example, how to produce
a topical webinar in a few days rather than several
weeks. (A swiftly prepared session on CryptoLocker
malware attracted 600 registrants—still a company
rec ord.) Team members today continue to create
calendars and budgets for the digital marketing unit,
but with far less line-item detail and greater flexibil-
ity for serendipitous developments. The sales team
is much happier.

3 Start Small and
Let the Word Spread
Large companies typically launch change programs
as massive efforts. But the most successful introduc-
tions of agile usually start small. They often begin in
IT, where software developers are likely to be famil-
iar with the principles. Then agile might spread to
another function, with the original practitioners act-
ing as coaches. Each success seems to create a group
of passionate evangelists who can hardly wait to tell
others in the organization how well agile works.

The adoption and expansion of agile at John
Deere, the farm equipment company, provides an
example. George Tome, a software engineer who
had become a proj ect manager within Deere’s cor-
porate IT group, began applying agile principles
in 2004 on a low-key basis. Gradually, over several
years, software development units in other parts
of Deere began using them as well. This growing
interest made it easier to introduce the methodol-
ogy to the company’s business development and
marketing organizations.

In 2012 Tome was working as a manager in the
Enterprise Advanced Marketing unit of the R&D
group responsible for discovering technologies that
could revolutionize Deere’s offerings. Jason Brantley,
the unit head, was concerned that traditional proj ect
management techniques were slowing innovation,
and the two men decided to see whether agile could
speed things up. Tome invited two other unit man-
agers to agile training classes. But all the terminol-
ogy and examples came from software, and to one
of the managers, who had no software background,
they sounded like gibberish. Tome realized that oth-
ers would react the same way, so he tracked down
an agile coach who knew how to work with people
without a software background. In the past few years
he and the coach have trained teams in all five of the

Agile Values and Principles

PEOPLE OVER PROCESSES
AND TOOLS
Proj ects should be built around
motivated individuals who are
given the support they need and
trusted to get the job done. Teams
should abandon the assembly-line
mentality in favor of a fun, creative
environment for problem solving, and
should maintain a sustainable pace.
Employees should talk face-to-face
and suggest ways to improve their
work environment. Management
should remove impediments to
easier, more fruitful collaboration.

RESPOND TO CHANGE
RATHER THAN FOLLOW A PLAN
Most detailed predictions and plans
of conventional proj ect management
are a waste of time and money.
Although teams should create a
vision and plan, they should plan only
those tasks that won’t have changed
by the time they get to them. And
people should be happy to learn
things that alter their direction, even
late in the development process. That
will put them closer to the customer
and make for better results.

WORKING PROTOTYPES OVER
EXCESSIVE DOCUMENTATION
Innovators who can see their results
in real market conditions will learn
faster, be happier, stay longer, and
do more-valuable work. Teams
should experiment on small parts
of the product with a few customers
for short periods, and if customers
like them, keep them. If customers
don’t like them, teams should figure
out fixes or move on to the next
thing. Team members should resolve
arguments with experiments rather
than endless debates or appeals
to authority.

CUSTOMER COLLABORATION
OVER RIGID CONTRACTS
Time to market and cost are
paramount, and specifications
should evolve throughout the
project, because customers can
seldom predict what they will
actually want. Rapid prototyping,
frequent market tests, and constant
collaboration keep work focused on
what they will ultimately value.

In 2001, 17 rebellious software developers (including Jeff Sutherland)
met in Snowbird, Utah, to share ideas for improving traditional
“waterfall” development, in which detailed requirements and execution
plans are created up front and then passed sequentially from function
to function. This approach worked fine in stable environments, but not
when software markets began to change rapidly and unpredictably.
In that scenario, product specifications were outdated by the time the
software was delivered to customers, and developers felt oppressed by
bureaucratic procedures.

The rebels proposed four new values for developing software, described
principles to guide adherence to those values, and dubbed their call to
arms “The Agile Manifesto.” To this day, development frameworks that
follow these values and principles are known as agile techniques.

Here is an adapted version of the manifesto:

R&D group’s centers. Tome also began publishing
weekly one-page articles about agile principles and
practices, which were e-mailed to anyone interested
and later posted on Deere’s Yammer site. Hundreds
of Deere employees joined the discussion group. “I
wanted to develop a knowledge base about agile
that was specific to Deere so that anyone within the
organization could understand it,” Tome says. “This
would lay the foundation for moving agile into any
part of the company.”

HBR.ORG

May 2016 Harvard Business Review 45

4 Allow “Master” Teams to
Customize Their Practices
Japanese martial arts students, especially those
studying aikido, often learn a process called shu-
ha-ri. In the shu state they study proven disciplines.
Once they’ve mastered those, they enter the ha
state, where they branch out and begin to modify
traditional forms. Eventually they advance to ri,
where they have so thoroughly absorbed the laws
and principles that they are free to improvise as
they choose.

Mastering agile innovation is similar. Before be-
ginning to modify or customize agile, a person or
team will benefit from practicing the widely used
methodologies that have delivered success in thou-
sands of companies. For instance, it’s wise to avoid
beginning with part-time assignment to teams or
with rotating membership. Empirical data shows
that stable teams are 60% more productive and 60%
more responsive to customer input than teams that
rotate members.

Using agile techniques, Enterprise Advanced
Marketing has significantly compressed innova-
tion proj ect cycle times—in some cases by more
than 75%. One example is the development in about
eight months of a working prototype of a new “ma-
chine form” that Deere has not yet disclosed. “If
everything went perfectly in a traditional process,”
Brantley says, “it would be a year and a half at best,
and it could be as much as two and a half or three
years.” Agile generated other improvements as well.
Team engagement and happiness in the unit quickly
shot from the bottom third of companywide scores
to the top third. Quality improved. Velocity (as mea-
sured by the amount of work accomplished in each
sprint) increased, on average, by more than 200%;
some teams achieved an increase of more than
400%, and one team soared 800%.

Success like this attracts attention. Today, ac-
cording to Tome, in almost every area at John Deere
someone is either starting to use agile or thinking
about how it could be used.

MARKET ENVIRONMENT
Customer preferences and solution
options change frequently.

Market conditions are stable
and predictable.

CUSTOMER INVOLVEMENT

Close collaboration and rapid
feedback are feasible.
Customers know better what they
want as the process prog resses.

Requirements are clear at the
outset and will remain stable.
Customers are unavailable for
constant collaboration.

INNOVATION TYPE

Problems are complex, solutions are
unknown, and the scope isn’t clearly
defined. Product specifications may
change. Creative breakthroughs and
time to market are important.
Cross-functional collaboration is vital.

Similar work has been done before,
and innovators believe the solutions
are clear. Detailed specifications
and work plans can be forecast
with confidence and should be
adhered to. Problems can be solved
sequentially in functional silos.

MODULARITY OF WORK

Incremental developments have
value, and customers can use them.
Work can be broken into parts and
conducted in rapid, iterative cycles.
Late changes are manageable.

Customers cannot start testing
parts of the product until
everything is complete.
Late changes are expensive
or impossible.

IMPACT OF INTERIM MISTAKES They provide valuable learning. They may be catastrophic.

SOURCE BAIN & COMPANY

CONDITIONS FAVORABLE UNFAVORABLE

The Right Conditions for Agile

46  Harvard Business Review May 2016

THE BIG IDEA EMBRACING AGILE

performance assessments, press interviews, and
visits to plants, customers, and suppliers—fall into
this category.) But many, and arguably the most
important, are. They include strategy development
and resource allocation, cultivating breakthrough
innovations, and improving organizational collabo-
ration. Senior executives who come together as an
agile team and learn to apply the discipline to these
activities achieve far-reaching benefits. Their own
productivity and morale improve. They speak the
language of the teams they are empowering. They
experience common challenges and learn how to
overcome them. They recognize and stop behaviors
that impede agile teams. They learn to simplify and
focus work. Results improve, increasing confidence
and engagement throughout the organization.

A number of companies have reallocated 25% or
more of selected leaders’ time from functional silos
to agile leadership teams. These teams rank-order
enterprisewide portfolio backlogs, establish and co-
ordinate agile teams elsewhere in the organization
to address the highest priorities, and systematically
eliminate barriers to their success. Here are three
examples of C-suites that took up agile:

1. Catching up with the troops. Systematic, a
525-employee software company, began applying
agile methodologies in 2005. As they spread to all
its software development teams, Michael Holm, the
company’s CEO and cofounder, began to worry that
his leadership team was hindering prog ress. “I had
this feeling that I was saying, ‘Follow me—I’m just
behind you,’” he told us. “The development teams
were using scrum and were doing things differently,
while the management team was stuck doing things
the same old-fashioned way”—moving too slowly
and relying on too many written reports that always
seemed out-of-date. So in 2010 Holm decided to run
his nine-member executive group as an agile team.

The team reprioritized management activities,
eliminating more than half of recurring reports
and converting others to real-time systems while
increasing attention to business-critical items such
as sales proposals and customer satisfaction. The
group started by meeting every Monday for an hour
or two but found the pace of decision making too
slow. So it began having daily 20-min ute stand-ups
at 8:40 am to discuss what members had done the
day before, what they would do that day, and where
they needed help. More recently the senior team
began to use physical boards to track its own actions

Over time, experienced practitioners should
be permitted to customize agile practices. For ex-
ample, one principle holds that teams should keep
their prog ress and impediments constantly visible.
Originally, the most popular way of doing this was
by manually advancing colored sticky notes from
the “to-do” column to “doing” to “done” on large
whiteboards (known as kanban boards). Many
teams are still devoted to this practice and enjoy
having nonmembers visit their team rooms to view
and discuss prog ress. But others are turning to soft-
ware programs and computer screens to minimize
input time and allow the information to be shared
simultaneously in multiple locations.

A key principle guides this type of improvisa-
tion: If a team wants to modify particular practices,
it should experiment and track the results to make
sure that the changes are improving rather than
reducing customer satisfaction, work velocity, and
team morale.

Spotify, the music-streaming company, exempli-
fies an experienced adapter. Founded in 2006, the
company was agile from birth, and its entire busi-
ness model, from product development to marketing
and general management, is geared to deliver better
customer experiences through agile innovation. But
senior leaders no longer dictate specific practices; on
the contrary, they encourage experimentation and
flexibility as long as changes are consistent with ag-
ile principles and can be shown to improve outcomes.
As a result, practices vary across the company’s 70

“squads” (Spotify’s name for agile innovation teams)
and its “chapters” (the company term for functional
competencies such as user interface development and
quality testing). Although nearly every squad con-
sists of a small cross-functional team and uses some
form of visual progress tracking, ranked priorities,
adaptive planning, and brainstorming sessions on
how to improve the work process, many teams omit
the “burndown” charts (which show work performed
and work remaining) that are a common feature of
agile teams. Nor do they always measure velocity,
keep prog ress reports, or employ the same tech-
niques for estimating the time required for a given
task. These squads have tested their modifications
and found that they improve results.

5 Practice Agile at the Top
Some C-suite activities are not suited to agile meth-
odologies. (Routine and predictable tasks—such as

FURTHER
RESOURCES

From HBR.org:
“Lean Knowledge Work”
Bradley R. Staats and
David M. Upton

“Decoding the
DNA of the Toyota
Production System”
Steven Spear and
H. Kent Bowen

“Beyond Toyota: How
to Root Out Waste and
Pursue Perfection”
James P. Womack and
Daniel T. Jones

Other:
Agile Alliance
For guides to agile practices,
links to “The Agile Manifesto,”
and training videos

Scrum Alliance
For a “Scrum Guide,”
conference presentations
and videos, and the “State
of Scrum” research report

ScrumLab Open
For training presentations,
videos, webinars, and
published papers

Annual State of
Agile Survey
For key statistics such
as usage rates, customer
benefits, barriers to
adoption and success,
and specific practices used

HBR.ORG

May 2016 Harvard Business Review 47

is how we will improve things.” Surak believes that
this shows the organization that “executives work in
the same ways as engineers,” increasing employee
motivation and commitment to agile practices.

3. Aligning departments and functions on a
common vision. Erik Martella, the vice president
and general manager of Mission Bell Winery, a pro-
duction facility of Constellation Brands, introduced
agile and helped it spread throughout the organiza-
tion. Leaders of each department served as initia-
tive owners on the various agile teams within their
departments. Those individual teams achieved im-
pressive results, but Martella worried that their time
was being spread too thin and that department and
enterprise priorities weren’t always aligned. He de-
cided to pull department leaders into an executive
agile team focused on the enterprise initiatives that
held the greatest value and the greatest opportunity
for cross-functional collaboration, such as increasing
process flows through the warehouse.

The team is responsible for building and continu-
ally refining the backlog of enterprise priorities, en-
suring that agile teams are working on the right prob-
lems and have sufficient resources. Team members
also protect the organization from pet proj ects that
don’t deserve high priority. For instance, shortly after
Martella started implementing agile, he received an
e-mail from a superior in Constellation’s corporate
office suggesting that the winery explore a personal
passion of the sender. Previously, Martella might
have responded, “OK, we’ll jump right on it.” Instead,
he replied that the winery was following agile prin-
ciples: The idea would be added to the list of poten-
tial opportunities and prioritized. As it happened,
the executive liked the approach—and when he was
informed that his suggestion had been assigned a
low priority, he readily accepted the decision.

Working on agile teams can also help prepare
functional managers—who rarely break out of their
silos in today’s overspecialized organizations—for
general management roles. It exposes them to people
in other disciplines, teaches collaborative practices,
and underscores the importance of working closely
with customers—all essential for future leaders.

6 Destroy the Barriers
to Agile Behaviors
Research by Scrum Alliance, an independent non-
profit with 400,000-plus members, has found that
more than 70% of agile practitioners report tension

and the improvements coming from the business
units. Other functions, including HR, legal, finance,
and sales, now operate in much the same way.

2. Speeding a corporate transition. In 2015
General Electric rebranded itself as a “digital indus-
trial company,” with a focus on digitally enabled
products. Part of the transformation involved creat-
ing GE Digital, an organizational unit that includes
all 20,000-plus of the company’s software-related
employees. Brad Surak, who began his career as a
software engineer and is now GE Digital’s COO, was
intimately familiar with agile. He piloted scrum
with the leadership team responsible for developing
industrial internet applications and then, more re-
cently, began applying it to the new unit’s manage-
ment processes, such as operating reviews. Surak is
the initiative owner, and an engineering executive
is the scrum master. Together they have prioritized
backlog items for the executive team to address,
including simplifying the administrative process
that teams follow to acquire hardware and solving
knotty pricing issues for products requiring input
from multiple GE businesses.

The scrum team members run two-week sprints
and conduct stand-up meetings three times a week.
They chart their prog ress on a board in an open con-
ference room where any employee can see it. Surak
says, “It takes the mystery out of what executives do
every day. Our people want to know if we are in tune
with what they care about as employees.” The team
collects employee happiness surveys, conducts root
cause analysis on the impediments to working more
effectively, and reports back to people throughout the
organization, saying (in effect), “We heard you. Here

scrum “takes the
mystery out of
what executives
do every day.”

48  Harvard Business Review May 2016

THE BIG IDEA EMBRACING AGILE HBR.ORG

members, appointing the team leader, and approv-
ing the team’s decisions. An agile leadership team
often authorizes a senior executive to identify the
critical issues, design processes for addressing them,
and appoint a single owner for each innovation ini-
tiative. Other senior leaders must avoid second-
guessing or overturning the owner’s decisions. It’s
fine to provide guidance and assistance, but if you
don’t like the results, change the initiative owner—
don’t incapacitate him or her.

Focus on teams, not individuals. Studies by
the MIT Center for Collective Intelligence and others
show that although the intelligence of individuals af-
fects team performance, the team’s collective intel-
ligence is even more important. It’s also far easier to
change. Agile teams use process facilitators to con-
tinually improve their collective intelligence—for
example, by clarifying roles, teaching conflict reso-
lution techniques, and ensuring that team members
contribute equally. Shifting metrics from output and
utilization rates (how busy people are) to business
outcomes and team happiness (how valuable and
engaged people are) also helps, as do recognition and
reward systems that weight team results higher than
individual efforts.

Lead with questions, not orders. General
George S. Patton Jr. famously advised leaders never
to tell people how to do things: “Tell them what to
do, and they will surprise you with their ingenuity.”
Rather than give orders, leaders in agile organiza-
tions learn to guide with questions, such as “What
do you recommend?” and “How could we test that?”
This management style helps functional experts
grow into general managers, and it helps enterprise
strategists and organizations evolve from silos bat-
tling for power and resources into collaborative
cross-functional teams.

AGILE INNOVATION has revolutionized the software
industry, which has arguably undergone more rapid
and profound change than any other area of business
over the past 30 years. Now it is poised to transform
nearly every other function in every industry. At this
point, the greatest impediment is not the need for
better methodologies, empirical evidence of signifi-
cant benefits, or proof that agile can work outside IT.
It is the behavior of executives. Those who learn to
lead agile’s extension into a broader range of business
activities will accelerate profitable growth.

HBR Reprint R1605B

between their teams and the rest of the organization.
Little wonder: They are following different road
maps and moving at different speeds.

Here’s a telling example: A large financial ser-
vices company we examined launched a pilot to
build its next mobile app using agile methodolo-
gies. Of course, the first step was to assemble a team.
That required a budget request to authorize and
fund the proj ect. The request went into the batch of
submissions vying for approval in the next annual
planning process. After months of reviews, the com-
pany finally approved funding. The pilot produced
an effective app that customers praised, and the
team was proud of its work. But before the app was
released, it had to pass vulnerability testing in a tra-
ditional “waterfall” process (a protracted sequence
in which the computer code is tested for documen-
tation, functionality, efficiency, and standardiza-
tion), and the queue for the process was long. Then
the app had to be integrated into core IT systems—
which involved another waterfall process with a six-
to-nine-month logjam. In the end, the total time to
release improved very little.

Here are some techniques for destroying such
barriers to agile:

Get everyone on the same page. Individual
teams focusing on small parts of large, complex
problems need to see, and work from, the same list
of enterprise priorities—even if not all the teams
responsible for those priorities are using agile pro-
cesses. If a new mobile app is the top priority for soft-
ware development, it must also be the top priority
for budgeting, vulnerability testing, and software in-
tegration. Otherwise, agile innovations will struggle
in implementation. This is a key responsibility of an
executive team that itself practices agile.

Don’t change structures right away; change
roles instead. Many executives assume that creat-
ing more cross-functional teams will necessitate ma-
jor changes in organizational structure. That is rarely
true. Highly empowered cross-functional teams do,
by definition, need some form of matrix manage-
ment, but that requires primarily that different dis-
ciplines learn how to work together simultaneously
rather than separately and sequentially.

Name only one boss for each decision.
People can have multiple bosses, but decisions
cannot. In an agile operating model it must be crys-
tal clear who is responsible for commissioning a
cross-functional team, selecting and replacing team

50  Harvard Business Review May 2016

THE BIG IDEA EMBRACING AGILE HBR.ORG

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 permissions@harvardbusiness.org.

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 permissions@harvardbusiness.org.

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 permissions@harvardbusiness.org.