What are the 4 statements of the Agile Manifesto?

Below are the guiding practices that support teams in implementing and executing with agility.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

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

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity–the art of maximizing the amount of work not done–is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Become an Agile Alliance Member

Discover the many benefits of becoming a member of the leading global nonprofit organization promoting the concepts of Agile Development.

Developing software is an incredibly complex and challenging undertaking. Historically, the process has been fraught with missed deadlines, unacceptable bugs, and sometimes incomprehensible features that users would never want. In the early 2000s, these projects had reached nightmarish proportions — perhaps no better exemplified than the disastrous release of Windows Vista, a project that was a year late and a commercial failure. Projects like this were largely seen as incapable of being released successfully.

To encourage better ways of developing software, a group of 17 methodologists formed the Agile Alliance in February of 2001 in a ski lodge in Utah. The group recognized the difficulty of creating good software and wanted to instill new values into software development teams; thus the Agile Manifesto was born. The manifesto defines the values and principles software teams should adopt in order to achieve the ultimate goal of creating good software.

In this article, we present the four key values of agile development and what you need to know about them. Each value has two sides, where there is more emphasis placed on the left side of the statement than the right. A good way to think about the manifesto is that it defines values, not alternatives, encouraging developers to focus on certain areas but not eliminating others.

1. Individual and interactions over process and tools

This first value places its emphasis on teamwork and communication. Teams of people, not tools, build software systems. And to do that they need to work together effectively through productive interactions.

Tools are an important part of developing software, but think of it this way: Who do you think will develop better software? Five software developers with their own separate but unique tools working together in a single room, or five isolated individuals with a well-defined process, a common set of the most sophisticated tools, and a huge office? Obviously the team will perform better. Making great software depends much more on teamwork, regardless of the tools teams are given. Think of the motto, “A fool with a tool is still a fool.”

But don’t take this first value too literally. It’s not that tools are unnecessary. Tools and processes are still key to developing software. Without the right load testing tool or process, your team will struggle. The point is that the tool should fit the team’s needs and process — not the other way round.

2. Working software over comprehensive documentation

User: This feature is confusing and I’m not sure how to use it.

Developer: Well, you should have read the manual.

Let’s make an extreme point: documentation is a crutch that software developers rely on as an alternative for making software that works well.

Documentation definitely has its place and can be a great resource or reference for users or co-workers who are wondering what the software is and how it works. But often you might find yourself in a company where they need the documentation before you can even create the software. Those times are frustrating, and if the company is truly Agile, they need to be reminded of this value: The primary goal of software development is to create software, not documents.

Take the time to develop software that is clear, self-explanatory, and caters to the tasks that users need to get done.

3. Customer collaboration over contract negotiation

Only your customers can tell you what they want, and it’s your job to listen. Successful development teams work closely with their customers and communicate with them frequently. Of course, they will not be able to tell you the next breakthrough idea (that’s your job), but by listening and getting feedback, you will understand what they truly want out of your product.

It’s important to find ways to separate the legal relationship you have with your customers from the product relationship. Contract negotiations have their place, but they can easily create a boundary with your customer that doesn’t help you develop great software. Create a relationship with customers that encourages communication and you’ll quickly learn their thoughts, opinions, and preferences. It may make your job a little harder, but it will make the result far better.

4. Responding to change over following a plan

Change is the reality of software development — technology changes, business trends change, customers change. There is nothing wrong with a project plan — however, it must be malleable. There must be room to allow for change and to respond to it. Otherwise, your plan quickly becomes obsolete.

This makes the job as a tester a little more difficult because in Agile the project or plan becomes very fluid. Developers are the first ones to note the change in the plan and make the decision to alter the code. This in turn affects the testers as they need to change their testing plans accordingly. But sometimes there is a break in communication between testers and developers which often leaves testers under pressure simply because they did not know what was happening to the plan soon enough.

To fix that, you need to refer back to the first value of this manifesto: communicate effectively with the entire team. It’s more of taking a proactive approach when it comes to testing, meaning actively reaching out to developers on your team to be in the loop of new changes or course of actions.

Not everyone is Agile

The interesting thing about these value statements is that most organizations completely agree with them, yet will rarely adhere to them in practice. Some senior management claim that creating software is the fundamental goal of the business but will insist on spending months producing documentation describing the software instead of building it. Just keep in mind the ultimate goal of your project, and if you are required to do something that hinders that goal, bring it up with your team and remind them of these four values.

This post was originally published in 2014 and was most recently updated in July 2021.

What are the 4 Agile Manifesto?

Which statement is a principle of Agile Manifesto?

How many principles emerged from the 4 Agile Manifesto values?

What are the four things require in Agile ethics?