8. Doing Agile Right – Doing Agile Right

 

8

DOING AGILE RIGHT

When we set out to write this book, we asked each other what we hoped readers would do differently after reading it. What was the customer problem we were trying to solve? After all, there are countless books, articles, and blogs on agile in the public domain. Why would the world need another one?

The answer was easy. We really do want agile to become a valuable and practical tool rather than one more frustrating fad. We believe that agile mindsets and methods can make people in an organization far happier and more successful. We want readers to look back on their agile transitions in five to ten years with a sense of pride and fulfillment rather than embarrassment and disappointment. Our concern is that the faddish misuse of agile will tarnish the whole idea. If fanatics try to correct one kind of imbalance by swinging all the way to its opposite—or if authoritarians use it as one more club to bludgeon people into obeying orders even faster than before—agile will soon join quality circles and business process reengineering on the aforementioned scrap heap of management manias.

And a scrap heap there is. Over the last twenty-seven years, our firm has collected candid feedback from nearly fifteen thousand executives in more than seventy countries to understand the truth about management tools of all sorts. This is probably the world’s largest and longest running database on the subject, and it has allowed us to trace the popularity and effectiveness of scores of such tools over time. We have watched tools such as knowledge management, quality circles, business process reengineering, and Lean Six Sigma become popular quite suddenly, then fall out of fashion. This happens most often when tools are overhyped and misapplied to problems they were never designed to solve. Usage grows faster than satisfaction, as in that old cigarette commercial that asked whether you were “smoking more now and enjoying it less.” Eventually, managers realize that the fad is no cure-all, that it has actually caused them to neglect other aspects of the business, and that analysts are now beginning to ridicule those who naïvely succumbed to the fad. At that point, usage falls fast.

Bain’s obsession with the truth about tools has proved especially helpful with agile. The studies listed in appendix C support the idea that agile is no fad. So does our own experience with clients. We and our colleagues founded the Agile Enterprise Exchange to help senior executives share candid insights about their own experiences. Operating under the Chatham House Rule, a group of more than forty senior executives from a wide range of industries, geographies, and business functions agreed to meet regularly, network continuously with each other, and openly share insights into their successes and challenges.1 This exchange is helping agile to become a valuable and sustainable trend. Much of their collective wisdom has shaped this chapter, and we are grateful to the members who are generously helping each other and others to do agile right.

Some of the guidelines for avoiding faddishness—for doing agile right—are simple and obvious, and we have mentioned them repeatedly in the book. It shouldn’t generate fear, for example. Contrary to popular opinion, people don’t fear all change. Most of us love vacations, better beauty products, new movies, and so on. What we fear is loss. As the psychologist Daniel Kahneman has shown, fear of loss has twice the psychological power of hope for gain. An agile transition should not provoke fear of losing control over operations, or of losing functional expertise, or of giving up current ways of working before learning that new ways are better. You can avoid fear through genuine collaboration and by iteratively prototyping, testing, and adapting proposed changes under real-life operating conditions.

Remember, too, that agile is a tool, not a strategy. A chainsaw is a wonderful tool for removing trees from fallen power lines or harvesting lumber to build a house. But no company needs a chainsaw strategy or a chief chainsaw officer. And a chainsaw is not the best tool for slicing tomatoes or performing heart surgery. Doing agile right means using agile as a tool in service of a strategy to improve business performance. It also means using the tool only where it’s appropriate. Michael Porter has rightly said that the essence of strategy is choosing what not to do. We likewise believe that doing agile right means choosing where not to use it. Agile methods are designed to develop innovative solutions where what to deliver and how to deliver it are vague and unpredictable. It isn’t the best way to manage routine operations, which require strict adherence to standardized operating procedures.

We also want to repeat once more that agile isn’t for abrupt cost cuts. Innovative business processes eventually enable people to do more work with fewer resources. But agile is not a great method for rapidly removing 30 percent of employees. It is sometimes sold that way, because faddists have learned that bureaucrats take to cost reduction tools as felines take to catnip—especially if the tools promise to deliver growth and conceal previous management mistakes. But we hope we never hear statements like this: “We are transforming from a gravel company to a technology company, and now that we’re accelerating growth by adopting agile methods, we have no choice but to lay off 30 percent of our amazing people.”

Observing simple guidelines like these lets you start the journey productively. But doing it right requires more than just avoiding the obvious potholes. An agile journey really is like a triathlon: it can be a lengthy and sometimes arduous trip. So in the rest of this chapter we want to do two things. One is to recount the experience of a company—Amazon—that has created and sustained its own remarkably successful version of agile over a period of years. It’s an inspiring story not because Amazon is an ideal company that should be copied—you already know what we think about copying—but because Amazon has continued to be extraordinarily innovative over a long stretch of time in a wide variety of businesses, and it’s worth learning how they do it. The other task for this chapter is to distill from our own research and experience a handful of rules for the agile road. These rules won’t just help you avoid the potholes; they will actually help you reach your destination.

Agile at Amazon

If the purpose of scaling agile is to create and sustain superior results by running the business reliably and efficiently, adapting the business to capitalize on unpredictable opportunities, and harmonizing the system across all these activities, then it’s hard to write a book on the subject without examining Amazon’s journey. Amazon’s system developed over time. The company more or less invented it on its own, though CEO Jeff Bezos is famous for adopting good ideas from anyone. The system is messy and wouldn’t look perfect to a purist. But it works—and it is instructive. It is also a powerful argument against those who would consider agile a fad.

As everyone knows, Amazon is a business phenomenon. An investment of $1,000 shortly after its IPO was worth $1.35 million by mid-2019. Magazines have lauded the company as most innovative, most admired, and so on. It often leads the American Customer Satisfaction Index for internet retail. It is an innovative marvel that has integrated forward and backward while adding new channels, new geographies, new categories, and new businesses. All this, of course, makes executives skeptical of its worth as an exemplar. “Who doesn’t know about Amazon?” our clients sometimes tell us. “They were born agile. There’s a news story every day about how they focus on the long term, take big risks, and kill or buy their competitors. I’m sick of hearing about Amazon. We have to operate in the real world. We have to make money and pay taxes. We can’t hire the people they hire. We don’t have their technology, and we certainly don’t have their CEO.”

But we’re not suggesting that anyone should cut and paste the Amazon strategy. Nor are we suggesting that other companies try to transplant individual components from the Amazon system into their own. And we’re certainly not suggesting that Amazon is some sort of perfect company, to be emulated in all respects. Indeed, that’s what makes it such an insightful example.

Look at all the negatives. Amazon’s culture does not provide the psychological safety that Google and other agile proponents recommend. Amazonians describe their culture to us as “confrontational,” “intellectually intimidating,” “combative,” “bruising,” and “Darwinian.” The stack ranking and firing of good people at the wrong end of a forced bell curve is emotionally draining. People work very hard at Amazon. Finding a sustainable work/life balance can be difficult. Amazon does not talk about a grand social purpose, which many experts believe is crucial to motivation; indeed, it has been roundly criticized for its treatment of low-wage workers and its heavy-handed approach to local governments over issues of taxation and location incentives. Even internally, funding off-cycle ideas is harder than it should be in an agile enterprise. CEO Jeff Bezos and other senior executives can be notoriously demanding micromanagers. Product release dates and required features are more firm than agile practitioners typically recommend. Insiders tell us that working on failed initiatives is not nearly as fun as Bezos would lead outsiders to believe.

Any one of these weaknesses might, theoretically, impede agile operations. Collectively, they could be crippling. Yet Amazon’s agile system powers ahead. How does that happen? The people we have talked to—and we’re fortunate to have many close relationships with executives who have worked at all levels of Amazon over the years—describe a balanced system of strengths and weaknesses that have evolved over time to work together in a uniquely Amazon way. It’s about the system, not the individuals. Thousands of Amazonians rotate in and out of the company all the time, so other companies can and do hire them. Amazon people are neither demigods nor demons. They are real people who accomplish extraordinary results in the Amazon system.

Jason Goldberger is one such person. Goldberger arrived at Amazon as a senior buyer in 1999, six years out of college and two years after the company’s initial public offering. Over the next eight years, he would advance to divisional merchandise manager, senior category manager, and eventually to general manager. He would battle through the dot-com crash from 2000 through 2002, when Amazon’s stock price plummeted by 95 percent. He would also participate in the evolution of Amazon’s unique agile system. That system helped the company rebound during his time there, pushing revenues from $2 billion to $15 billion, employees from 7,600 to 17,000, and the stock price from its 2001 low to a 1,300 percent increase.

Like other observers and participants, Goldberger found the most striking characteristic of Amazon’s system to be its obsession over customers. He had worked at other retailers—Federated Department Stores, QVC, and Linens ’n Things—so he understood what terms like customer centricity were supposed to mean. But it was different at Amazon. The company was crazy, nuts, loony about customers. Executives would routinely wake up software engineers in the middle of the night to solve customer problems. They would readily sacrifice short-term profits for the long-term goal of delighting customers. Amazon tracks some five hundred metrics, and nearly 80 percent of them relate to customers. Bezos frequently leaves one seat empty at a conference table for “the most important person in the room.”2

Every Amazon executive we know agrees with Goldberger that Amazon takes its mission to be “Earth’s most customer-centric company” far more seriously than other companies may imagine. It enforces a strong set of operating principles to reinforce this obsession.3 The principles include ownership (think long term on behalf of the entire company); invent and simplify (look everywhere for new ideas); be right a lot (build strong judgment from diverse perspectives); learn and be curious (constantly improve); hire and develop the best (raise the performance bar with every hire and promotion); insist on the highest standards (even if others think they are unreasonably high); think big (communicate a bold direction); have a bias for action (speed matters); be frugal (accomplish more with less); earn trust (be vocally self-critical); dive deep (stay connected to details); have backbone (respectfully challenge and avoid compromise); and deliver results (never settle).4 Most companies have platitudinous principles, and most employees learn quickly that those principles don’t mean a thing. The executives we talk to say that Amazon is different. The principles are the criteria Amazon uses to hire builders and the principles by which it lets them build. They are how the company runs its business. Love them or hate them, you will live or die by these principles at Amazon.

Genuine customer obsession sets a strong foundation for agility. Still, caring without creating strong capabilities won’t build an agile enterprise.

Goldberger, for example, was a merchant. But he learned quickly that he couldn’t really take care of customers the way Amazon expected him to unless he learned a lot more about technology and supply chains. So he worked side by side with operations experts. He researched discussion topics that he didn’t fully grasp. He came to understand and appreciate functions that seemed foreign in previous jobs. He describes this learning process as being common among Amazonians.

Starting around 2000, when Amazon had nine thousand people, Goldberger noticed that the company began thinking of its technological capabilities in new ways. It started to break large, monolithic systems into smaller service modules called microservices. Each microservice would be built as an independent, flexible, reusable, and replaceable subsystem that would communicate with other microservices through standard connections known as application programming interfaces. This approach improved efficiency. Building small modules made it faster and easier for autonomous teams to develop, test, deploy, and scale their services. Equally important, it improved Amazon’s ability to quickly identify, stop, and replace any microservice that was not working properly. Microservices were a counterbalance to the sharp elbows that could have made widespread collaboration difficult. They made cross-organizational collaboration and experimentation far less risky.

These service-oriented architectures were, and are, a key component of Amazon’s agile system. “Most people think that the most valuable contribution of service-oriented architectures is the ability to release innovations faster,” Goldberger told us.

Yes, it does that. But it also lets you stop ineffective innovations faster. If you tell people to innovate without making mistakes, you will kill innovation. But if you tell people to innovate and not worry about mistakes that are quickly reversible, you free them to test and learn in more agile ways. Jeff talks about two-way doors, where you can always come back if you don’t like what you see on the other side. Service-oriented architectures enabled thousands of two-way doors.

One of the earliest applications of this architectural philosophy was Amazon Marketplace, a platform that let Amazon sell third-party inventories on its website. Amazon had tried twice before—with Amazon Auctions and zShops—to offer competitive alternatives to eBay. Both flopped. But service-oriented architectures enabled Amazon to create single detail pages that seamlessly integrated third-party providers into the core Amazon shopping experience. Now the company had turned a me-too idea into a superior offering. Today, there are more than five million marketplace sellers on Amazon’s platform, accounting for 53 percent of its retail units sold.

The philosophy also led to the creation of Amazon Web Services. In 2003, two members of Amazon’s website engineering team, Benjamin Black and Chris Pinkham, began working on ways to scale the company’s technology infrastructure faster and more efficiently to keep up with the company’s skyrocketing growth. They wrote a memo describing the cloud-based architecture and analyzing the potential to sell virtual servers as a service. Although Amazon’s board feared the idea was too far from the company’s core retail concept, Bezos liked the way it could help anyone, including students in dorm rooms, to start new businesses. Amazon officially relaunched Amazon Web Services in 2006. Since then, it has created a new strategic engine for Amazon, providing strong revenue and profit growth for the company and contributing key breakthroughs in cloud computing for the world.

Despite the entrepreneurial values and principles that permeated all of Amazon, its organizational structure for a long time remained very much like that of most companies. In early 2002, Bezos decided to change that. He formally proposed scaling agile teams, though he called them two-pizza teams and was largely indifferent to the specific methods or frameworks they used. His idea was to restructure the whole enterprise around small, autonomous teams that would continuously tackle the biggest problems in more agile ways. Each team needed to have no more than ten people—small enough to feed with two pizzas when members were working late into the night. The teams were free to compete with each other. Each one would create a fitness function, an equation that would help themselves and others (especially Bezos) to measure their progress.

Goldberger recalls how eager people were to work on these pizza teams. “Pizza teams are brilliant. They strip away unnecessary hierarchy and let people who are closest to the work collaborate directly with each other and with customers. Most people I knew wanted to try them. Those that did try them got a pizza icon by their name in the online directory, which was a badge of honor.”

Two-pizza teams took off and stuck in innovative departments such as technology, but not in routine operations such as accounting. The fitness functions never gained much traction anywhere and were mostly ignored. Amazon did not end up restructuring the whole enterprise around two-pizza teams, but the teams have become the primary mechanisms for attacking innovative ideas. Amazon runs thousands of them, and they have become a core part of the culture.

In 2004, a decade after the company’s founding, Amazon also changed its approach to funding innovative initiatives and running proposal discussions. Today, every plan and every proposal—especially those for two-pizza teams—begins with a six-page memo. The memo opens with a visionary one- or two-page press release of the benefits the initiative would create for customers. Very much like the user stories in any agile backlog, mock press releases describe targeted customers, the benefits they are seeking, the frustrations they have experienced with previous solutions, and the advantages of the new Amazon approach. The proposal also includes at least four or five pages of frequently asked questions (FAQs)—starting first with the hardest ones—about how the innovation works. Frequently the memo includes exhibits and rough diagrams or pictures depicting customers using the solutions. Although these proposals were originally dubbed six-page memos, many executives now refer to them as “PR/FAQs,” and many memos run fifteen pages or more.

Goldberger still remembers his first six-page proposal. He had prepared a PowerPoint presentation but learned one week before that it needed to be a six-page memo. “It was a rough and tumble discussion,” he says. “It’s a little awkward to sit there for thirty to sixty minutes while everyone reads the memo. Then the questions start flying in random order. If you don’t know your stuff, you will be exposed within minutes. Bezos can trip up a canned answer in a heartbeat. You had to be an expert, not just a competent presenter.” What Goldberger appreciated most about the six-page memos, however, was how they reinforced Amazon’s mission about customer focus. “What I remember,” he told us “is how they made me feel. They made us all think about what we were really trying to do. Working backward from the customer forces you to think about every activity as a service to the customer. And since many of the proposals are focused on improving internal business processes and technology, it makes you think about everyone you work with as a customer. I felt like I had a real responsibility to them, and I developed deep commitments to them.”

Other executives agree with Goldberger, including Nadia Shouraboura, an executive at Amazon from 2004 through 2012. “Each piece of Amazon’s system balances and reinforces other parts of the system,” she told us.

The core of the system is obsession over customers. Amazon might micromanage, but it’s usually about customer passion. Personally, I prefer this passion to indifference. Executives don’t tell people what to do. They say, “You are responsible for this customer, and this customer has this problem. What are you going to do about it?” Six-page memos secure resources for innovation by working from the customer backward. During my time at Amazon, I wrote hundreds of six-page memos and read thousands more. Those discussions do not waste time on what presenters want to say. They spend every possible minute on reinventing customer experiences. Then two-pizza teams focus on how to develop creative solutions for the customers. Two-pizza teams are self-sufficient, fully committed and empowered. Each team is what Amazon calls “single-threaded,” meaning they do not multitask. One team, one problem. Service-oriented architectures enable those teams to collect customer data from anywhere, and test solutions anywhere, without waiting for approvals from hierarchies. The system works to make everyone better.

Amazon continues to expand and refine its tools for scaling and improving agility. Will it succeed in the future? Bezos doesn’t know, and neither do we. In November 2018, he told his employees, “Amazon is not too big to fail. In fact, I predict one day Amazon will fail. Amazon will go bankrupt. If you look at large companies, their lifespans tend to be thirty-plus years, not a hundred-plus years.” The key to postponing that demise is for the company to obsess over customers and to avoid looking inward. “If we start to focus on ourselves, instead of focusing on our customers, that will be the beginning of the end. We have to try and delay that day for as long as possible.”5

The dangers of a complex system are real, even for Amazon. Regulatory changes could force breakups. Growth could slow, which would affect the stock price and the compensation of star players. Micromanagement and bureaucracy could increase, smothering innovation. Recent declines in customer satisfaction could turn into long-term trends. But we know of few companies working harder to continuously balance and harmonize its system to adapt to unpredictable markets than Amazon.

The Rules of the Agile Road

Most of the companies that succeed at agile, including Amazon and the others named in this book, seem to develop an unusual set of capabilities. These capabilities enable them to implement agile without falling into the traps and faddishness that plague so many other would-be agilists. Four are particularly important—so important that we think of them as the rules of the agile road, the skills and attributes that will take you where you want to go.

1. Learn to Love Agile Teams—and Then Create Your Own

You can’t consider doing agile at scale if you can’t do agile at all. As we have noted, agile teams are tools used to develop innovative solutions when what to deliver, how to deliver it, or both are vague and unpredictable. Their primary purpose is to change the business through innovation—developing new products, services, or customer experiences (for external customers); improving processes to help operations folks deliver solutions to those external customers; or improving the technology that underlies those processes. Teams are at the heart of agile.

People sponsoring or participating in agile teams should not only be familiar with agile practices; they should also understand why the teams do everything they do. The teams are self-governing because autonomy increases motivation, puts decisions in the hands of people closest to customers and operations, and gives leaders time to focus on enterprise strategies that only they can do. The teams are small and multidisciplinary because small size improves communications and productivity, and because including a variety of disciplines increases creativity, reduces interdependencies with other teams, and accelerates decision making. Teams are dedicated to a single task because multitasking makes people stupid, slows development cycles, and increases work in process. Effective agile teams do not blindly follow rules. They understand why they are doing what they are doing, continually search for better ways to do it, and share their insights with other teams.

Wherever they are deployed, agile teams should create irrefutable results. Great results build enthusiasm for expanding the scale and scope of agile. Great results attract star players. As more people join teams, they gain confidence. They learn the value of prioritization. They begin challenging the assumptions behind predictions. They collect direct feedback from customers rather than from managers, limit work in process, and speed up decision making. They figure out how to eliminate low-value work and how to continuously improve their own ways of working. They then carry this confidence back to their functional departments. The agile teams learn to identify impediments to their speed and success, and the leadership team learns how to remove these impediments. Agile teams are pulled, not pushed, into the organization.

As you learn to love agile teams, you will want to create your own team, one that is committed to working together according to agile principles. If you are a C-level executive, this may be your executive leadership team or the senior managers of the business unit or function you lead. If you are a junior executive, it may be a group of people in your department. Maybe it is a team currently working on innovation projects in more traditional ways. Or perhaps it is a group of people who do similar work, but have never considered doing it together as an agile team.

Start by getting your team to read and discuss this book together. Debate the concepts. Work with team members to study and experiment with various aspects of agile methods. Find out whether there are effective agile teams somewhere in the company that you can visit and observe. Ask them frank questions about what they like and dislike about agile approaches. Ask your team if they would like to pursue an opportunity or two in agile fashion. Consider joining a training program together to build a common foundation of capabilities. Work together to build sustainable agile habits. Write your own personal version of an agile manifesto.

When one of us (Darrell) was first learning agile principles and practices, he figured he should practice them himself. For each value in the agile manifesto, he picked one simple behavior to change and set promptings to trigger that behavior. For example:

  • Work in ways that make humans happy and successful.  When he felt stressed, he determined to express sincere appreciation for the work of at least one person.
  • Break large tasks into small steps and test solutions with working models.  When confronted by an opinion different from his own, he decided to ask, “How could we test that?”
  • Simplify and sequence activities to focus on the most valuable customer benefits.  When asked to do work with little or no value to customers, he committed to describe what he needed to do instead and to explain the extraordinary value that would be forfeited by delays.
  • Welcome and celebrate learning.  When his predictions or opinions turned out to be wrong, he vowed to laugh about them with others and change course.

What happened? Here’s his account:

I found that the most enjoyable change was the first. Expressing gratitude made me happier and improved teamwork. The hardest change was the last. For more than a year, I wrote down my hypotheses and predictions, then tracked their accuracy using something called a Brier score. Embarrassingly, I found that I was wrong far more often than I expected. Along with a heavy dose of humility came the realization that considering the opinions of others couldn’t be much riskier than relying on my own. I also feared that laughing at so many mistakes would undermine my credibility. Instead, it led to more collaborative ways of developing hypotheses, better results, and greater confidence.

As these behaviors became easier, he started adding others. He felt happier and more in control. He set a better example for his teams and developed lifelong habits that would never slip back to bureaucratic behaviors.

2. Master Agile at Scale—but Envision an Agile Enterprise

Agile at scale, remember, refers to widespread proliferation of agile teams, even when agile principles have not spread to the rest of the enterprise. Its most obvious benefit is that it expands the quality and quantity of innovation. It infuses a spirit of testing and learning into the business, encouraging employees to identify opportunities for improvement in everything they do. Moreover, it can increase innovation without increasing costs. Leaders who inventory current innovation activities often find themselves astonished by how many projects there are, where those projects are, what they are doing or not doing, who is working on them (and what else those people are working on), how effectively they are coordinating, and how well they are turning out innovations. The executives typically find that a third of these teams could cease operations tomorrow and never be missed. Stopping those projects outright creates room and resources for more valuable opportunities. Among the other two-thirds, some teams will be working on vital initiatives but will be struggling and discouraged. These are good candidates for agile makeovers. Sometimes leaders must reconfigure the teams to add the right skills and mindsets, but the subsequent improvements in costs and results can create striking success stories and enthusiastic ambassadors.

Another benefit of scaling agile may be even more important. The proliferation of teams teaches people how teams of teams can work within familiar bureaucratic structures, such as matrix organizations and hierarchies. Cross-functional agile teams are by definition matrix organizations. As long as the people to whom team members report understand agile mindsets and methods, the joint accountability doesn’t hamper performance. The same is true for hierarchies. Teams of agile teams, and teams of teams of agile teams, create reporting structures that look a lot like hierarchies. Yet product owners are not traditional bosses: they do not predict, command, or control the work of teams. Nor do they assign tasks to individuals or set deadlines—the team works together to do these things. Despite all the criticisms of hierarchies, they, too, work well with agile mindsets and methods. Mastering agile at scale not only improves innovation, it also helps operations to run in ways that are more humane.

Mastering agile at scale requires that leaders know enough to define what they mean by agile. As we noted in chapter 2, there are dozens of agile frameworks. When most of our clients examine the options, they typically choose two or three frameworks (for example, Scrum, Kanban, and a scaling framework such as Scrum@Scale or SAFe). They then customize these frameworks to fit their company’s culture, harmonize the core concepts and terminologies, and encourage teams to adapt.

Though agile at scale is a great start, doing agile right ultimately requires both agile teams and agile systems—an agile enterprise. We know that these terms are frequently confused because both involve doing agile. But the differences are important. Agile at scale focuses on improving the performance of agile teams, allowing bureaucracy and innovation to coexist. Agile enterprises focus on creating agile business systems, transforming bureaucracy and innovation into symbiotic partners that collaborate to deliver superior results.

Let’s put the concept of an agile enterprise concept under a microscope. A detailed definition might look something like this: Agile enterprises create balanced systems that efficiently adapt to changing customer opportunities in order to deliver superior results. Each element is meaningful, starting with the thing itself. In an agile enterprise, executives do not focus on optimizing the performance of individual teams. They focus instead on improving the performance of the entire business system. Such a system is balanced: it runs operations reliably and efficiently while also innovating to capitalize on changes. Stable operations and flexible innovation are not enemies. They are complementary, interdependent, mutually beneficial capabilities that need each other to survive.

The other elements are equally significant. Agile systems efficiently adapt. The trick in successful evolution is to preserve the characteristics that work well while quickly and efficiently changing what needs to change. Iterative testing with rapid feedback loops is the only way to adapt without creating painful, unintended consequences. And what do the systems adapt to? Changing customer opportunities. Agile enterprises don’t merely study the customer environment to identify and react to changes in customer preferences. As at Amazon, they proactively change the environment. They obsess over discovering, creating, and capitalizing on solutions that help customers to achieve satisfying goals and force competitors to follow their lead or face extinction. This process can and often should include disruptive innovations—products or services that a company’s existing customers may not immediately value but that others might.

Finally, agile enterprises deliver superior results. The only valid purpose for increasing agility is to improve results—customer results (buying behaviors, market share), financial results (revenue growth, cash flows), employee results (employee quality, effectiveness), and societal results (human rights, environmental sustainability). There is nothing inherently virtuous in agility or, for that matter, nothing inherently evil in bureaucracy. They are only tools in the service of a strategy for achieving results.

Even if you are not currently planning a transition to an agile enterprise, we recommend taking a few weeks to explore what such a transition might look like. How many teams could we have? What would they do and where would they report? How much additional value could the enterprise create? How could we better harmonize bureaucracy with innovation? What would be the greatest impediments and risks to achieving such a vision? How far could we realistically go, and how fast could we plan to get there? Envisioning an agile system in this manner encourages holistic, integrative thinking. It creates an estimate of the value at stake, and it fosters greater alignment on the ultimate destination, which helps to guide strategic decisions.

There are other benefits as well. Envisioning an agile enterprise can increase commitment, energy, and the courage to take actions. It can prevent the organization from doing things that would ultimately make enterprise agility harder or impossible. It can facilitate discussions on how far toward an agile enterprise the organization wants to go, how fast it wants to get there, and how to sequence action steps. It can help the executive team identify questions that need to be answered, risks that need to be addressed, and tests that could alter decisions.

For all that, it can also lead to dangerous extremes. One extreme is, “I want it all, and I want it now.” The other is, “I’m paralyzed by the prospects.”

We have discussed the dangers of big-bang, all-at-once agile transitions. Executives who want it all right now typically use bureaucratic transformation teams to force agile on the organization. They almost always copy someone else’s agile model, convince themselves that it has all the answers, and go for it. The results are seldom good. In a complex system like a business, the relationships among causes and effects are often delayed, and may lead to unintended consequences. Remember Prohibition: How many people expected that the amendment banning alcohol sales in the United States would also increase the wealth and power of organized crime, lead to rising use of hard drugs and dangerous homemade brews, decrease tax revenues, criminalize millions of previously law-abiding citizens, reduce trust in authority, and overburden the legal system? And still it took thirteen years for the United States to reverse course.

At the other extreme lie executives who are paralyzed by the complexity of an agile enterprise. Yes, the pain of overextended bureaucracy is harsh, and the vision of an agile enterprise is enticing. But where to begin? There is so much to change. If we don’t do it perfectly, we could end up in a worse position than we are today. Fear of loss kicks in. Nothing significant happens for years. Then, suddenly, the management team realizes that they are in deep trouble. Now there is no time for delay or testing and learning. “We need it all, and we need it now.” Like yo-yo dieters, such companies are apt to lurch back and forth from one extreme to another.

3. Use Agile Innovation to Get There

At the beginning of an agile journey, the hardest truth for many executives to accept is that where to go and how to get there are not just unknown, they are unknowable. Even experienced agile practitioners can’t predict with any degree of confidence how agile the business system should ultimately be or how to get from here to there. This distressing prospect challenges many leaders’ most fundamental assumption about how they add value. Who could argue against the philosophy of (“Neutron”) Jack Welch? “Good business leaders create a vision, articulate the vision, passionately own the vision, and relentlessly drive it to completion.”6 In other words, leaders predict, command, and control.

The problem is that predicting, commanding, and controlling don’t work in vague and uncertain conditions. In Amar Bhidé’s study of entrepreneurial companies, he found that two-thirds of the companies moderately or significantly altered their initial visions for the enterprise before they achieved success. In his words, “Entrepreneurs revise their hypotheses rapidly through a series of experiments and adaptive responses to unforeseen problems and opportunities.”7 Famed venture capitalist Fred Wilson, cofounder of Union Square Ventures, discovered a similar pattern. “Of the twenty-six companies that I consider realized or effectively realized in my personal track record, seventeen of them made complete transformations or partial transformations of their businesses between the time we invested and the time we sold. That means there’s a two-thirds chance you’ll have to significantly reinvent your business between the time you take a venture capital investment and when you exit your business.” Wilson further found that of the investments he considered failures, 80 percent failed to transform.8

As we noted earlier, scholars such as Daniel Kahneman suggest that leaders’ predictions are about as accurate as the toss of a coin.9 So if leaders’ predictions are just as likely to be wrong as right, then attempts to command and control provoke a flood of humbling questions. What if my predictions are no better than those of people closer to our customers and the operations that serve them? What if testing and learning with customers actually leads to faster and better decisions than I am making? What if the time it takes to get on my calendar and wait for me to make decisions is doubling or tripling our cycle times and lead times? And so on.

Remember: Agile was designed to create innovative solutions when what to deliver and how to deliver it are vague and unpredictable. This is a perfect description of the journey from an overextended bureaucracy to an agile enterprise. And it’s why we argue that your first step should be to create an agile leadership team, which will operate just like any other agile team. It has an initiative owner who is responsible for overall results and a facilitator who coaches team members and helps keep everyone actively engaged. Leaders agree to spend less time micromanaging their individual functions. They agree to spend more time developing an agile system to support the strategy for achieving targeted outcomes, such as business purposes, financial results, customer satisfaction, and employee inspiration. They overcome organizational paralysis by breaking complex problems into actionable steps and systematically attacking them. They plunge in to solve problems and remove constraints rather than delegate that work to subordinates.

A critical tool for the team is a robust, adaptive backlog of opportunities that team members can tackle together. The backlog will give your team a realistic, itemized, fact-based vision of how much value is possible, and in what order the team should attack the work. Committing to each other to stick together in pursuit of the backlog increases the probability of the team’s collective success. Initially, a backlog may seem like nothing more than a fancy to-do list, but it is different in three important ways. First, each item is written in the form of an important customer need or opportunity rather than as a task to complete. Second, each item is ruthlessly sequenced to discourage multitasking and to push all resources to the most valuable work. Third, backlogs are continuously updated and resequenced to reflect the most current information about their value and resource requirements.

In addition to forcing focus on customers and adaptability, a backlog gives your agile team courage to say no to low-value activities. When Erik Martella, vice president of Central Coast Wineries at Constellation Wines, started implementing agile, he received an email from a superior in Constellation’s corporate office suggesting that the winery explore a personal passion of the sender. Previously, Martella told us, he might have responded, “OK, we’ll jump right on it.” Instead, he replied that the winery was following agile principles: the idea would be added to the list of potential opportunities and prioritized. As it happened, the executive liked that approach—and when he was informed that his suggestion had been assigned a low priority, he readily accepted the decision.

There’s one more related benefit of a backlog. Do you remember how Amazon’s Goldberger talked about the advantages of stopping ineffective innovations faster? Members of failing teams—fearing that they will be labeled as losers and reassigned to menial tasks or even laid off—work very hard to look busy and confident. They should actually be calling it quits and seeking more promising assignments. A robust backlog encourages such behavior by constantly presenting an appealing menu of obviously superior opportunities. The backlog beckons: Would you rather plug away on that mundane project delivering disappointing results or leap to one of the company’s highest and most exhilarating priorities? People don’t deliberately choose to fail if they have better options.

Over time, the agile leadership team (like every other agile team) must measure its progress. A common cry in the agile community these days is, “Measure outcomes, not outputs.” We understand the intent, but the truth is that to create effective systems leaders need to measure outcomes and outputs, as well as activities, inputs, and purposes. The agile community’s point is that you can work hard and turn out a bunch of new products without improving customer satisfaction or financial results. Conversely, however, you can’t improve customer satisfaction or financial results without working very hard and turning out a bunch of new products.

Sakishi Toyoda, the founder of Toyota Industries and a pioneer of agile innovation methods, taught that if you want to improve outcomes, you have to improve the processes and systems that deliver those results. If outcomes weren’t what was expected, he encouraged people to dig deeply into the root cause. He called his technique the five whys. Identify a problem and then ask why the processes are leading to it. If a process is defective, ask why. Keep this up until you find the source of the problem, which usually takes five iterations. Then you can figure out how to fix it. Similarly, measuring outcomes is not sufficient. You can’t fix an outcome without understanding and fixing the processes in the system that cause it. Using metrics to monitor processes not only helps to answer the five whys, it also enables statistical process controls to prevent future problems even when current outcomes appear to be fine. Current financials may look strong, but if the new product pipeline is empty and your best innovators are jumping ship, you have a process problem that will soon become an outcomes problem.

As leaders do all this, their own productivity and morale improve. They learn to 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.

4. Make It Fun

We are perplexed by how many change-management gurus preach, and actually seem to believe, that transitioning to agile approaches must be radical and painful in order to be beneficial. They seem to revel in the organizational chaos while predicting that euphoria is surely just around the corner. With all due respect to Elisabeth Kübler-Ross and grief curves, doing agile right has little in common with losing a loved one. It has everything to do with finding better ways to work in teams that make people happier, more innovative, and more successful.

Here’s our advice: If the change process is making you or your employees unhappy, stop it! Now! Don’t do weird things. And don’t mistake employees’ gradual, grudging resignation to weird ways of working for budding enthusiasm. The truth is that agile progress should feel good from the beginning. We’re not saying that agile requires no work; we are saying that it should produce the equivalent of a runner’s high—the good feelings that come from a workout that delivers tangible progress toward a healthier mind and body. Substantial research shows that happiness and innovation are inextricably linked. It doesn’t matter whether happiness drives innovation or innovation increases happiness. If you improve one, you will begin a cycle that can continuously improve both. Success is habit forming. Our brains produce neurochemicals that make the process of successful achievement feel good. When we set and achieve a goal, our brains release dopamine, the reward hormone that drives us to continue doing things that bring us pleasure. When we bond with others and increase our trust in them, our brains deliver a hit of oxytocin, which increases loyalty and makes us want to grow closer to others. When we overcome a difficult challenge, our brains release endorphins, creating good moods and decreasing fatigue. When we engage in activities that reinforce a strong sense of purpose, our bodies produce serotonin, which makes us feel confident and calm. All of these chemicals and others reinforce beneficial behaviors and increase our happiness as well as our ability to innovate as a team.

When people are unhappy at work, it is because they are not doing rewarding things and their brains are not producing enough of the chemicals that make work pleasurable. These people aren’t just disengaged, they are suffering from a form of neurochemical withdrawal. Good agile leaders will learn how to increase achievement by making innovation fun and rewarding. They learn how to help teams set and achieve goals, bond with others, overcome difficult challenges, reinforce a sense of purpose, and make successful achievements feel good.

One tactic for making the whole endeavor fun is to create and celebrate frequent wins. Critics of agile teams complain that agile uses sprints to create high-pressure deadlines that push people to exhaustion, leaving no time for resting or even thinking. We agree that bad agile has the potential to do this. But doing agile right uses sprints for entirely different purposes. By breaking large, complex problems into more manageable tasks, agile increases confidence to tackle the most daunting assignments. To figure out creative ways to develop and test rapid prototypes, agile teams employ short, tight feedback loops that quickly and easily adjust to unpredictable events. And the greatest benefit of sprints is that they create more frequent wins and opportunities to celebrate them. Teresa Amabile and Steven J. Kramer put it this way in their HBR article, “The Power of Small Wins”:

Of all the things that can boost emotions, motivation, and perceptions during a workday, the single most important is making progress in meaningful work. And the more frequently people experience that sense of progress, the more likely they are to be creatively productive in the long run. Whether they are trying to solve a major scientific mystery or simply produce a high-quality product or service, everyday progress—even a small win—can make all the difference in how they feel and perform.10

Managed properly, sprints create opportunities every week or two to deliver gratifying progress toward a meaningful purpose. All learning becomes something to celebrate, even if it causes the team to change assumptions, pivot to a different solution, or jump to a new opportunity. Your job as an agile leader will be to help your team create more frequent wins and to remove the obstacles that impede progress. You have the responsibility to highlight progress, and to celebrate that progress in rousing ways. Doing so will improve your team’s motivation and ability to innovate.

And finally, one more ingredient of fun: teaching and coaching others. Teaching—and watching others learn—is one of the most rewarding and satisfying of human endeavors.

Here’s why: Richard Feynman, whose work in quantum electrodynamics won him a Nobel Prize in Physics, taught that the best way to master any new skill was to teach it to a beginner. He believed that experts often hide behind jargon and esoteric vocabulary to disguise their own ignorance. We ourselves find that when we work to explain things in simple language, we have identified an opportunity to learn more. We try to dig in until we can explain it to a child—or to a skeptical senior executive. As you develop agile capabilities and start teaching them to beginners, you will be surprised by how much they force you to learn. Their questions will expose your incomplete thinking and hidden assumptions. And as others learn and apply agile principles and practices, improving their own performance, and making it easier for additional employees to improve theirs, you will be astonished by the satisfaction that comes from mentoring and bonding with others while making such a meaningful contribution to business performance.

As we said at the start of this book, if you and your team are not having fun with agile, you’re not doing it right.