Agile Manifesto: 4 Core Values & 12 Principles Explained

The image below comes from the Agile Manifesto website and shows the four Agile value statements.

Agile Manifesto and the 4 Agile Values answer what agility is

As you can see in the preface to the values, the authors state they were discovering better ways to develop software and help others. All values are important, but those on the left are prioritized over those on the right.

Individuals and interactions over processes and tools

As previously mentioned, when the Agile Manifesto was released, it challenged heavyweight methodologies. The Capability Maturity Model (CMM) and ITIL were popular trend toward process-oriented approaches at the time.

Thus, it was surprising that these thought leaders chose to start with people. They believed that finding the right people (individuals) within a team and helping them collaborate effectively (interactions) is far more important than following any specific process and/or using particular tools. That’s why they placed the emphasis on the left: individuals and interactions.

Working software over comprehensive documentation

In traditional or waterfall software development, teams would spend significant time gathering requirements and developing designs and specifications, only building something tangible late in the lifecycle. The authors of the manifesto believed that having a working solution is more valuable than having a large collection of documents describing how the solution works.

Customer collaboration over contract negotiation

The third value is customer collaboration over contract negotiation—where contract negotiation means arguing about what’s included in the scope. For example, you might hear phrases like “That’s not what was in your requirements document.” These thought leaders believed that collaborating with our customers to deliver the solution they truly need is far more important.

Responding to change over following a plan

The fourth and final Agile value is responding to change over following a plan. The authors agree that planning is important—indeed, Agile teams do a lot of planning. But these thought leaders believed that the ability to respond to inevitable changes is more crucial than sticking to a plan made at the beginning of a project, when information is still limited.

All of these values in the manifesto are important, but those on the left take higher priority than those on the right.

12 Agile Principles

In addition to these 4 Agile values, the authors of the Agile Manifesto agreed to a set of 12 Agile Principles, which form the foundation of Agile ways of working. While less widely known than the 4 Agile values, I find the 12 Agile principles more practical and offer clearer guidance for Agile practices.

12 Agile Principles behind the Agile Manifesto

For convenience, I’ve numbered the 12 principles, though they are unnumbered on the official website.

  1. The first principle is the highest priority is to satisfy the customer through early and continuous delivery of valuable software. The phrase “valuable software” confuses some. Remember, in 2001, when these thought leaders introduced Agile values and principles, they were focused only on software development. Since then, Agile has been adopted across nearly every industry—architecture, car manufacturing, even jet fighter production. If it makes more sense to you, substitute “valuable solution” for “valuable software”.
  2. The second principle is to welcome changing requirements, even late in development. While most people today focus on controlling change or managing “scope creep,” the reality is change is inevitable. Agile processes defer decisions, shorten development cycles, and support timely analysis of requests. This allows Agile teams to adapt quickly and at low cost. This provides a competitive advantage and is one of the key pillars of Agile working.
  3. The third principle is to frequently deliver working software, from a few weeks to a few months, preferably with shorter timeframes. One of the main benefits of frequent delivery is obtaining feedback to ensure you’re on the right track and actually building what the customer needs.
  4. The fourth Agile principle is about business people and developers working together daily throughout the project. Today, business stakeholders often create requirement documents and “throw them over the wall” to developers. Months or even years later, developers deliver the solution to the requester for final testing—only to discover the solution was misinterpreted, built incorrectly, or is no longer needed. The emphasis of this principle is on collaboration between those building the solution and those using it, to avoid such outcomes.
  5. The fifth Agile principle is to build projects around motivated individuals, providing them with the environment and support they need, and trusting them to get the job done. This is essentially a three-part approach: empowering people, giving them autonomy, and trusting them.
  6. The sixth Agile principle promotes sustainable development. Sponsors, developers, and users should be able to maintain a constant pace indefinitely. When I first started working on tech projects, they often lasted 6 months, 12 months, or longer. It was common to accomplish little in the first month or two. Not surprisingly, this led to massive crunch periods at the end, where huge workloads had to be completed. Team members were expected to work evenings or weekends to meet fixed deadlines and fixed scopes. This is known as a “death march” project. Agile doesn’t say you’ll never work evenings or weekends—but it does emphasize working at a sustainable pace for everyone.
  7. Principle seven is that working software is the primary measure of progress. Traditionally, percentage completion has been used to track project progress. Percentage completion is highly unreliable because it’s difficult to judge, especially when it reaches 80% or 90%. A 90% completion often means just 10% of the effort or time remains. Agile teams avoid percentage completion by breaking work into features or functionalities, splitting them into small chunks, and tracking whether these chunks are completed. This approach avoids misleading progress metrics.
  8. The eighth principle is that the most effective and efficient way to convey information to the development team and within the team is through face-to-face conversation. Today, the most popular communication tool might be email. It’s efficient for the sender—after all, they can send messages to hundreds or thousands at once. But it’s not real communication. Research shows that reading someone else’s writing leaves significant room for misunderstanding. Agile advocates have learned that true shared understanding requires bringing people together. If face-to-face isn’t possible, use the highest-bandwidth communication available—this could be video or phone calls. This is far better than posting documents to SharePoint! The takeaway here is to use the highest-bandwidth communication channel available. A side effect of preferring face-to-face interaction is that it makes sense to colocate team members from the same Agile team. Today, many organizations overlook this seemingly obvious point.
  9. Principle nine is continuous focus on technical excellence and good design to enhance agility. The focus is on avoiding shortcuts or technical debt. Don’t do something that makes things faster in the short term but costs more in the long run. If you keep accumulating technical debt, you’ll lose agility. This is common in waterfall projects with fixed timelines. To meet promised deadlines, corners are cut. Testing cycles may be reduced or eliminated to save time, leading to more issues in production after launch. This results in firefighting and code that’s hard to maintain.
  10. Principle 10 is about keeping things simple and eliminating unnecessary work. Simplicity—the art of maximizing the amount of work not done—is essential. That is, we should examine our processes and eliminate anything that doesn’t add value to the customer, thereby maximizing the amount of uncompleted work while still delivering what’s needed.
  11. Principle 10 is also about self-organizing teams. The best architectures, requirements, and designs come from self-organizing teams. We should let those closest to the work decide how best to accomplish it—this is the essence of this principle.
  12. The final principle, number 12, is about retrospectives. Teams regularly reflect on how to become more effective and then adjust and adapt their behavior accordingly.

Agile values and principles may not seem radical today, but when they were announced in 2001, they were quite revolutionary. Hence the term “Manifesto.” They outlined a way of working that was entirely different from how organizations had operated in the previous century. Before that, software development largely mirrored industrial-era work practices. Understanding this historical context is crucial, as discussed below.