1.

MORE VALUE FROM LESS WORK

What we need is an entrepreneurial society in which innovation and entrepreneurship are normal, steady, and continuous.

—PETER DRUCKER¹

For Spotify—the fast-growing Swedish music streaming service with over 100 million active users and more than 30 million paying users—the true value of Agile management became dramatically apparent in mid-2015. Spotify had embraced Agile management since its launch in 2008, with swarms of self-organizing teams intent on delivering steadily more value to Spotify’s users. The premise of Agile management is that empowering bottom-up innovation will steadily add significant value for customers and the firm. Accordingly, the teams at Spotify—some 2,500 people as of mid-2016—seek to learn everything about you as both a listener of music and as a user of Spotify, and then find interesting ways to appeal to you on both levels. Sometimes they do that by matchmaking, by telling you at the right moment about a great playlist, or a great new feature, or some new content that they think you will like. Other times, they do it by creating new listening experiences.

Innovations generated by Agile teams had fueled Spotify’s growth for seven years. But in March 2015, a couple of Spotify’s software engineers—Chris Johnson and Ed Newett—came to Matt Ogle, a senior product leader with two degrees in English literature and a background as an engineer, with an idea that turned out to be a game-changer. They had thought of a way of solving a problem that had stumped Spotify and other music streaming services like Pandora and Apple Music for years: How could users find the music they would really love in a library of millions of songs without wasting time browsing through music they didn’t like?²

In 2013, Spotify had introduced a feature called News-Feed in which users received personalized recommendations of albums and artists. This was progress, but it still took a lot of effort on the part of users to engage with the recommendations and get to listen to the music.

In 2014, Spotify had offered a feature called Discover, which grouped the recommendations into strips, as on Netflix. This was easier to use than News-Feed, but it also required active user effort. Studies showed that users were still spending more time listening to playlists that Spotify’s editors had created.

Now the two engineers had another idea. What if, they asked, we could completely remove the friction for you as a user? What if we took the music you had listened to in the past and sorted it into micro-genres? What if we analyzed the billions of playlists created by other users and algorithmically matched preferences with your playlists, so we can then create a new playlist specifically designed for you? What if we delivered this personalized playlist of songs for you once a week? What if, every time you skipped a track, we learned from that and made sure that your next weekly playlist would appeal to you even more? What if we did this not just for you but for every one of our tens of millions of active users? Would that be possible? Or would it just produce noise? This was the embryo of the wildly successful idea on Spotify that became known as Discover Weekly.

Ogle liked the idea. He discussed with the engineers different ways of making it work. They brought in a designer who played the bad cop in the discussion. “Why should this feature exist?” he asked. “We already have too many things for users! What will it do that we’re not already doing?” Those questions helped the team get clearer on what the new idea was for and what value it might add.

Ogle’s team had all the elements in place to conduct a quick experiment. Spotify had already collected data on active users—which then numbered some 75 million. They had also built high-level capabilities in machine learning and artificial intelligence. They had already developed micro-genres of music and classified its entire vast repository of music and its billions of playlists.

But most important, Spotify had created an organizational culture of Agile management in which autonomous cross-functional teams were encouraged to experiment and create new ways of adding value to customers. With Agile management, Ogle and his team didn’t need to prepare a detailed cost-benefit proposal and seek a series of approvals up a steep management chain before they could try out their idea. They were used to working as a team, with radical transparency among the team members. They were already tightly focused on the user experience: They knew how to test alternatives and learn from the tests. Within a couple of weeks, the tiny cross-functional team had pulled together a quick prototype and tried it out on Spotify’s own staff—all active Spotify users.

The result? Spotify staff just loved it. Ogle himself became a huge enthusiast. On one of his very first playlists, he recalls listening to a song by Jan Hammer, the composer of the Miami Vice theme. “It starts off with this poppy thing, then the strings,” said Ogle. “When the vocals came in, I thought, holy shit, we have to ship this feature. Whatever just served this song needs to be out in the world.”³

Ogle and his team did another quick experiment on one percent of the active Spotify users—close to a million people. Again, the response was strongly positive. Amazingly, 65 percent of respondents found “a new favorite song” in their personalized weekly playlist. As a result, Spotify’s management was ready to introduce Discover Weekly for all Spotify listeners.

Scaling up the Discover Weekly algorithms from one million users to 75 million users in twenty-one languages in multiple time zones each week proved to be more of a challenge than the engineers expected. Nevertheless, working in an Agile fashion totally focused on the goal, the team took only a couple of months to complete the work. When Discover Weekly was deployed to all Spotify users in July 2015, just four months from the initial concept, it was a wild success—beyond anything Ogle and his engineers had imagined.

In fact, Discover Weekly has become a global phenomenon. It has resulted in a massive boost for Spotify’s brand and a huge influx of new users. It is more than just another feature—it is almost a new brand in itself, with foreign-language countries clamoring for “Discover Weekly” rather than a label in their own language. Every Monday morning, Spotify users—now more than 100 million of them—receive a playlist of thirty songs that feels like a gift from a talented and knowledgeable musical friend who understands their taste in music and who has searched the world to put together a handpicked playlist of the very best music they will adore.

Users say it’s spooky how fresh and familiar their Discover Weekly playlists feel. A common reaction is, “How come Discover Weekly knows me better than myself?” Within the first six months, songs from Discover Weekly had been streamed several billion times.

“If you’re the smallest, strangest musician in the world, doing something that only twenty people in the world will dig,” says Ogle, “we can now find those twenty people and connect the dots between the artist and listeners. Discover Weekly is a compelling new way to do that at a scale that’s never been done before.”⁴

Discover Weekly gives Spotify a massive brand advantage over competitors like Pandora and Apple Music, which also have vast catalogs of music but without Spotify’s personalized approach to help you find music you will enjoy. Yet Spotify knows it can’t rest on this success. It knows that its competitors will soon emulate Discover Weekly. In the spirit of Agile, Spotify is already racing ahead with further innovations that will bind its user community ever more tightly to the music streaming service they have come to love. Spotify’s management knows that it will only survive if it continues to pursue Agile management and innovates faster than its competitors.

At first glance, the idea that Barclays—a 327-year-old transatlantic bank with more than 100,000 employees—could become as Agile as Spotify and deliver an instant, frictionless, intimate banking experience at scale might seem ridiculous. The bank operates in a difficult environment. It’s highly regulated. It’s recovering from a major financial crisis. And it has new challenges coming its way as it grapples with what Brexit means for the future. It’s a transatlantic bank offering products and services across personal, corporate, and investment banking, credit cards, and wealth management, with a strong presence in its two home markets: the United Kingdom and the United States. The bank operates in over forty countries. One-third of payments made in the U.K. pass through Barclays.

Despite its size and reach, Barclays, like all the big global banks, finds itself in a world in which its customers are coming to expect the same kind of instant, intimate, frictionless responsiveness at scale that they experience with Spotify’s Discover Weekly playlist. What they would like from a bank are prompt, helpful responses, not just to simple questions like, “What’s my bank balance?” but also, “Should I spend this money on this car? Should I buy, lease, or get a loan? What sort of insurance do I need? What impact will this have on my savings? How is my retirement looking?”

Ironically, if Barclays, like all banks, knew what it already knew, it could, like Spotify, provide good answers to those questions. That’s because Barclays, like Spotify, has massive amounts of data about its customers and clients that could help the bank add value by answering some of these questions—if this data was put to better use.

Barclays, like all the big global banks, also faces the challenge of inherited management practices and old data structures and processes that can make it difficult to deliver instant, frictionless, intimate banking experiences at scale. As an old institution, it has to invest time and money in upgrading and streamlining old data structures, processes, and applications to improve the products and services it can offer its customers. With individual customers’ information stored on separate parts of the bank’s systems, it can be difficult to provide the level of customer experience that customers have come to expect from companies today.

Decades ago, none of that mattered to customers when they would make an appointment to see their local bank manager and discuss how they could finance an extension on their house, or buy a new car, or invest in shares to provide for their retirement. Much depended on a personal relationship with the bank manager. In the end, customers might have gotten the loan or the advice they needed. But the process took time to arrange. It was inconvenient. It involved significant effort producing documents and records. And it worked for only a handful of customers.

How could Barclays possibly go from that old-school banking experience to the kind of easy, convenient, personalized responsiveness that its millions of twenty-first-century customers are coming to expect in everything they do?

Unlike Spotify, Barclays had not, until recently, made an institutional commitment to Agile management. Like most of the big global banks, Barclays had management practices and processes that were steeply hierarchical and bureaucratic. As in most large organizations today, Barclays had isolated islands of Agile software developers, but this wasn’t consistent across the organization. Nor had Barclays developed the capability to carry out and learn from rapid experiments with its customers.

Yet management could see that some of the bank’s competitors are already acting with that kind of agility. On the international front, large Asian competitors, such as Alibaba and Tencent, are expanding rapidly, with management and data systems oriented to meeting their customers’ needs, not their own internal requirements. They are acquiring new customers for just a couple of cents each, while the cost for larger, mainstream financial players like Barclays was a large multiple of that. Meanwhile, digital behemoths like Google, Amazon, and Apple are handling an increasing proportion of the world’s financial transactions that used to be handled by banks. On yet another front, financial sector startups are innovating rapidly and threatening to create the very instant, personalized, frictionless responsiveness that customers increasingly expect. Although these startups are still small, many of them are now valued at more than a billion dollars. A group of some thirty of them formed in just the last few years are worth collectively more than Barclays’ own market capitalization.⁵

In 2014, Barclays started to respond to these external threats, recognizing that it needed to adapt its way of working, management practices, and systems. To keep pace with what new competitors were offering, the bank recognized that it would only succeed if it was able to offer, like Spotify, easy, quick, convenient, personalized responsiveness at scale. In short, Barclays had to become Agile. In March 2015, Barclays’ operations and technology team announced that becoming Agile was a key strategic initiative. The many islands of Agile within Barclays were invited to come out from the shadows and become the champions of Agile transformation at Barclays.

Two years later, by March 2017, Barclays had made remarkable progress. After a massive program of Agile training and coaching, the equivalent of more than a thousand self-organizing Agile teams—around 15,000 people—were operating, covering every aspect of the business (commercial bank, investment bank, accounts, audits, and compliance)—all focused on delivering more value sooner to customers. While some teams were still in the early stages of mastering Agile management practices, a sizable proportion were already mature and making significant inroads improving Barclays’ performance.

For example, the Agile Loans team devised an online loan application that reduced the time from “initial ask” to “the Barclays response” from twelve days to twenty minutes. The online solution operates almost a thousand times faster than cumbersome paper-based procedures and in-person interactions requiring visits to physical offices.

Agile Onboarding is another example. You might think that a bank like Barclays would have figured out how to make it easy for anyone to become a customer, either as an individual or as a business, through opening a new account, applying for a loan, or making a new investment. Yet in practice, the online and in-branch processes for this function were cumbersome. Barclays had recognized the importance of improving the process: Several years before, it had tasked a group of over a hundred developers to create a better online onboarding process, but they had yet to produce a desirable solution. By contrast, when Barclays put together an Agile team of only six developers, they developed a viable onboarding tool in just six months, also resulting in cost savings and improved productivity.

The Agile transformation at Barclays is both top-down and bottom-up. Support and inspiration from the top are critical to legitimizing the Agile way of working and helping to remove impediments to the fundamental changes implicit in Agile. At the staff level, there is a community of Agile practitioners with some 2,500 people, along with around 15,000 practitioners involved in Agile teams. In fact, it was these Agile community members who drafted the bank’s Agile Enterprise transformation proposal in 2014. Barclays’ own Agile advocates said, “Here’s what Agile means for us and here’s how we should do it.” And now Barclays is doing exactly that. Since Agile is perceived as something inspired and supported—not imposed—from on high, the psychological level of buy-in at the working level is strong.

Nevertheless, it’s still early days for Barclays’ Agile transformation. Barclays has much work to do before it can fully deploy the intelligence and the know-how of algorithms that could help millions of customers make better financial decisions in real time. This will require deeper understanding of their different situations, contexts, and prospects, as well as insight into how their needs can be met on the fly and at scale. And it is only through years of steady implementation that Barclays will be able to claim that it has embedded a culture of Agility throughout the organization.

But Barclays has made a start. And everywhere there is evidence of early success. Its management knows that Agile transformations involve a deep change in organizational culture that will take time. Barclays can take heart from the experience of other global behemoths like Microsoft and Ericsson that have persevered with Agile transformations at scale over a period of years and have made sustained progress. In other words, firms don’t have to be “born Agile,” like Spotify. Even big, old firms can undertake an Agile transformation if they set their minds and hearts to it—and stick with it.

Spotify and Barclays are just two of thousands of organizations that have made a fundamental discovery: Business success in the twenty-first century increasingly depends on becoming as nimble as the rapidly shifting and unpredictable context in which they find themselves.

As a result, Agile management is now spreading to every kind of organization and every aspect of work, as recognized in 2016 by the citadel of general management, Harvard Business Review, with its article “Embracing Agile,” by Darrell K. Rigby, Jeff Sutherland, and Hirotaka Takeuchi.

Now agile methodologies—which involve new values, principles, practices, and benefits and are a radical alternative to command-and-control-style management—are spreading across a broad range of industries and functions and even into the C-suite. National Public Radio employs agile methods to create new programming. John Deere uses them to develop new machines, and Saab to produce new fighter jets. Intronis, a leader in cloud backup services, uses them in marketing. C. H. Robinson, a global third-party logistics provider, applies them in human resources. Mission Bell Winery uses them for everything from wine production to warehousing to running its senior leadership group.⁶

The centrality of Agile for general management was also recognized in March 2016 with McKinsey & Company hosting a Global Agility Hackathon involving some 1,500 participants worldwide. According to the winning submission:

Becoming an agile organization is an increasingly urgent necessity for companies in today’s digital economy, yet most companies have a deeply embedded command organization architecture and culture. This reflects, first and foremost, the industrial economy mindsets and skills of their senior leaders, which is arguably the greatest obstacle to becoming an agile organization. . . . To make the transformation, senior leaders must learn and practice a holistic and complete set of new mindsets and skills, and apply them to design a wholly new, agile organization architecture and culture.⁷

The emergence of Agile for general management was also confirmed by the findings of the SD Learning Consortium, a group of companies including Microsoft, Ericsson, CH Robinson, Riot Games, Barclays, and Cerner. Amid conflicting claims as to whether Agile is something real, the Consortium seeks to discover what is actually happening on the ground and to learn what works and what doesn’t. Site visits showed that in a few cases, Agile was indeed hardly more than talk; the organization was still functioning as a top-down bureaucracy. But in most cases, site visits showed that major corporations have large-scale implementations of Agile goals, principles, and values. In effect, Agile management in large organizations is actually happening.⁸

In organizations that have embraced Agile management, self-organizing teams are continuously providing new value for customers. Because the work is done in an iterative fashion with continuous interaction with users, the organization can constantly upgrade what it offers to users, sometimes in real time. When teams work in a common cadence—short iterations of the same length that start on the same day—many teams can work together on large, complex challenges in a coordinated fashion and deliver fail-safe products. When Agile is done right, the teams are working within a business model in which the organization is generating value for the organization itself as well as the customer. Everything—the work being done, the information, and the money—moves easily, in an integrated fashion, often with strong returns to scale.⁹

Agile management is about working smarter rather than harder. It’s not about doing more work in less time: It’s about generating more value from less work. For instance, in 2011, Ericsson (a 140-year-old Swedish firm with around 100,000 employees) embraced Agile for its business unit in managing networks for the world’s telecommunications companies. Competition in the sector is fierce. Of seven global firms that operated just a few years ago, only three, including Ericsson, have survived. Before 2011, Ericsson would build its systems on a five-year cycle with a unit housing several thousand employees. When the system was finally built, it would be shipped to telecom customers and there would be an extended period of adjustment as the system was adapted to fit their needs.

Now Ericsson has over a hundred small teams working with its specific customers’ needs instead of working on all of the requirements for the overall system. They involve the customers in testing different aspects of the system in three-week cycles. The result is faster development that is more relevant to the specific needs of the customers. Moreover, the interaction has enabled Ericsson to focus on the customers’ highest priorities. The client gets to see the next iteration of the system every three weeks, instead of waiting five years for one “big bang” delivery. They know exactly what is being worked on and can direct the course of the work.

In one case, Ericsson’s client said, “For us to deploy this new system in our entire network, we would need around 120 improvements.” It turned out, because of Ericsson working interactively with its customers, the client decided to go ahead with around sixty of the improvements. The client said: “If we had been working as we were in the past, we would never have done that at this stage. But because of the cooperation that we have, now we are ready to go ahead.” The result? The client gets value sooner. Ericsson has less work in progress. And Ericsson is deploying one to two years earlier than it otherwise would, so its revenue comes in one to two years sooner. The client is much happier and there is a financial benefit for Ericsson.¹⁰

One common misunderstanding of Agile management is to see it as a technology solution—digitization—rather than an approach to running an organization. While obviously Agile does use digital technology to enable instant, frictionless, intimate value at scale, the gains are driven by Agile management. When top-down bureaucracies use digital technology, machine learning, platforms, blockchain technology, or the Internet of Things, they typically get meager results. That’s in part because internally driven innovation often generates changes that customers don’t want or aren’t willing to pay for.

Resolving complex problems requires both continuous collaboration across internal silos and interaction with customers. Delivering instant, intimate, frictionless customer experiences that delight customers lies beyond the performance capability of an internally focused bureaucracy. Bureaucracy was never intended to accomplish that: It was designed to produce merely consistent average performance according to internal rules set by the organization itself.

Moreover, bureaucracies, with their steep chains of command, can’t move fast enough to take advantage of opportunities in a VUCA marketplace as they emerge. In a competitive setting, it’s not technology itself that makes the difference. The key is how adroitly the firm uses the technology. The driver of sustained success is the Agile mindset.

But what exactly is Agile? What does it mean for an organization to embrace the Agile mindset? When I use the word “agile” or “nimble,” you might think about a squirrel or a ballet dancer or a champion soccer player. You probably wouldn’t think of a large organization— big, unwieldy, clunky, slow, out to make money from you, and fundamentally unfriendly. You generally don’t think of organizations as being nimble because generally they’re not. We’re accustomed to dealing with organizations that are frustratingly set in their ways and preoccupied with their own internal processes. Their motto could be: “You take what we make; that’s the way it is.” The possibility that organizations could operate with agility is thus not obvious. And yet the site visits of the SD Learning Consortium show that large Agile organizations are not only possible. They do exist.

The challenge of understanding Agile is magnified by the more than forty labels that have been used for different flavors of Agile.¹¹ Nor does the multiplicity of Agile practices help: In my 2010 book, The Leader’s Guide to Radical Management, I identified more than seventy different Agile practices. How on earth are traditional managers going to make sense of such a bewildering blizzard of ideas?

The truth is that when we look closely, we can see that organizations that have embraced Agile have three core characteristics:

1. The Law of the Small Team

2. The Law of the Customer

3. The Law of the Network

The first universal characteristic of Agile organizations is the Law of the Small Team. Agile practitioners share a mindset that work should, in principle, be done in small, autonomous, cross-functional teams working in short cycles on relatively small tasks and getting continuous feedback from the ultimate customer or end-user. Big and complex problems are resolved by descaling them into tiny, manageable pieces.

For the first decade of the Agile movement (i.e., the 2000s), much of the effort was spent on figuring out how to generate high-performance teams on a systematic basis. Teams of course were not a new idea. We all know the magic. We have all at one time or another been involved in a small group where communications flow effortlessly and the group seems to think and act as one. When we are members of such a team, we can analyze a situation, decide, and act as though we are part of a single, uninterrupted motion. There is no one in charge telling us what to do. We trust the other members of the team. That trust is rewarded by performance. It’s as though the group has a mind of its own. Face-to-face conversation sorts out any differences in point of view. Work has become fun. The group is in a state of flow.¹²

Work in most twentieth-century organizations was very different. Big systems were implemented with big plans delivering large quantities of a standard product and succeeded through economies of scale. Work was broken down into small, often meaningless pieces. Individuals reported to bosses who ensured consistent and accurate performance in accordance with the plan’s specifications. The boss’s boss did the same, and so on, up the line. Plans and budgets were generated and allocated, division by division. The connection between any piece of work and its impact on the life of a customer was often hidden by mind-numbing internally focused systems. The result today is a disengaged workforce, with only one in five employees fully engaged in the work. Even worse, almost one in seven employees is actively disengaged and intent on deliberately undermining what the organization does.¹³

Throughout the twentieth century, writer after writer suggested that working in teams would be a better way to get work done. It began with Mary Parker Follett in the 1920s, and continued with Elton Mayo and Chester Barnard in the 1930s, Abraham Maslow in the 1940s, Douglas McGregor in the 1960s, Tom Peters and Robert Waterman in the 1980s, on to Douglas Smith and Jon Katzenbach in the 1990s and Richard Hackman in the 2000s.

Yet most organizations stayed stubbornly bureaucratic, with bosses supervising individuals. One reason was the pervasive management belief that teams couldn’t deliver disciplined, efficient performance at scale: They were useful for solving complex one-off problems, but for the run-of-the-mill work in a big organization, the conventional wisdom was that bureaucracy was better.

Another reason was that most teams in twentieth-century organizations were teams in name only. Most of them weren’t real teams at all. The team leader acted like any other boss in a bureaucracy. (See Figure 1-1.)

A third reason is that self-organizing teams achieving high performance were a rarity. The literature on teams often talked about high-performance teams—teams that were not just 10 percent or 20 percent better, but two, three, or even many times better—but suggested that they were a matter of luck. The right people had to have come together. The context had to be conducive. The stars had to be aligned. You could create conditions where it might happen. You could encourage it. But ultimately a high-performance team was a rare accident.

Figure 1-1. Agile vs. bureaucratic team.

It was the Agile movement that figured out how to create an environment that fostered consistent high performance in its teams. If there were a Nobel Prize for management, which there isn’t, and if there were any justice in the world, which there isn’t, the creators of Agile would be Nobel laureates. It is a breakthrough achievement, well accepted in the world of software development, and just now becoming more widely understood and recognized in general management.

The second characteristic of Agile organizations is the Law of the Customer. Agile practitioners are obsessed with delivering value to customers. The primary importance of the customer is recognized in the first principle of the Agile Manifesto:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

But frankly, in the first decade after the Agile Manifesto, customer focus received secondary consideration among software developers: Most of their attention was on getting the characteristics of the high-performance team right. In this period, teams often had very little contact with the actual customer. Instead, the customer was represented by a proxy representative who was mysteriously called a “product owner” and who supposedly knew what customers wanted.

Once Agile had solved the problem of how to generate high-performance teams on a consistent basis, then attention turned to the epic shift in power in the marketplace—the shift in power from seller to buyer. Who were these “product owners” and how did they figure out what the customer wanted or needed? The question became urgent, because under the Law of the Customer, abruptly, frighteningly, and to the great surprise of twentieth-century organizations, the customer had become the boss. Globalization, deregulation, and new technology, particularly the Internet, provided the customer with choices, reliable information about those choices, and the ability to interact with other customers. Suddenly the customer was in charge and expected value that was instant, frictionless, intimate, and preferably free.

As a result, firms had to think about the customer in a new way. Twentieth-century firms had gotten used to the notion that they could exploit and manipulate customers. If a customer didn’t like something they were offering, the firm would say, “We hear what you’re saying, but that’s what we’re offering. Take it or leave it. We’ll consider introducing changes in our next model, now some years away.” In today’s competitive marketplace, this approach is steadily less effective. The customer is thinking: “Why are we waiting a couple of years? If you won’t fix it now, I’ll find someone who will.”

The primacy of the customer is at once the most obvious and the most difficult aspect of Agile to grasp. One reason that it’s difficult to understand is that twentieth-century managers had learned to parrot phrases like “The customer is number one!” while continuing to run the organization as an internally focused, top-down bureaucracy interested in delivering value to shareholders.

It’s not that bureaucratic organizations ignore the customer. They do what they can for the customer—but only within the limits of their own internal systems and processes. Firms may say they are customer-focused, but if the information they need to answer simple questions from customers is hidden in multiple systems that don’t talk to each other, or if customer services must be cut to meet a quarterly profit target, then it’s too bad for the customer. The customer gets the short end of the stick. In a top-down bureaucracy, “the customer is number one” is just a slogan: Internal systems, processes, and goals take precedence. (See Figure 1-2.)

In the Agile organization, “customer focus” means something very different. In firms that have embraced Agile, everyone is passionately obsessed with delivering more value to customers. Everyone in the organization has a clear line of sight to the ultimate customer and can see how their work is adding value to that customer—or not. If their work isn’t adding value to any customer or user, then an immediate question arises as to why the work is being done at all. The firm adjusts everything—goals, values, principles, processes, systems, practices, data structures, incentives—to generate continuous new value for customers and ruthlessly eliminates anything that doesn’t contribute.

Figure 1-2. Bureaucratic vs. Agile organization.

The third characteristic is the Law of the Network. Agile practitioners view the organization as a fluid and transparent network of players that are collaborating toward a common goal of delighting customers.

In the early years of the Agile movement, it was generally assumed that if the firm could get high-performance teams going, then the whole organization would be “Agile.” It turned out not to be the case. It wasn’t enough to have Agile teams totally focused on delivering more value to the customer if the rest of the organization was being run as a top-down bureaucracy focused on cutting costs or increasing the current stock price. Such a dynamic undermines and, over time, kills Agile management.

The problem is widespread, even in organizations that are actively embracing Agile at the team level. We found in surveys of Agile teams that some 80 percent to 90 percent of Agile teams perceive tension between the way the Agile team is run and the way the whole organization is run. In half of those cases, the tension was “serious.”

The Law of the Network is the current frontier of the Agile movement—how to make the whole organization Agile. It’s a tough nut to crack because Agile represents a radically different concept of an organization. At the heart of twentieth-century management thinking is the notion of a corporation as an efficient steady-state machine aimed at exploiting its existing business model. As Google executives Eric Schmidt and Jonathan Rosenberg write in their book, How Google Works, “Traditional, MBA-style thinking dictates that you build up a sustainable competitive advantage over rivals and then close the fortress and defend it with boiling oil and flaming arrows.”¹⁴

The fortress is run from the top, with an assumption that the top knows best. The fortress is “built to minimize risk and keep people in their boxes and silos,” as business school professor John Kotter writes. People “are working with a system that is designed to get today’s job done—a system that asks most people, usually benignly, to be quiet, take orders, and do their jobs in a repetitive way.”¹⁵ Exploitation of the existing business model takes precedence over the exploration of new possibilities.

Over many decades, multiple fixes were explored to alleviate the static nature of the organization, including task forces, special project groups, strategy departments, tiger teams, skunk works, R&D, dual operating systems, knowledge funnels, design thinking, and so on.¹⁶ But these were still fixes to the same concept of the corporation as a static machine with a vertical reporting dynamic. Big bosses continued to appoint little bosses, and so on down the line. The organization continued to operate like a giant warship—big and disciplined but slow and hard to maneuver.

By contrast, when the whole organization truly embraces Agile, the organization is less like a giant warship and more like a flotilla of tiny speedboats. Instead of a steady-state machine, the organization is an organic living network of high-performance teams. In these organizations, managers recognize that competence resides throughout the organization and that innovation can come from anywhere. The whole organization, including the top, is obsessed with delivering more value to customers. Agile teams take initiative on their own and interact with other Agile teams to solve common problems. In effect, the whole organization shares a common mindset in which the organization is viewed and operated as a network of high-performance teams.

One common misunderstanding is that Agile organizations are necessarily flat or nonhierarchical. In Agile organizations, the top management still has the important function of setting direction for the organization. People are still removed for not getting their job done. If anything, the drive for higher performance in an Agile organization is even more relentless than in a bureaucracy. Because of radical transparency and peer-to-peer accountability, there is nowhere to hide. Everyone knows everything.

But the hierarchy in an Agile organization is primarily a hierarchy of competence, not a hierarchy of authority. The performance question is not whether you have pleased your manager by doing what you were told to do: The question is whether you have added value to your real boss—the customer. The organization operates with an interactive communication dynamic, both horizontally and vertically. Anyone can talk to anyone. Ideas can come from anywhere, including customers. As a network, the organization becomes a growing, learning, adapting living organism that is in constant flux to identify and develop new opportunities that add new value for customers. When done right, continuous delivery of more value to customers from less work results in generous returns to the organization that provides it.

Agile thus explodes the distinction between exploitation and exploration. All parts of the organization are continuously exploring how to add more value to customers.

In the early years of the Agile movement, critics said that small teams would never be able to handle big, complex problems. It turns out that once the teams are housed in a network driven by horizontal conversations focused on a common goal and operating in a common cadence, then networks of small teams can handle large, complex problems with the same agility as small teams—and much better than a top-down bureaucracy.

These three laws—first, small teams working on small tasks in short iterative work cycles delivering value to customers; second, an obsession with continuously adding more value for customers; and third, coordinating work in an interactive network—are the same three principles that enable Spotify to provide personalized music playlists to over 100 million users every week. These same principles are allowing Barclays to become a bank that can provide easy, quick, convenient, personalized banking at scale; and Ericsson’s network management to deliver more value to its clients sooner.

When these three laws are in effect, people in the organization share a different way of understanding how the world works and how to interact with the world to get things done. Counterintuitive ideas abound: Managers can’t tell people what to do; firms make more money by not focusing on making money; dealing with big issues requires small teams, small tasks, short work cycles—in effect, small everything; control is enhanced by letting go of control.

When a traditional manager encounters an organization with these strange ideas, it’s like visiting a foreign country where everything is different, where yes may mean no, where fixed prices are negotiable, and where laughter may mean anger.¹⁷ The familiar cues that enable travelers to function in their home country are absent. In their place are new rules that are odd and incomprehensible. The result can be bewilderment, frustration, and an inability to cope. Until the travelers grasp what has happened, learn the new cues of the different country, and embody them in their behavior, they will feel disoriented and incompetent.

This is why Agile cannot be implemented within the assumptions of current management practice. Agile means embracing fundamentally different assumptions. For traditional managers, the process usually isn’t comfortable. It isn’t easy. At the outset, it feels wrong. It’s like learning a foreign language with a different grammar. It is only over time and through actual experience and practice that Agile becomes second nature and automatic. This is not about “implementing Agile tools and processes.” It’s about more fully embodying the Agile mindset and acquiring the associated muscle memory.

Ultimately, Agile is about understanding and interacting with the world with a different mindset. When people don’t have an Agile mindset, our research shows that even if they are implementing every tool and process and practice exactly according to the book, no benefits flow. Conversely, when people in the organization have an Agile mindset, it hardly matters exactly what tools, processes, and practices they are using. The mindset makes things come out right. In the end, Agile is a mindset.

Of the three laws, the first one—the notion that work in principle should be done in small teams working in short cycles—is the best known in the Agile world because that’s what received most of the attention of the early Agile implementations.

But it’s the second law—the idea that the very purpose of a firm is to deliver value to the customer—that is the most important, because this is the principle that makes sense of the other two and that permits the greatest insight into why an Agile organization operates the way it does.

Yet, the lynchpin of Agile management is really the third law: The impact of high-performance teams with a customer focus is suboptimal unless and until the whole organization operates as an interactive network. It is when the three laws combine together and focus on a common external goal that we get the explosive increment in value that comes from truly embracing Agile management.

Agile management thus operates under three laws, and together they generate the basics of the Agile organization. The three laws allow us to make sense of the myriad Agile practices that may—or may not— be applicable in any particular context. Practices may change, but the Agile mindset applying the three laws endures. The Agile mindset offers a lasting guide to what’s involved in an organization implementing the new management paradigm.