What Is the Agile Manifesto?

In 2001, a group of 17 “lightweight” methodologists met in Snowbird, Utah, to discuss their approaches to delivering software. This group of people consisted of representatives from eXtreme Programming (XP), Scrum, DSDM, Adaptive Software Development, and others “sympathetic to the need for an alternative to documentation driven, heavyweight software development process.”Jim Highsmith says that most of the agile principles boil down to “mushy stuff” and that “the meteoric rise of interest in and sometimes tremendous criticism of Agile Methodologies is about the mushy stuff of values and culture. After much discussion about said mushy stuff and the ways in which they were creating software, the Agile Manifesto was written:

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.

Kent Beck

Mike Beedle

Arie van Bennekum

Alistair Cockburn

Ward Cunningham

Martin Fowler

James Grenning

Jim Highsmith

Andrew Hunt

Ron Jeffries

Jon Kern

Brian Marick

Robert C. Martin

Steve Mellor

Ken Schwaber

Jeff Sutherland

Dave Thomas

Although the four value statements are discussed in the following sections, we feel that it is important to emphasize the last statement of the Manifesto. The writers were not claiming that agile teams do not write documentation, for example, although this myth surrounds agile teams. Rather, agile teams question the value of the documentation that they have traditionally produced, and whittle that away to only write documentation that is useful and valuable, such as tests or high-level designs, or end-user documentation deliverables such as online help or manuals. When thinking about the last statement of the Manifesto, it is important to remember to stress the items on the left as value statements and employ the items on the right as needed and when they add value. Now let’s explore the Agile Manifesto in more depth.

Individuals and Interactions over Processes and Tools

This first value of the manifesto underscores the importance of individuals and interactions when building software systems. All agile approaches focus on empowered, self-managing teams; autonomous teams do not need the day-to-day intervention of management. Instead, if management protects a team from outside interference, and focuses on removing obstacles in the way of creating product, teams become highly effective and productive. Additionally, it is widely accepted that complex systems cannot be predicted and that they’re best managed using empirical process controls; therefore, management allows self-managing agile teams to build systems in an empirical manner.

Agile teams are empowered to make the necessary decisions in order to get the work done. Takeuchi and Nonaka referred to this as “self-transcendent,” meaning that the team should be in a “never-ending quest to find the limit.” Empowered teams take the guidelines that management gives them and create their own goals from those directives; they find a way around a problem through devising unique solutions as a team.

Agile teams are composed of a mix of skills—everyone necessary to create the product increment is on the team. This means that an agile team is composed of developers, testers, database experts, writers, business analysts, user interface experts, and other skilled professionals. Through working together daily to meet the goals of the iteration, the individuals on the team start to create a shared direction for the product. Ideas overlap. Leadership emerges. Agile team members are able to step in for each other as necessary; they create the system as a team and not as a series of handoffs that we normally associate with a serial process. They apply what they’ve learned, and the collective knowledge grows; design, quality and productivity is improved as a result.

Humans have tried to create tools to replace face-to-face communication. From collaboration portals, to online communities, to virtual whiteboards, the tech space abounds with products to help us get better at communicating. Unfortunately, for many, these tools have been touted as the penultimate communication vehicle. What many teams have learned, however, is that practicing ventriloquism through tool and process marionettes has created phenomenal waste in our product development processes. The Agile Manifesto, by focusing on individuals and interactions, forces teams to rethink the best approaches to communication, realizing the power of team members collaborating in person to solve a mutual problem. And when the team members aren’t face to face (this is indeed a global market), tools can help support—not replace—those conversations. Never underestimate the value of a simple phone call.

Working Software over Comprehensive Documentation

Agile projects value working software, which is a profoundly different emphasis from traditional, phased projects. Traditionally, one would measure a project’s progress by the percent complete of the functional milestones (that is, analysis complete, documentation complete, code complete, and so on). In agile projects, however, working software is the ultimate quantification of project status. Instead of status meetings where everyone reports, “I’m 90 percent complete,” agile teams provide actual working product as a status report, called a “product review,” at the end of each iteration. Inspecting software that works enables us to respond appropriately to the true state of the project. Everything is visible; decisions can be made based on product that exists, not documented representations thereof.

This value statement of the Agile Manifesto is two-fold; the second idea behind this statement is that many teams consider some documentation wasteful. In fact, we’ve been told very directly by some developers that they don’t need “no stinkin’ specs.” In business terms, spending lots of time up front to capture every design detail in a specification can be a waste of time. Most agile teams say that design changes as the system is built, which results in outdated documentation; therefore, why waste time documenting ideas that will most likely change as implementation begins, and as customer feedback is received? The famous Standish Group finding that more than “60% of software functionality is rarely or never used” speaks to the waste introduced by comprehensive documentation. How is this so? Well, in traditional projects when the scope is defined up front, the scope is protected in order to keep the project “on schedule and within budget,” even when the features defined up front need to change or even be dropped based on changes in the customer’s environment. Therefore, why should we develop something that will not be used by our customers? In fact, why even write about it?

One developer stated it very succinctly:

If someone hands me a 40-page document and tells me to go code, I won’t know what to work on first. In fact, I would probably tackle the architecture stuff first, or maybe I’d work on something that was interesting and exciting to me. It probably won’t be the most valuable feature for the customer. So now the waste of writing the document is compounded by the waste of me coding whatever it is that I think I should start with—and it probably won’t be the right thing.

Besides the waste factor, agile teams prefer face-to-face communication over documentation because it is simpler, faster, and more reliable.

With that said, there are various forms of documentation that teams consider valuable within the context of their organization. For example, one organization could not live without end-user documentation; in fact, it was so important that it became a criterion that each feature had to pass in order to be accepted at the end of each iteration. Another team decided to document its decisions every iteration because it had just previously lost five valuable team members to a hostile team takeover. And yet another organization had to pass government regulatory compliance, so it had to work with its auditors to find the “right” level of documentation that could pass audits. Even though the stress is on working software, all documentation is not bad. If in doubt, ask the team: Is it valuable? Are we better off for writing it? Are we obligated by law, and, if so, how can we find out what is the minimum we can do?

Customer Collaboration over Contract Negotiation

Contract negotiation in the traditional sense means that we identify and define everything the customer wants and then draw up the contract that spells out the payment and date specifications. This has resulted in many fixed-price/fixed-scope situations. What we have learned is that this isn’t always the best approach for software development projects. Too many teams have found themselves in death-march situations, working 80 hours a week to meet the deadline set forth in the contract—a contract that was estimated and agreed to by somebody other than the team in the first place. Just as bad, customers have found themselves committed to work that no longer makes sense, all in the name of a contract.

Agile “customer collaboration,” on the other hand, implies that customers become a part of the development process. To develop the right system, customer feedback is essential. Agile teams value the contributions made by the customer—or the customer representative—and learn to let the customer make the business decision. In turn, customers rely on important technical information that the team can provide in order to make appropriate decisions. Sometimes customers don’t know what they want until they can see it.

We see a tremendous focus on contracts these days that are better suited for agile projects. Mary Poppendieck talks about building in cost responsibility for both parties, based on Toyota’s contracting examples with its die makers. Their contracts are written based on a target cost principle—that once the target cost of the contract has been met, Toyota and the customer share the excessive cost of change. This is an incentive for both parties to minimize the cost of change, yet recognizes and allows it to happen. Another type of contract—the “staged contract”—allows for built-in checkpoints in the contract to provide the customer visibility and go/no-go decision points along the way. These contract types are not new, but they are gaining more visibility as more viable alternatives for software development teams.

Teams can build a system that meets the customer’s needs if the customer provides feedback and guides them along the way. Writing specs down and throwing them over the fence is simply not effective, and has landed many a team in the position of working overtime to fix the system to meet the needs of the customer. Perhaps, if the customer had been involved along the way, the team wouldn’t be in such a predicament. We’ve coached many teams who have ended up in this situation and are using agile methods as a way of changing this.

Responding to Change over Following a Plan

It’s much easier to respond to change when the organization and the customer share a clear understanding of the project’s status. Focusing on increments of working software and collaborating with the customer allow development teams to more readily respond to change.

In plan-driven environments, all requirements are specified up front, broken down to the task level and estimated. Costs and dates are calculated bottom-up from these very granular tasks. The resulting schedule becomes a baseline for the project and is utilized to measure the project’s performance. Therefore, it is very important to stay on task and control scope creep in a plan-driven project setting to limit or eliminate cost overruns or schedule slippage.

Source: Software Project Manager’s Bridge to Agility

Chapter 1. What Is “Agile”?

In the struggle for survival, the fittest win out at the expense of their rivals because they succeed in adapting themselves best to their environmen

—Charles Darwin

Darwin’s famous voyage on the HMS Beagle took four years, nine months, and five days, ending in 1836. We are all familiar with the story: Darwin set sail and discovered unique species of plants and animals in South America and other regions of the world, resulting in years of work that culminated in his Theory of Evolution.[1] Darwin began his adventure much to the disappointment of his family, who felt that it would delay his anticipated admission into the clergy. After his return from the voyage, and aware of the Victorians’ strong belief in the divine, he kept his emerging theories quiet for twenty years while he studied barnacles to derive enough data to one day prove and thoroughly support his point. He knew the uproar that his thoughts and beliefs (or disbeliefs!) would create.

The rest is history, as the cliché goes. Darwin’s theories were so profound, so prolific, that they still fuel debates in school systems and in medical research around the globe today. His discoveries threatened the religious norms of the time and prod at that belief system today, more than 125 years since his death.

Darwin’s voyage is like the project manager’s walk across the bridge to agility: the leap of faith, venturing out into the unknown, the process of discovery, and the sometimes unpredictable results. Both Darwin and the new agile project manager wonder about what to make of their newfound knowledge and how to blend that knowledge within the current context of society or the business organization.

Even though agile ways of doing development have been around since the 1960s, only recently has the agile movement gained so much momentum that one in seven companies is piloting or exploring the methods.[2] We are living in a time of a major movement within the software industry. This movement has caused many project managers to investigate what it means to be “agile.” What they find is that, like Darwin’s discoveries, agile methodologies are different from the traditional norms of software development, norms that often represent the societal structure for their business organizations. For some of you reading this book, agile methodologies will be a completely new island; yet, for others, the approaches might represent a way of working with which you’re already familiar.

One trip to the Agile Manifesto web page yields thousands of names of supporters of the process. A random sampling of the comments on that web page produce quotes such as “The Agile Manifesto is an important first step in reforging the craft of software development.”[3] And, as evidenced by the thousands of postings, the support is global: “Me siento feliz porque nuevamente me siento emocionado por los avances en mi profesion.” (I feel happy because again I feel touched by the advances in my profesion [sic].)[4]

Although agile has a lot of support, it also has its fair share of critics who believe that it is a fad and does not work. There are websites and blogs from people who insist that a plan-driven, prescriptive approach is more appropriate for delivering software. Our experiences have shown that successful agile projects and agile teams exist all over the world. It is our opinion that when teams are supported by management, and can interact with the customer, they are much more successful than teams who create software using a sequential, prescriptive approach.

We realize that traditional project managers with no agile experience who visit an agile team’s room for the first time must feel a bit like Darwin when he discovered the unique creatures and life on the Galapagos Islands, as the landscape is quite different: Teams deliver incremental product releases, which allow the organization to be responsive and proactive in resolving issues; teams are safe places for individuals whereby trust, collaboration, and hard work are the founding values; people talk to each other.

This chapter provides you with a solid understanding of the origins, values, and principles of agile methods so that you will understand what the other island looks like.