2. Scaling Agile – Doing Agile Right




Saab’s aeronautics business has more than one hundred agile teams operating across software, hardware, and fuselage for its Gripen fighter jet, a $43 million product that is daunting in its complexity. At 7:30 a.m. each front-line team holds a fifteen-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. Saab 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. As we noted earlier, the product that emerges from all this has been deemed the world’s most cost-effective military aircraft.

SAP SE, 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-focused 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 pull from the organization,” said Sebastian Wagner, who was then a consulting manager in that group.1 Over the next two years, the company rolled out agile to more than 80 percent of its development organizations, creating more than two thousand 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.

USAA has several hundred agile teams up and running at this writing and plans to continue adding them. The company—a financial services firm specializing in serving American military personnel—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 profit and loss statement (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 member-focused, cross-organizational teams to get much of the work done. USAA 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.

Over the past decade, leaders who experienced or heard about agile teams began 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 agile improve corporate performance as much as agile methods improve individual team performance? Companies as diverse as 3M, Amazon, Bosch, Dell, Facebook, Google, Haier, ING, Lego, Microsoft, Netflix, PayPal, Royal Bank of Scotland, Riot Games, Salesforce, Spotify, and Target have all increased the scale and scope of their agile teams. We have worked with and studied many such enterprises. Though their results are generally impressive, the differences in companies’ approaches, outcomes, and even definitions of scaling agile are striking.

What Does It Mean to Scale Agile?

One definition of scaling agile is simple: add more agile teams. Increase their number to fifty, one hundred, or more. Widen the scope of agile, so that teams are functioning in several different parts of the organization. Learn to use teams of teams to tackle very large projects. We have seen many different examples of this kind of scaling, and most commentary about scaled agile focuses on it. We refer to this as agile at scale, and it describes the experience so far of the typical large organization.

But there is another definition of scaling agile, which for most companies is still on the horizon. We call it creating the agile enterprise, and in some ways that’s what this book is about. Agile at scale focuses on improving the performance of agile teams while allowing bureaucracy and innovation efforts to coexist. Agile enterprises, in contrast, focus on creating agile business systems: they transform bureaucracy and innovation efforts into symbiotic partners that collaborate to deliver better results. The chapters that follow will discuss in detail the question of how far and how fast to proceed, along with the many changes in behavior, processes, and operations that are required to create an agile enterprise. In those chapters we’ll try to cover everything from reshaping IT and changing the budget process to revamping the company’s talent management and compensation system. In this chapter we have a more modest but equally important objective. We want to provide an overview of what’s involved in creating an agile enterprise and contrast it to the more modest ambition of doing agile at scale. We also want to examine why a company might want to embark on such an ambitious and sometimes perilous journey.

Agile at Scale

A company that pursues agile at scale is likely to remain bureaucratic in its fundamental approach to business. Typically, the customer the company is aiming to satisfy is the shareholder. The primary objective is to launch enough agile teams to improve financial results. To ensure that the program is profitable, management may combine cost-cutting measures, including layoffs, with support for more agile teams. A program management office typically drives the transformation, just as previous task forces drove other transformation initiatives. The program office’s job is to change people’s behaviors—installing agile teams, promoting the supporters, and fixing or firing people who actively resist the transformation. Typically, too, the executive team takes responsibility for keeping agile teams on track and on budget. After a couple of years, there will be many more agile teams, and these teams will likely coordinate among themselves quite effectively. Yet they will almost certainly be working within a bureaucratic system of corporate management, operations, support, and control—a system that runs pretty much as it has for decades.

Earlier, we identified some of these practices as pitfalls to avoid—and they are, if you want to create a true agile enterprise. But agile at scale doesn’t always go disastrously wrong, and for some companies it may be the right choice. Adding dozens of agile teams is manageable within traditional governance processes, and creative workarounds can overcome most obstacles. Senior executives can control the work of a few dozen agile teams without destroying the teams’ performance or morale. Since agile teams almost always perform better than traditional project teams, team results usually improve. Still, there are serious risks to this approach. Over time, nonagile parts of the organization may escalate their complaints. People in these units may feel that agile teams are stealing the best people, pilfering money that could be used in their own functions, disregarding budgeting procedures, endangering good management practices, and in general putting the company at risk. The resultant discord may force the organization to retreat to more conventional ways of doing things, sacrificing whatever gains have been made. There is an opportunity cost as well: a company that limits itself to agile at scale gives up the potential gains of creating an agile enterprise.

But the most difficult problem—and one that is likely to be counterintuitive—is this: even though agile teams may develop innovations better and faster than ever before, leaders are likely to find that the company’s overall innovation velocity is not improving. When they investigate that problem, they uncover the concept of flow efficiency.

The time it takes an agile team to release an innovation is determined by two factors, the time required to work on the innovation and the time spent waiting on others. Waiting times include delays caused by operating processes such as strategic planning calendars, decision approval processes, budgeting and funding cycles, software release schedules, legal or regulatory constraints, people allocation processes, and dozens of other factors. A company’s flow efficiency is calculated by dividing work time by the sum of work time plus wait time (see figure 2-1). Empirical data shows that the flow efficiency for most companies is seldom better than 15 or 20 percent. So even if the speed of agile work improves by one-fifth, the enterprise’s overall innovation velocity could improve by only 3 or 4 percent. That’s a barely noticeable difference. Moreover, when companies fire operating and support people to pay for agile teams without reinventing business processes, it leaves fewer people to do the same amount of work. That leads to slower speeds, longer queues, longer waits, and more work in process. To make matters worse, managers are likely to be desperate for ways to improve utilization and reduce cost, so they fill the wait time by giving people additional projects. This leads to multitasking, which increases switching costs, reduces productivity, exacerbates wait times, and further slows development cycles. In the end, the speed of innovation can actually decline.


Flow efficiency is seldom better than 15–20 percent for most companies

Data source: Daniel Vacanti, author of Actionable Agile Metrics for Predictability: An Introduction, and David J. Anderson, coauthor of Kanban Maturity Model: Evolving Fit-for-Purpose Organizations.

Here’s a telling example, and a real-world counterpart to the Irresistible Snacks’ experience. A large financial services company we examined launched a pilot to build its next mobile app using agile methodologies. Of course, the first step was to assemble a team. That required a budget request to authorize and fund the project. The request went into the batch of submissions vying for approval in the next annual planning process. After months of reviews, the company 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 traditional waterfall process (a protracted sequence in which the computer code is tested for documentation, functionality, efficiency, and standardization), 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.

So how do we deal with such serious challenges? That’s the purpose of an agile enterprise.

The Agile Enterprise

Agile enterprises are more than aggregations of teams. They are carefully balanced operating models that use agile methods to (1) run the business reliably and efficiently, (2) change the business to capitalize on unpredictable opportunities, and (3) harmonize the two activities. So executives aiming to create such an enterprise approach the scaling process with a different mindset. They do not try to separate agile teams from the rest of the organization as if the two groups were enemies. Nor do they try to put every employee into an agile team. Although agile innovation teams are an essential element of an agile enterprise, they usually involve only 10 to 50 percent of employees. Most of the work and most of the people in agile systems focus on running the business—operations, support, and control functions.

In an agile enterprise, moreover, leaders view the scaling process itself as an agile initiative—in fact, as the most vital of all agile initiatives. Senior executives manage the transition as an agile team. They understand that such transitions are continuous improvement products, not projects with predictable end points or fixed completion dates. They do not view employees as subordinates and change resisters but as customers whose engagement and feedback will be critical to success. The executive team sets priorities and sequences opportunities to improve those customers’ experiences and increase their satisfaction. Leaders plunge in to solve problems and remove constraints rather than delegate that work to subordinates.

Bosch, a leading global supplier of technology and services with more than 400,000 associates and operations in sixty-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 seemed to require different approaches, and Bosch’s first attempt to scale agile unintentionally led to a divisive culture—one in which hot new businesses were run with agile teams while traditional functions were left out of the action, compromising 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 said. “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 ten 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. (We’ll have more on Bosch in the following chapters.)

Building an agile enterprise does not mean doing away with bureaucracy completely. Anyone contemplating it has to pass F. Scott Fitzgerald’s famous test of a first-rate intelligence: “the ability to hold two opposed ideas in the mind at the same time and still retain the ability to function.”2 Indeed, the organization itself needs that kind of intelligence.

On the one hand, an agile enterprise needs agile teams pursuing innovation all over the place—and by innovation, we do not mean simply the introduction of new products such as Irresistible’s proposed line of snacks. Companies need innovation in business processes, in technology, in human resources, even in finance. Agile teams could take hard looks at supply-chain procedures, HR policies, and customer-service practices.

In short, an agile enterprise is a cross-functional team. The leaders of an agile enterprise must run the business reliably and efficiently, change the business to capitalize on unpredictable opportunities, and harmonize the two activities. This view is consistent with the Chinese philosophy of duality, or yin and yang. Operations and innovations are complementary and interdependent activities that need each other to succeed. The tensions, checks, and balances are features of, not flaws in, a healthy operating system (figure 2-2). That’s why we stress the idea of balance throughout this book. Of course, the right balance will vary by industry, company, and activity within a business. Managing R&D activities for an innovation leader in robotics will demand far more change than managing mining operations for a commodity player in the gravel industry.


The yin and yang of business

Creating an Agile Vision and Strategy

Leaders aiming for agile enterprises know that a vision of the future can help to break through constraining bureaucratic mindsets. They know that an effective strategy and the priorities it imposes are essential for focusing agile teams on the right initiatives. But they also know that forecasts of the future are usually wrong, and they probably aren’t certain how far or how fast they want to proceed. (Chapter 3 examines this subject in detail.) So how can they develop and sell a vision and a strategy for achieving it without looking foolish when either or both prove to be flawed? Sadly, the most common approach is to refuse to recognize and admit such shortcomings—though replacement leaders are delighted to point them out as they step in to change course.

A better way is to think like an agile team and to create a vision in just that manner.

This process begins with the only reason any agile team exists at all: to improve performance by helping some group of customers progress toward their goals. Agile teams typically express those customer goals in the form of user stories. The simplest user stories look something like figure 2-3. More sophisticated versions look more like figure 2-4.


Simple user stories


More sophisticated user stories

With appropriate user stories in place, leaders can then explore the world through the eyes of various customers of an agile enterprise, including end-use consumers, operations employees, innovation employees, financial investors, and the external community. Here is another place where balance is essential. Over the past few decades, corporate weighting of short-term financial results has grown to unhealthy levels (and planning to achieve top quartile total shareholder returns, as so many management teams do, is guaranteed to fail at 75 percent of companies anyway). It has therefore become fashionable for agile gurus to throw financial results on the scrap heap along with bureaucracy, and to recommend focusing only on customer satisfaction. No doubt that makes for a newsworthy soundbite. But unless you’re going to give your products away for free and then close up shop, you have to balance customer satisfaction with other objectives.

The first step, then, is to develop a strategic hypothesis that can effectively balance and integrate customer solutions to build a sustainable enterprise. The next step is to show some humility. Admit that parts of the strategic hypothesis may need to adapt. This requires more than shrugging shoulders, throwing hands in the air, and declaring, “We have no clue if this will work, but it sure would be cool if it did!” Instead, leaders can describe the potential benefits of the strategy, identify the assumptions that must hold true for the strategy to succeed, and then create a prioritized and sequenced list of activities that move the organization toward that vision while testing assumptions and adapting along the way. We call this sequenced list of activities an enterprise backlog, and it is built jointly with a taxonomy of teams.

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 an enterprise backlog and a taxonomy of teams required to achieve it. The taxonomy identifies key customer solutions and the business processes and technology that support them. It then determines where to deploy teams and how to coordinate or combine the teams with critical interdependencies. The first step 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 step examines the relationships among these customer experiences and key business processes (improved checkout procedures 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 business processes that will support customer experience teams.

The taxonomy of a $10 billion business might identify anywhere from 250 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.

USAA’s taxonomy, for instance, is fully visible to everyone across the enterprise. “If you don’t have a really good taxonomy, you get redundancy and duplication,” then-COO Carl Liebert told us when we were researching this book. “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.’ ” The intent of USAA’s 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.

Wait, you may be thinking, how am I supposed to pay for all these teams? The answer, in most cases, is by curtailing unproductive innovation activities and reconfiguring continuing innovation initiatives as agile teams. Often, a taxonomy will reveal that about one-third of current innovation teams are working on things that customers don’t want or teams can’t deliver. Previous processes didn’t have any good way of putting a stop to these activities other than waiting until they ran out of budget. Agile changes that. For teams that continue, agile methods should increase productivity by at least 20 percent, sometimes substantially more. As agile teams move on to redesigning business processes and technology, further efficiencies will emerge.

Sequencing 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 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. One such was ING, which we mentioned in the book’s introduction. Bart Schlatmann, the chief operating officer at the time, reflected on the experience in an interview:

I still remember January of 2015 when we announced that all employees at headquarters were put on “mobility,” effectively meaning they were without a job. We requested everyone to reapply for a position in the new organization. This selection process was intense, with a higher weighting for culture and mindsets than knowledge or experience. We chose each of the 2,500 employees in our organization as it is today—and nearly 40 percent are in a different position to the job they were in previously. Of course, we lost a lot of people who had good knowledge but lacked the right mindset; but knowledge can be easily regained if people have the intrinsic capability.3

He is understandably putting a favorable gloss on the experience. But can you imagine the terror and trauma the initiative must have provoked in the workforce? Why start with such a risky and costly move? Such an approach emphasizes cost savings more than innovation and growth. Fostering a new way of working with people who have been fearing for their jobs—and 40 percent of whom are in new roles—gets the whole project off to a rocky beginning. And that’s not to mention the fact that the leadership team just role-modeled the exact opposite of agile values in doing so.

The fact is, 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. 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. With a vision sketch and sequenced backlog, senior executives can 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. Again, we’ll discuss the how-far-and-how-fast issue in more detail in chapter 3.

Planning for Interdependencies

One of the features of agile is that it breaks complex problems into smaller, more manageable modules. That’s one reason an agile enterprise needs so many agile teams. But coordinating and integrating those modules then becomes a central task. It requires complete transparency among teams, so that each knows what the others are doing and what the effects are likely to be. In bureaucracies, everything flows back to a central hub for direction and approvals. An agile enterprise, by contrast, must develop a network with nodes that can work with each other without a central hub. That’s why transparency is essential. Technology systems can help, but regular face-to-face communications are often necessary.

Sometimes a small program management office can also be helpful, both with coordination and as a supplement to the executive committee. But remember that the goal is an agile enterprise. A program or transformation office cannot become the agile police or get between leaders and their teams. It has to stay lean and service-oriented, watching the results of the agile teams and bringing improvement opportunities to the executive team. If the transition is as important as we say it is, the executive committee should devote substantial time to it, just as at Bosch. The program office can also be supplemented by a center of excellence related to agile, focused primarily on training and coaching agile teams. The trainers and coaches can be available to all, but they should be called in only at the request of teams that want their services.

When launching the transition, 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. 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
  • Supported by senior executives who will address impediments and drive adoption of the team’s work

Whatever the pace or end point, 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. At the beginning of its agile initiative, the advanced technology group at 3M Health Information Systems launched eight to ten teams every month or two; two years in, more than ninety teams were up and running. 3M’s Corporate Research Systems Lab got started later but launched twenty teams in three months. “Agile adoption has already enabled accelerated product deliveries and the release of a beta application six months earlier than originally planned,” said Tammy Sparrow, a senior program manager at 3M Health Information Systems.4

Harmonizing Bureaucracy and Innovation

The more teams a company launches, the more it is likely to encounter friction between agile and bureaucratic parts of an organization. In the past, people have assumed that the two elements had to be kept separate, because innovation efforts would always be squelched by bureaucracy. That’s why so many have dreamed wistfully of ambidextrous leaders, equally adept at running the business and changing the business. It’s why so many organizations established skunkworks or separate operating units for disruptive new ventures. Unfortunately, such leaders are scarce, and fledgling skunkworks often die on the vine.

An agile enterprise, however, has to create harmony and complementarity between operations and innovation, and those that are furthest along on the journey have learned how to do so. As we will see in chapter 8, for example, Amazon has built big, innovative businesses in the very heart of its existing organization; it has also structured its bureaucratic functions so that they harmonize with innovation efforts. Agile enterprises typically rely on at least three tools for bringing the two sides into sync.

One of the best ways to overcome the friction—and to set the organization on the right path—is to engage operating people in agile teams. Add some operators as full-time members of teams that need their expertise. Use others as subject matter experts that agile teams can call upon for urgent requests. Launch agile teams with lots of operators to challenge current operating standards and to redesign business processes and technology to create new standards of efficiency and quality. Build trust and collaboration among innovators and operators. Ensure that agile innovations will take hold and scale effectively in real-world operating conditions. Moreover, as operators learn more about agile values and principles, they will likely begin to explore opportunities to apply them to their own functions. The questions on the next page suggest some of the ways a company can help more people understand agile principles and put them to work. The adoption of agile values and principles throughout the organization makes the final step, synchronizing operations and innovations, much easier.

People who work in an organization’s support and control functions—the bureaucrats—can also join agile teams and take the values and some of the principles back to their own units, creating what might be called an agile-harmonized bureaucracy. Bureaucratic units may not operate as agile teams, but they can learn to be better bureaucracies. Again, the questions on the next page are good guidelines for bringing about the necessary changes. Bureaucratic leaders can develop more humility. They can show greater willingness to question the value of predictions. They can begin thinking of innovators as their customers. Once learned, agile mindsets often put down roots. When rank-and-file bureaucrats begin posing these questions of their leaders, you will know that agile is likely to flourish.

The agile concept of the sprint is also a powerful device for harmonizing the organization. Sprints offer a quick and inexpensive way to reduce wait times and accelerate adaptation. They turn big, lengthy programs into smaller batches that use rapid feedback loops with customers, internal or external. That allows people working in complex systems to quickly start, stop, or pivot their activities in response to changes or new demands. Sprints act much like clutches in synchronizing large, slow-moving gears with those that are spinning rapidly. When a company uses sprints, breakthrough innovations don’t have to be five-year gambles of the sort that terrifies bureaucrats; they become short bursts that can regularly be reviewed and adapted. Similarly, cumbersome planning and funding activities don’t have to happen in annual cycles—cycles that force innovation teams to delay their starts or postpone the death of floundering initiatives. Breaking a long, monolithic planning and budgeting process into quarterly sprints minimizes wait times and increases flow efficiency. To increase agility, companies are likely to find opportunities not only in planning and budgeting but also in performance assessments, business process reviews, structural changes, communication programs, and more.


Scaling up agile is always a challenge. The following questions will help you get off on the right foot.

  1. Where can we prudently give people greater autonomy and decision authority?
  2. Should more employees learn to create backlogs that allow them to prioritize and sequence work?
  3. How can people collect more feedback from customers?
  4. How can employees minimize work in process?
  5. Can we use regular retrospectives to identify better ways of working?
  6. Would a fifteen-minute coordination discussion each morning help us help each other?
  7. Should we encourage greater collaboration through more team-based metrics and incentives?
  8. How can we provide more performance feedback more quickly?
  9. Where can we eliminate low-value work?
  10. Where can we use experiments and incremental, iterative development?

Scaling Agile Frameworks

Before we leave the topic of scaling agile, we should review a few of the frameworks that are available for managing the task. After all, managing agile at scale requires leaders to know enough to define what they mean by agile and what methodology they are going to use. Our clients always want to know: Which methodology is best?

Unfortunately, we have no simple answer. There are dozens of agile frameworks. Certainly, it is easier to manage teams if they all use the same variety of agile, but is it necessary? Can some teams use Scrum while others use Kanban, Extreme Programming (XP), Crystal, Dynamic Systems Development Method (DSDM), or some hybrid method? As always, the answer lies in balance and trade-offs. On the one hand, to force consistency is to impose bureaucracy on agility—a slippery slope. On the other hand, there are real costs to expanding the number of agile frameworks. It raises training expense. It increases the difficulty of transferring people across teams. It interferes with sharing best practices across teams. It raises the costs of coordination and communications, and it increases the complexity of planning multiteam road maps and release dates.

Choosing an approach or two for individual agile teams is relatively easy, and Scrum is likely to be in the mix. (Full disclosure: Scrum Inc. and Scrum@Scale currently have partnerships with Bain & Company.) Scrum has ten times as many users as the runner-up framework, Kanban. Scrum has been tested and refined with tens of thousands of users for more than twenty-five years. It’s a flexible framework that combines frequently and easily with other approaches, including Kanban and XP. Scrum training materials are strong, and user tips are plentiful. Nearly all project management software and scaling systems presume their users will be running Scrum teams.

However, choosing a scaling framework is more complicated. Scaling frameworks started popping up only around 2010. Recent user surveys show that the four most popular frameworks are the Scaled Agile Framework (SAFe), “Don’t know,” Scrum of Scrums (aka Scrum@Scale), and “Internally created methods.”5 In other words, this space is still wide open, and new players continue to emerge. The latest entrants include the Spotify Model, Disciplined Agile Delivery (DAD), Large Scale Scrum (LeSS), Enterprise Scrum, Lean Management, Agile Portfolio Management (APM), Nexus, and Recipes for Agile Governance in the Enterprise (RAGE). You can see why people can get confused.

Describing all of these frameworks or recommending any one of them is beyond the scope of this book. Competitive debates among their supporters often feel more like religious wars than the type of collaborative exchange of ideas that led to the agile manifesto, and those debates will certainly not be resolved in a few paragraphs here. We have worked extensively with most scaling frameworks and can appreciate why they all have ardent fans. But prudent choices are less about which framework is the best and more about which frameworks are best suited to the specific needs of a business. So let’s briefly explore some of the strengths, weaknesses, and most favorable operating environments for three of the most popular frameworks.

Scaled Agile Framework (SAFe)

SAFe officially launched in 2011, and has had six major updates as this book goes to press. About 30 percent of companies scaling agile say they use the SAFe framework. It is by far the most detailed and prescriptive approach. First-time visitors to the SAFe website may feel overwhelmed by the volume and specificity of guidance available. (A Google site search shows 2,390 indexed pages on the Scaled Agile Framework website, compared to 41 for Enterprise Scrum.) SAFe builds on a strong Scrum foundation and offers prescriptions for four levels of scaling: teams, programs, large-solutions, and portfolios. Its core premise is that managers should divide innovation work into value streams focused on customer needs. Most value streams deploy five to ten agile teams (50–150 people), known collectively as a release train. If the value stream needs more teams, it adds additional release trains. SAFe introduces several new roles, including lean portfolio managers, epic owners, enterprise architects, solution architects, solution managers, solution train engineers, product managers, system architects, release train engineers, and business owners. It also adds a number of events and artifacts to the scaling of Scrum. Its 2018 release (SAFe 4.6) focused on strengthening five core competencies: lean agile leadership, team and technical agility, the software development practices known as DevOps and release on demand, business solutions and lean systems engineering, and lean portfolio management. (SAFe 5.0 launched in January 2020.)

SAFe’s strengths include the depth and breadth of its prescriptions, its training programs, its big-picture view of performance beyond the team level, its appeal to control-oriented executives, and its ability to coordinate interdependencies among teams. It does a nice job developing and managing a complete taxonomy of teams. Many SAFe users rave about the alignment and coordination processes known as program increment (or big room) planning that synchronize teams every eight to twelve weeks. SAFe’s weaknesses include the rigidity of its prescriptions, its limited applicability to innovations beyond technology and software development, the amount of time and expense required for planning and coordinating activities, the amount of top-down bureaucracy that carries over to scaling processes, and its lack of attention to the harmonization of support and control functions such as human resources, marketing, and customer services.

Overall, SAFe works most effectively in organizations that have a heavy technology focus combined with monolithic architectures. It works well in companies that fear ambiguity, want to preserve a significant level of top-down control, do not believe they need many breakthrough innovations, and need to synchronize a large number of interdependencies among teams. Of course, SAFe can also work where organizations have enough experience and confidence to customize the process and increase its flexibility to suit their own cultural needs.

Scrum@Scale (Scrum of Scrums)

Jeff Sutherland, the cocreator of Scrum, publicly introduced the Scrum@Scale framework in 2014. However, he is quick to point out that teams of Scrum teams have existed as long as Scrum has—about twenty-five years. Sutherland designed the Scrum@Scale framework to coordinate multiple teams with a “minimum viable bureaucracy” in what he calls a “scale-free architecture.” The system is designed to scale across the entire organization—all departments, all products, and all services in all types of organizations. Sutherland intentionally avoids adding complexity that could hurt the productivity of individual Scrum teams. Scrum@Scale simplifies scaling by “using Scrum to scale Scrum”; it expands at a sustainable pace of change as determined by the organization. Compared to SAFe, it aspires to a more comprehensive enterprise transformation with fewer prescriptive processes.

To coordinate interdependencies across teams, the framework regularly brings together the product owners of teams to discuss what teams are doing, and it brings the Scrum masters of teams to share how they are doing it. In other words, rather than bringing entire teams together for coordination sessions, Scrum@Scale brings representatives from the teams together to manage interdependencies. The framework seeks to build common values of openness, courage, focus, respect, and commitment across the entire organization, using transparency, inspection, and adaptation in the process. An Executive MetaScrum Team serves as the product owner for the entire organization, working with product owners to develop the organizational vision, set the strategic priorities, and align all the teams around common goals. An Executive Action Team serves as the Scrum master for the entire organization, working with Scrum masters to remove constraints that are impeding the progress of teams. The two executive teams use common feedback tools and metrics to connect their work.

Scrum@Scale’s strengths include its ambition to improve the agility of the entire organization; the complete consistency of the framework with successful Scrum values, principles, and practices; and reducing the layers and bottlenecks of bureaucracy with very low overhead costs. Its fans also point to its focus on reducing the time required to make decisions and to its high level of transparency, which allows teams to quickly reduce work that fails to create value. Scrum@Scale recognizes the roles of knowledge and infrastructure teams that support Scrum teams but do not formally operate as Scrum teams. The approach’s weaknesses include limited specifics and prescribed practices, few techniques for effectively coordinating among large numbers of highly interdependent teams, and limited case examples of enterprise-wide transformation successes. Companies that have been using another framework (such as SAFe) may find it difficult to transition to Scrum@Scale, and will likely decide to keep elements of previous frameworks that they find most helpful.

Overall, Scrum@Scale works most effectively in organizations that are comfortable with Scrum approaches and want to scale them in ways that reinforce fundamental Scrum values and principles. It works well when companies are comfortable with some ambiguity and would like to customize their approach to scaling. It is effective where organizations want more focus on breakthrough innovations than on top-down controls.

The Spotify Model

Spotify, the media-services and audio-streaming provider, could scarcely be clearer about its scaling model. It created the model to scale agile teams in its unique engineering organization and culture. It warns that the model is constantly evolving and should not be copied by other companies, or even by other areas within Spotify. Nevertheless, ever since 2012—the year when Henrik Kniberg and Anders Ivarsson published their paper on scaling agile at Spotify—companies have ignored Spotify’s advice, copied its engineering structure, and tried to apply it to their entire enterprise.6 The result is an upsurge of squads, tribes, chapters, and guilds, all Spotify terminology. Squads are like Scrum teams. Tribes are collections of ten or fewer squads (fewer than one hundred people) working on related areas. Chapters are groups of people with similar functional skills who work within the same tribe in matrix fashion. Guilds are informal communities of interest that share knowledge and practices.

The Spotify model is intuitive and easy to understand; it works well in Spotify’s engineering department, though it is not a significant factor in areas such as strategic planning or finance. The approach favors strong team autonomy, guided by shared ambitions. It allows teams to develop their own ways of working, encouraging flexibility with agile tools and techniques. As for weaknesses, the model is light on prescriptions. Because Spotify designed its model for a culture that already existed, it did not need to prescribe or change all of the cultural norms and ways of working that make it so effective. Many adopters of the Spotify model assume the key to success is the organization structure. In fact, the organization structure capitalizes on the trust and collaboration inherent in the company’s culture. Similarly, the model is light on developing logical taxonomies and managing interdependencies among teams, since Spotify’s teams have fewer interdependencies than at most organizations because of its modular products and technology architecture. As a result, companies trying to copy the Spotify model—but that have product lines requiring close coordination of interdependencies—often end up with tribe structures that create chaos. The model does not describe structures, roles, or decision rights for operations, support, and control functions outside of development.

Overall, the Spotify model is effective for innovation departments with cultures and architectures similar to Spotify’s. Spotify’s engineering culture has always stressed servant leadership, minimization of interdependencies among teams, autonomy, democratic decisions, and innovation over risk avoidance. Adapting the Spotify model to different cultures or different parts of the company requires sophisticated customization.

As these brief overviews demonstrate, models for scaling agile vary significantly. They are likely to succeed in different business and cultural environments. All are helpful for getting to agile at scale, but none has yet shown strong records of accomplishment in creating agile enterprises. Until they do, companies will need to combine, customize, and augment the frameworks to address their unique situations.


  1. There are major differences in both mindsets and methods between companies that set out to create agile enterprises and those doing agile at scale.
  2. Adding dozens or hundreds of agile teams is sufficient to do agile at scale. But if the dominant mindsets and operating systems remain bureaucratic, they will limit agile’s potential.
  3. Creating an agile enterprise requires balancing and integrating operations with innovation. Agile enterprises run the business reliably and efficiently, change the business to capitalize on unpredictable opportunities, and synchronize the two kinds of activities.
  4. The best way to manage the transition to an agile enterprise is to manage it like any other agile team.
  5. Companies that create agile enterprises 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.