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