Agile for Everybody

Chapter 1. What Is Agile, and Why Does It Matter?

Understanding Agile as a Movement

On February 11–13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground—and of course, to eat.

So begins the story of the Agile movement as told by one of its originators, Jim Highsmith. 

It is worth taking a moment to reflect on the humility—and humanity—of this statement. The Agile movement was not born out of an ambition to sell books or rack up consulting hours. It was born out of the very belief that animates its most successful implementations: when people come together, look beyond the tactical differences in their respective approaches, and seek common ground, amazing things can happen.

The 17 people who gathered at Snowbird had spent the better part of the prior decade looking for ways to bring this kind of collaboration to their day-to-day work as software developers. Some of them had begun implementing daily “stand-up” meetings to create more space for regular conversation. Some of them were encouraging their colleagues to work in pairs, maximizing the transfer of knowledge and revealing previously unseen solutions. Some of them were looking at how organizational processes themselves could become “stretch to fit” to better suit the needs of the specific individuals on a given team.

By the time the Snowbird summit took place, some of these practices had evolved into fully formed methodologies with names like Scrum, Extreme Programming, and Crystal. But those gathered at Snowbird were not interested in debating which of their methodologies was the best. Instead, they wanted to see if 17 self-described “organizational anarchists” could identify the common themes, values, and principles underlying their respective practices, frameworks, and methodologies. By all accounts, nobody thought this would be an easy task.

To the great surprise of many people in attendance, deciding on a shared set of values proved much less contentious than deciding where to hold the summit in the first place. By the end of their gathering, this group had agreed upon a word to describe the ideas that connected and united their respective approaches: Agile. And they had captured their shared values in a document called the Manifesto for Agile Software Development.

Here is the text of what has come to be known colloquially as “the Agile Manifesto,” in its entirety:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

That’s it. Sixty-eight words. Note that none of these words speak to specific practices, tools, or methodologies, except to say that tools are explicitly less valuable than people. According to Highsmith, this was no accident:

At the core, I believe Agile Methodologists are really about “mushy” stuff—about delivering good products to customers by operating in an environment that does more than talk about “people as our most important asset” but actually “acts” as if people were the most important, and lose the word “asset.” So in the final analysis, the meteoric rise of interest in—and sometimes tremendous criticism of—Agile Methodologies is about the mushy stuff of values and culture.

At the heart of the Agile movement, in both its substance and its history, is the belief that hard methodologies and “mushy” values cannot and should not be disentangled from each other. Methodologies must be driven by culture and values, and culture and values must be enacted through tangible practices.

It is for this very reason that I bristle a little bit whenever I hear Agile referred to as simply a “methodology.” Yes, there are a number of methodologies—including the aforementioned Scrum, Extreme Programming, and Crystal, as well as those more recently developed, such as SAFe and LeSS—that provide a blueprint for how we can put Agile values into practice. But you need not look all that closely at the 68 words of the Agile Manifesto to understand why framing Agile as a process or a tool can easily miss the point.

I have also heard Agile referred to as a “mindset.” While I agree that Agile requires a substantial shift in thinking, I feel like describing it as a “mindset” lets us off the hook too easily. Just thinking in an Agile way is not enough, and it leaves an awful lot of room for us to say, “Well, I understand this whole Agile thing, but the people I’m working with just haven’t adopted this new mindset, so there’s nothing we can do about it!” Table 1-1 compares these different approaches to Agile, and demonstrates how framing Agile as a movement makes it possible for us to change both our methodology and our mindset, and to keep these two dimensions synchronized as we go.

Table 1-1. Agile as a methodology, a mindset, and a movement

Agile as a methodology	Agile as a mindset	Agile as a movement
Practices matter more than mindset.	Mindset matters more than practices.	Mindset and practices are inexorably connected.
The practices and methods of Agile were already determined by others.	The principles and values of Agile were already determined by others.	I have an active role to play in determining how Agile principles and practices are articulated and applied in my team or organization.
Individuals within teams must collaborate and interact in prescribed and predefined ways.	Individuals within teams must independently develop an Agile “mindset.”	Individuals within teams must work together toward a shared set of goals and values.

For all of these reasons, I am inclined to agree with Highsmith himself when he describes Agile as a movement. Embracing Agile as a movement helps us to better understand our own responsibilities around bringing its practices and principles to our own work in several ways:

Agile is a single movement that emerged from parallel innovation

Much like other important movements in work, culture, and art, Agile emerged when multiple practitioners developed independent but parallel innovations in response to changes in the world around them. The impressionist painting movement, for example, emerged as a number of painters reacted in parallel against the rigid academic rules of the time, and to the popularization of photography. Similarly, the Agile movement emerged as a number of software developers reacted in parallel against the rigid conditions of corporate work, and to the accelerating pace of technological change, as shown in Figure 1-1. Seeing Agile through the lens of parallel innovation helps us to understand how our own contributions can continue to push the movement forward.

Figure 1-1. A partial timeline of Agile frameworks and methodologies by the year they are widely considered to have been formalized. Note how new frameworks and methodologies have continued to emerge and evolve after the movement’s founding.

Agile demands both thought and action

When we think of Agile as a movement, it sets a high bar for both thought and action. Movements require a new way of thinking and a new way of working, and they demand that we keep these two things constantly synchronized with each other. If we do the work thoughtlessly, we are at best making minor operational tweaks. And if we do not support our thought with action, we are creating a deep and dangerous divide between what we say and what we do.

Agile compels us to work together toward a greater good

Framing Agile as a movement makes it clear that it is something we must do together. Agile asks us to be open, collaborative, and reflective. It asks us to look beyond the “correct” implementation of processes and tools, accept our uniqueness and complexity as individuals, and find ways in which we can work together toward a greater good—just as the signers of the Agile Manifesto did when they gathered in Utah.

In many ways, the story of the Agile movement contains within itself the blueprint for a successful implementation of Agile: accept the fact that different teams benefit from different tactical approaches, find common ground in shared values, and keep moving forward.

Unpacking the Appeal of Agile

The Agile Alliance, an organization formed by the 17 signers of the Agile Manifesto, defines Agile simply as “the ability to create and respond to change in order to succeed in an uncertain and turbulent environment.”

It is not terribly difficult to see why this is so compelling to modern organizations. The idea that our world is faster-paced, more connected, and more customer-driven than ever before is table stakes for any contemporary discussion about organizational design and culture. Modern organizations—especially large, slow-moving enterprises—exist in constant terror of being “disrupted” by smaller and more adaptable players. The sense of urgency around becoming faster, more flexible, and more customer-centric is real. And Agile provides a material answer to the question, “How can we be more like the cutting-edge technology companies and startups that might put us out of business?”

However, the idea that Agile is some kind of magical secret that provides high-tech companies with an intrinsic competitive advantage is a gross and misleading oversimplification. Many of the folks I’ve worked with at large traditional companies are genuinely shocked to hear that the technology companies that they both fear and idolize are not the egalitarian hives of free-snack-fueled innovation that you read about in rosy PR statements or fawning press profiles. For better or worse, these companies often face many of the same underlying challenges that more traditional companies do: a tendency to  be more management-centric than customer-centric, organizational silos that stifle collaboration, and resistance to change after a project is set in motion.

Many folks I’ve worked with are also surprised and disheartened to hear that “working like a small startup” in no way guarantees a successful realization of Agile values. Startup founders, especially those puffed up by millions of dollars in venture funding and our current cultural obsession with entrepreneurship, can be among the least genuinely adaptable people I’ve ever met. For better or worse, a high-tech organization of five people can be just as insular, noncommunicative, and set in its ways as a traditional business of 5,000 people.

Ultimately, embracing a truly Agile approach means giving up on the idea that any set of rules or practices will confer an immediate competitive advantage or high-tech halo. It’s all right there in the first sentence of the Agile Manifesto: our teams and organizations are much more a product of the people we work with than they are a product of the processes we implement. At its best, Agile can remove some of the friction that comes from working against the fast-moving and unpredictable nature of the world around us, making it easier for individuals and teams to do their best work. But Agile cannot turn a bank into a search engine or an enterprise into a startup.

Escaping Business as Usual

The Agile Manifesto states unequivocally that individuals and interactions are to be valued above processes and tools. And while this statement of values is easy to agree with in theory, it presents some enormous challenges in practice. Processes and tools are generally visible, material, and relatively easy to change. But the forces shaping individuals and their interactions are often invisible, unspoken, and very difficult to change. It is very rare that somebody will come out and say, for example, “I might get fired if I tell my boss about the negative feedback I received from a customer, so I will intentionally withhold that feedback.” But it is not at all uncommon for individuals working in organizations to be very selective about what information they actually provide to their managers—or seek out from customers in the first place. Their managers, meanwhile, are often left wondering, “Why didn’t anybody tell me that this was a bad idea?”

Scenarios like this continue to play out day after day in organization after organization, regardless of the fancy frameworks and shiny high-tech tools those organizations adopt. Even in organizations whose leadership is committed to pursuing meaningful change, the forces keeping people tethered to “business as usual” can feel as pervasive and inescapable as gravity itself. Thus, they are often manifest in what I call the Three Laws of Organizational Gravity:

• Individuals in an organization will avoid customer-facing work if it is not aligned with their day-to-day responsibilities and incentives.

• Individuals in an organization will prioritize the work that they can complete most easily within the comfort of their own team or silo.

• A project in motion will stay in motion unless acted upon by the senior-most person who approved it.

The example described earlier is one manifestation of the Third Law of Organizational Gravity: if somebody’s manager approved a project, that person is unlikely to call that project into question, regardless of what they hear from customers—and, ultimately, regardless of how their manager might actually react upon hearing this feedback. We are creatures of habit, and many modern organizations represent the sum total of the habits and expectations we’ve built up after years of navigating “business as usual.”

Framing up these dynamics as a matter of organizational gravity helps us unpack the all-too-common situations in which the path of least resistance feels irreconcilably at odds with the best interest of our colleagues and our customers. It helps build empathy and understanding for organizational leaders whose attempts to manage this tension might seem hypocritical or duplicitous. And it helps us understand how our own day-to-day behaviors might be contributing to the very problems we are trying to solve. In Chapters 3 through 5 we take a closer look at each of the Three Laws of Organizational Gravity and discuss how our guiding principles of Agile can help us escape them.

Agile Versus Waterfall

The practices associated with the Agile movement are often presented as an alternative to traditional Waterfall approaches to product and project management. The comparison usually goes like this: in a Waterfall approach, each stage of a product or project’s development is executed by a separate team with a separate, distinct skill set. A team of business or subject matter experts, for example, might be responsible for creating the initial plan for a product. They then hand it off to another team, which is responsible for designing that product. That team then hands it off to yet another team that handles building the product. It is often months, or even years, before anything is actually finished—but the thing that is finished, at least in theory, is the exact thing that was initially planned.

An Agile approach, by contrast, involves a cross-functional team releasing smaller finished outputs in shorter cycles, as shown in Figure 1-2. The term “cross-functional” usually denotes a team in which all the skills needed to see a project through from planning to execution are represented in a single team. This team works together to complete smaller outputs within finite and consistent periods  of time, often called time boxes. The output of each time box is released to its intended audience, and the feedback gathered from that audience is used to direct and prioritize future time-boxed outputs,  often called iterations. Thus, something of value can be delivered quickly—but as time goes on, the “completed” product or project can deviate substantially from the initial plan.

Figure 1-2. Waterfall (left) involves multiple handoffs between specialized teams, leading to a single highly planned release. Agile (right) involves a cross-functional team releasing more frequently, gathering feedback, and adjusting course as needed.

By way of example, imagine that you were building a website for a brick-and-mortar retail company. In a traditional Waterfall approach, you would create a lengthy specification, or “spec,” which is a document that outlines exactly the features you want on your website, how you want those features to work, and what you want the overall look and feel of the site to be. You would then hand off that spec to a team of designers, who would provide a visual mockup of the site’s specific pages and elements. After you approve those mockups, you would then hand them off to a team of developers, who would transform them into a functioning website that matches as closely as possible the original spec you wrote. In six months, you would have a fully functioning website.

Now, let’s imagine that you were building that same website using an Agile approach. The team tasked with creating the site would include both designers and developers, and you would be working with them to prioritize smaller releases based on your needs and those of your customers. You might decide, for example, to spend your first two-week time box creating a basic landing page that provides customers with information about your store. You might then decide to spend your next two-week time box creating a simple email mailing list with weekly specials and offers. In four weeks, you might have something that is already contributing to the growth of your business, even if it is not the full-featured website you had in mind.

It is, frankly, difficult to compare Agile and Waterfall in a way that doesn’t seem to give the clear advantage to Agile. In theory, meticulously prioritized and tightly scoped releases always seem more appealing than hundred-page specs, transactional handoffs, and months-long project plans.

In practice, though, it is rarely this simple. Imagine, for example, that you are working on a product in a highly regulated industry such as banking or medicine. A basic legal review might require months of time from a team of very well-compensated lawyers. If those lawyers don’t have a chance to review a complete and comprehensive project plan, there is a high likelihood that your design and engineering teams will produce something that simply cannot be released, resulting in lost time and lost money. How are you supposed to be Agile in such an environment?

These challenges become even more confounding for teams that are not building a product in the traditional sense. Marketing and sales teams, for example, are often highly dependent upon yearly budgeting cycles. Agencies working on major ad campaigns must work backward from fixed deadlines and incorporate both structured and ad hoc feedback from their clients. In the real world, even our best Agile intentions rarely lead us to something that looks or feels like a bunch of neat little circles in a row. When we approach Agile as an absolute and inflexible set of operational rules, small but positive changes to the way we work can feel like trivial steps toward an end state that is perpetually out of reach. When we take a principles-first approach to Agile, small but positive changes to the way we work can create a powerful sense of momentum and possibility.

For these reasons, it is important that we look for opportunities to apply the principles of Agile to our day-to-day work even if a textbook Agile approach seems impossible. If, for example, we are organized into large and functionally siloed teams, how can we encourage more interaction across teams? How can we make each handoff between teams more collaborative and less transactional? And how can we more closely involve our customer every step of the way?

Agile, Lean, and Design Thinking

Unsurprisingly, the signers of the Agile Manifesto are not the only people who have spent the past couple of decades thinking about new ways of working. Along with Agile, several adjacent movements and approaches, including but not limited to Lean and Design Thinking, have come to prominence as organizations look for new ways to work quickly and adaptably.

The Lean movement traces its origins back to the automobile manufacturers of the early 20th century, who sought to minimize waste and overproduction. Lean manufacturing provided some of the inspiration for foundational Agile methodologies such as Scrum and was explicitly applied to the world of Agile software development in 2003 when Mary and Tom Poppendieck published Lean Software Development: An Agile Toolkit. In 2011, Eric Ries extended the Lean movement further beyond its manufacturing roots with the publication of The Lean Startup, a popular business title arguing that, in today’s environment of great uncertainty, anything that does not contribute to learning about customers is, in Lean parlance, waste.

Design Thinking is, in the words of IDEO CEO Tim Brown, “a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.” In practice, Design Thinking often involves conducting interviews to better understand customer needs, brainstorming several potential solutions, and rapidly prototyping these solutions to test for usability and desirability.

Extending the idea of “parallel innovation” that birthed the Agile movement, we can see how these movements are in many ways addressing the same fundamental question: how can organizations adapt to meet the needs of customers in a fast-changing world? Though each of these movements answers the question slightly differently, they are all driven by a similar set of values around customer centricity, collaboration, and openness to change. 

As product designer and researcher Dr. Anna Harrison pointed out to me, perhaps the most meaningful difference in these approaches is not the approaches themselves, but rather how organizations measure their respective success, as shown in Figure 1-3. Broadly speaking, organizations tend to measure the success of Agile initiatives by velocity, or the speed at which they can release products to market. Organizations tend to measure the success of a Lean initiative by efficiency, or the amount of waste they can eliminate from the production process. And organizations tend to measure the success of a Design Thinking initiative by usability, or the amount of value their products can provide to customers.

Figure 1-3. Agile and adjacent movements mapped to the success metrics against which they are commonly measured. This can be a helpful diagnostic for understanding an organization’s perceived priorities.

Which of these three movements an organization first chooses to pursue is sometimes a sign of which of these three success metrics it perceives to be most important. Other times, it is simply a matter of which book or article an organizational leader happens to have read first. It is not uncommon for different teams within an organization to find themselves separately exploring the principles and practices of these movements at the same time. A product team, for example, might find itself in a series of Lean Startup workshops, only for its counterparts in marketing to kick off an Agile marketing initiative. Or, perhaps more commonly, an organization might be putting its engineers through Agile training and its product managers and designers through Design Thinking training, leaving both groups with a whole lot of questions about whether these approaches are duplicative, complementary, or in conflict with one another.

It is only through grappling with these questions that many organizations come to realize just how closely aligned these three movements are, and that it is ultimately up to them to implement principles and practices from each that best meet their specific needs and goals. As IBM Distinguished Engineer Bill Higgins told me, “After working with both Agile and Design Thinking, we got to the point of saying that the outcomes of these two approaches are highly aligned. The differences tend to be in some of the terminology—oftentimes different terms for some of the same concepts.”

All of which is to say that if you’re worried about choosing the wrong approach—don’t be. Many of the concepts discussed in this book will overlap substantially with those you may encounter in books and articles about Lean or Design Thinking or other approaches to organizational design and leadership such as Six Sigma. When you have a clear sense of the change you want to see in your team or organization, and the values that you believe will drive that change, you will likely find something useful in every different approach you encounter. The challenge is not so much to select which approach is the most correct, but rather to be clear enough in your own objectives that you can find the elements of each approach that are best suited to your particular needs and goals.

Summary: Agile Made Simple (But Not Easy)

The world of Agile can seem like a dizzying tangle of methodologies, frameworks, rules, and rituals. But the expansive nature of Agile is in no way a symptom of intrinsic complexity—in fact, quite the opposite is true. The tactics of Agile can seem so complex and contradictory precisely because the underlying values of Agile are so simple, accessible, and broadly applicable. Within this set of values there is plenty of room for a wide, diverse, and differentiated set of approaches, which makes it possible for us to bring Agile to teams and organizations with a wide, diverse, and differentiated set of needs. When we approach Agile as a movement driven by values and principles, we are insisting that there is also room for us to figure out how best to put these values and principles into practice in a way that meets the needs of our particular teams and organizations. In doing so, we take on the responsibility of serving as active stewards of the Agile movement, not just passive followers.