Agile is a vast global movement that is transforming the world of work. The movement took off in software development in 2001 and is now spreading rapidly to all parts, and all kinds, of organizations, 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 Hirakata Takeuchi. There are already hundreds of thousands of Agile practitioners all around the world.
Yet what exactly is Agile? How do you explain Agile when there are more than forty different variants of Agile, as depicted in this graphic by Australian designer Lynne Cazaly.
Graphic by Lynne Cazaly reproduced with permission from a talk by Craig Smith: Slides and video are available here: https://craigsmith.id.au/2015/12/03/yow-2015-40-agile-methods-in-40-minutes/
And what about all those Agile practices? There are more than 70 different Agile practices. Even the Agile Manifesto, with its four values and twelve principles can be a cognitive stretch for newcomers.
How on earth can you explain such a bewildering blizzard of seemingly different ideas?
Let’s start with why. Agile enables organizations to cope with continuous change. It permits them to flourish in a world that is increasingly volatile, uncertain, complex and ambiguous. The rise of Agile is driven both by the passion of those who love working this way and by organizations that are making a life-changing discovery: the only way to cope sustainably with today’s marketplace is to embrace Agile. Firms must become as nimble as the rapidly shifting context in which they find themselves. As managing software becomes central to the success of most businesses, Agile is becoming a key to the management of everything.
In an Agile organization, 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 does for each individual user, sometimes almost in real time. When teams work on a common cadence, many teams can work together on large complex challenges in a coordinated fashion. When Agile is done right, the teams are working within a business model in which the organization is generating value for the organization as well as the customer. Everything—the work being done, the information, and the money—moves easily, in an integrated fashion, leading to low or zero marginal costs and massive returns to scale.
Agile is about working smarter, rather than harder. It’s not about doing more work in less time: it’s about generating more valuewith less work.
Agile responds to the central challenge of business today: how to provide instant, frictionless, intimate value at scale. While such performance, when it occurs, is enabled by technology, it’s drivenby Agile management. When top-down bureaucracies use digital technology, machine learning, platforms, blockchain technology or the Internet of Things, they typically get meager results. Delivering frictionless customer experience lies beyond the performance capability of an internally-focused bureaucracy. Internally-driven innovation with new technology often generates changes that customers don’t want or aren’t willing to pay for.
Delivering frictionless customer experience requires both continuous collaboration across internal silos and interaction with customers–something that bureaucracies are not good at. Nor can bureaucracies, with their steep chains of command move fast enough to take advantage of opportunities in the marketplace as they emerge.
In a competitive setting, it’s not the technology itself that makes the difference, since the same technology is available to all firms. The key is how adroitly the firm uses the technology. The driver of sustained digital success is Agile.
What Does It Mean To Be Agile?
What does it mean for an organization to embrace Agile? When I say the words, “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—unwieldy, clunky, slow, out to make money from you, and fundamentally unfriendly. You generally don’t think of organizations as agile 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 and that’s the way it is.” The possibility that organizations could become agile and nimble is thus not obvious. And yet the site visits of the Learning Consortium show that large Agile organizations do actually exist.
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
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.
For the first decade of the Agile movement, much of the effort was spent on figuring out how to generate these high-performance teams on a systematic basis. Teams, of course, were not a new idea. Most of us know the magic. We have all at one time or another been involved in a small team 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 it is 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 almost as if the group has a mind of its own. Face-to-face conversation sorts out any differences in point of view. Work becomes fun.
Work in most 20th century organizations was very different. Big systems implemented big plans delivering large quantities of a standard product. Work was broken down into small meaningless pieces. Individuals reported to bosses who ensured consistent and accurate performance in accordance with the 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 particular piece of work and its impact on a customer was often hidden by immense internally-focused systems. The result? Only one in five workers today is fully engaged in his or her work, and even fewer are truly passionate—a disaster for firms that increasingly depend on a motivated workforce.
Throughout the 20th century, writer after writer suggested that working in small 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, Peters and Waterman in the 1980s, on to Smith and Katzenbach in the 1990s.
Yet most organizations stayed stubbornly bureaucratic. One reason was the pervasive management believes that the 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 20th-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.
Real self-organizing teams that achieved genuine high performance were a rarity. The literature on teams often talked about high-performance teams—teams that were not just ten or twenty percent better, but two, three, or even ten times better—but suggested that they were a matter of luck. The stars had to be aligned. The right people had to have come together. The personal chemistry had to be right. The context had to be conducive. You couldn’t plan it or make it happen. You could encourage it. But ultimately it was a happy accident.
It was Agile that figured out how to generate high-performance teams on a consistent basis. If there was a Nobel Prize for management, which there isn’t, and if there was any justice in the world, which there isn’t, the creators of Agile would be awarded the Nobel prize for management. It is a breakthrough achievement, well accepted in the world of software development, even though it is still not widely understood or recognized in general management.
2. The Law Of The Customer
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. But frankly, in the first decade of the Agile movement, customer focus received secondary consideration among software developers: most of the 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 the proxy representative who was called a “product owner,” and who mysteriously 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 from seller to buyer. Who were these product owners and how did they know what the customer wanted? The question became urgent, because under the Law of the Customer, abruptly, suddenly, inexplicably, frighteningly, to the great surprise of 20th-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 connect with other customers. Suddenly the customer was in charge and expected value that is instant, frictionless and intimate.
As a result, firms had to think about the customer in a new way. 20th 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. We’ll consider introducing changes in our next model, now some years away.” In today’s more competitive marketplace, in which customers expect instant, frictionless, intimate responsiveness at scale, 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 will 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 why it’s difficult to understand is that 20th 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 focused on delivering value to shareholders.
It’s not that these bureaucratic organizations ignore the customer. They do what they can for the customer—but only within the limits and constraints 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 in order 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.
In the Agile organization, “customer focus” means something very different. In truly Agile organizations, 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 eliminate anything that doesn’t contribute.
3. The Law Of The Network
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 towards a common goal of delighting customers.
In the early years of the Agile movement, it was generally assumed that if you could get high-performance teams going, then the organization would be “Agile.” It turned out not to be the case. It isn’t enough to have Agile teams totally focused on delivering more value to the customer, if the rest of the organization is being run as a top-down bureaucracy focused on cutting costs or increasing the current stock price. The top-down dynamic undermines, and if continued, eventually kills the Agile teams.
Moreover when Agile teams are housed within a bureaucracy, collaboration between teams can be just as much a problem as it is between silos in a pure bureaucracy.
The problem is widespread, even in organizations that are actively embracing Agile at the team level. In surveys that we conducted at Scrum Alliance, we found that some 80-90% of Agile teams perceived 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 rated as “serious.”
The Law of the Network is the new 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 20th century management thinking is the notion of a corporation as an efficient steady-state machine aimed at exploiting its existing business model. “Traditional, MBA-style thinking,” as Google executives, Eric Schmidt and Jonathan Rosenberg, write in their book, How Google Works, “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 efficient 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 organization is viewed and operated as a network of high-performance teams.
Surprise: Agile Organizations Are Hierarchical!
One common misunderstanding is that Agile organizations are necessarily flat or non-hierarchical. In Agile organizations, the top management still has the important function of setting direction for the organization. People still get fired if they don’t get their job done. If anything, the drive for higher performance in an Agile organization is even more relentless than in a bureaucracy. In the nooks and crannies of bureaucracy, poor performers can easily hide. In the Agile organization, radical transparency enables peer-to-peer accountability.
But the hierarchy in an Agile organization is very different from the hierarchy of a bureaucracy. It’s a hierarchy of competence, not a hierarchy of authority. The performance question is not whether you have pleased your boss: the question is whether you have added value to your 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 exploit new opportunities and 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 Agile, 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 bureaucracy.
A Different Management Mindset
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 a hundred million users every week, and Barclays to start becoming an Agile bank that can provide easy, quick, convenient, personalized banking at scale.
When these three laws—the Law of Small Team, the Law of the Customer, and the Law of Networks—are in effect, people in the organization share a different understanding of how the world works and how to interact with the world in order to get things done.
For the traditional manager encountering Agile for the first time, counter-intuitive ideas abound. Managers find they can’t tell people what to do. Firms make more money by not focusing onmaking money. Dealing with big issues requires building on tiny teams. Control is enhanced by letting go of control. Leaders are less like heroic conquering warriors and more like curators or gardeners.
When traditional managers enter an Agile organization where these seeming paradoxes are the norm, it’s like travelers visiting a strange foreign country where everything is different: yes may mean no, where no one pays fixed prices, and where laughter may signify fury. The familiar cues that enable travelers to function in their home country are absent. In their place are new cues that are weird 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 find themselves disoriented and incompetent to deal with the different environment.
That’s why Agile can’t 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 just wrong. It’s like learning a strange foreign language. It is only over time and through actual experience and practice that Agile becomes second nature and automatic. This is not about “doing Agile.” It’s about “being Agile.”
Ultimately Agile is about embracing a different mindset. The importance of the Agile mindset was striking in the site visits of theLearning Consortium. When people in the organization had the right mindset, it hardly mattered what tools, processes and practices they were using, the Agile mindset made things come out right. Conversely, if they didn’t have an Agile mindset, it didn’t matter if they were implementing every tool and process and practice exactly according to the book, no benefits flowed. Agile is mindset.
The Three Laws Of Agile
Agile thus operates under three laws—one, the Law of the Small Team; two, the Law of the Customer, and three, the Law of the Network. Together they generate the basics of the Agile organization. The three laws enable 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 of Agile endures. They offer a lasting guide to what’s involved in an organization becoming Agile.
Of the three Laws, the first Law—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 software developers.
But it is the second Law— the idea that the very purpose of a firm is to deliver value to the customer— is the most important, because it is the principle that makes sense of the other two principles and that permits the greatest insight into why an Agile organization operates the way it does.
Yet the lynch-pin of Agile is really the third principle: the impact of high-performance teams and the customer focus will be sub-optimal unless the whole organization operates as an interactive network. It is when the three elements combine together and focus on a common external goal that we get the explosive increment in value that comes from truly embracing Agile.
Disclosure: I am an unpaid pro bono adviser and director of the SD Learning Consortium.
And read also:
What is Agile?
HBR’s Embrace Of Agile
Why Do Managers Hate Agile
Learning Consortium Project (November 2015)
The Best-kept Management Secret on the Planet: Agile
The Case against Agile: Ten Perennial Objections
What’s the Difference? Agile vs Scrum vs Waterfall vs Kanban