The 12 Principles of Agile Methods

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Few of us would argue that satisfying the customer is unimportant. The distinctive feature of this principle is the means by which the Agile methods pursue that goal.
“… through early…delivery of…software.” Agile methods tend to shun  long upfront requirements development and design activities. Rather, after laying an appropriate foundation (“appropriate” being defined differently for each method), they seek to develop working software as quickly as possible.

In essence, these methods replace the traditional requirements and design phases of development with early proof-of-concept activities. The Agile methods look very much like prototyping projects but with the distinction that the resulting product is delivered for use, instead of being thrown away.

“… through … continuous delivery of … software.” Agile methods all assume an incremental development strategy. They seek to mitigate risk by delivering increments quickly and often (every couple of weeks to every couple of months) so that the customer can validate the project’s decisions and assumptions and verify the utility of the resulting software.
“… through … delivery of valuable software.” Most Agile methods allow the customer to define what is most valuable and give the customer a significant role in establishing the order in which features are delivered.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

This is the core principle on which the Agile methods are built and the reason why the name “Agile” was adopted. This principle acknowledges the fact that change is inevitable and establishes the philosophy that encouraging regular change is an advantage of the Agile methods for their customers. Rather than trying to suppress or control change, the Agile Methods are designed to allow—even encourage—change throughout the project’s life.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
This principle expands on the “continuous delivery” phrase from the first principle. It is explicit that the increments on Agile projects should be as short as possible and goes so far as to say that a week or two is not too short for an increment. It also sets an upper limit that might be surprising to many, since development phases of fewer than three months are generally not seen.

Business people and developers must work together daily throughout the project.
The Agile methods all require collaboration between the development team and the other stakeholders in the project. A most crucial role in Agile projects is given to the customer (or the ultimate user of the system being developed). But all other stakeholders (identified by these technophiles as “business people”) have important roles and are expected to interact with the team on a regular basis.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The Agile methods are all built on the assumption that development team members are all competent, motivated, supported by the organization, and empowered to do their jobs. At the same time, each method builds an environment that is intrinsically motivating to the technical staff and has the natural effect of building each staff member’s capability to self-motivate and self-manage.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
This is the principle that explains why the Agile methods tend to have few written documents. They all favor face-to-face communication as the primary means of sharing information, often supplementing it with tools such as whiteboards. The results of communication are often documented in the form of “information radiators,” which are visually available postings of information to which people can refer whenever it is needed.

Working software is the primary measure of progress.
This principle is another way in which the Agile methods strike against documentation. Most software projects will identify the acceptance of a requirements or design specification as a milestone showing significant progress. Many Agile methods (though not all) reject that idea. They tend to place little value on the project’s interim products and focus almost entirely on the resulting software. Of course, since working software is delivered so often on an Agile project (see the third principle), it becomes a reasonable
measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
In many organizations, overtime is the norm, and in some it is routinely required. The Agile methods rebel against those norms and argue instead for “sustainable” schedules (generally meaning something in the vicinity of 40 hours per week). And by this they do not mean to plan for 40 hours per week, then work 80; rather, they mean to change the expectation of what can be accomplished so that overtime is rare. But as this principle states, the nature of the Agile methods tends to level out the demands on the project team so that a more sustainable pace is naturally maintained.

Continuous attention to technical excellence and good design enhances agility.
This is perhaps the most valuable principle of the Agile methods. Each Agile method has a strong focus on ensuring that the quality of the technical work is maintained at a high level. The different methods do this in different ways, but each has a strong quality component.

This principle provides a refreshing counterpoint to the all-too-common perception that the developers’ job is to write the software and someone else is responsible for making sure it works. In the Agile methods, development teams take on the primary responsibility to be sure that what is delivered is correct and that the software satisfies the customer’s needs. This focus does not mean that independent verification and validation is unnecessary; rather, it means that the software that is delivered for IV&V will be of higher quality and generally more ready for final testing.

Simplicity—the art of maximizing the amount of work not done is essential.
Before the Agile Manifesto was written, the methods that fall under the “Agile” umbrella were generally referred to as “light” methods. The term “light” was dropped out of recognition that certain application domains require heavier processes (e.g., developing software for safety-critical systems). Even so, the Agile methods always stress using the lightest possible processes.

The best architectures, requirements, and designs emerge from self-organizing teams.
Self-management is a hallmark of Agile methods and a backlash against the command-and-control methods used to manage many software projects. There is growing evidence that self-managed teams are in fact quite effective.

But moving toward self-managed teams requires significant changes throughout the organization. The most significant change occurs in the ranks of management, where managers’ roles must evolve toward coaching and leading, as engineers’ roles grow to include self-management. These changes are difficult to effect and require that many people learn new skills and behaviors, but they can have significant positive results.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
The concept of retrospective or postmortem analysis is well known in the industry (if not widely practiced). The Agile methods adopt this important activity as their primary means of improving their processes. Some Agile methods take this to an extreme by doing these analyses at the end of each increment of development, resulting in lessons learned and process improvements many times each year.