>  Blog

The Core Agile Values


Understanding the four, core values of agile methodologies, enshrined in the "Agile Manifesto".






Pradyumn Sharma

August 1, 2017



In February 2001, seventeen pioneers and practitioners of various software development methodologies came together to coin the umbrella term "agile" for the first time. The ideas from that gathering eventually led to the formation of the Agile Alliance (www.agilealliance.org), an organization devoted to promotion of agile methodologies.

In the sixteen years following that event, agile methodologies (such as Scrum, Extreme Programming, Kanban, Lean, DevOps) have become mainstream and are widely used across organizations, domains, technologies, etc.

The core values of the agile methodologies are best summed up in the Agile Manifesto, which can be found on the Agile Alliance website here (https://www.agilealliance.org/agile101/the-agile-manifesto/).

Following is the text of the Agile Manifesto:

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.

1. Individuals and interactions over processes and tools.

We need good processes to build any non-trivial software. We also need appropriate tools to build software. But great processes and great tools don't create great software; great developers do; developers who are sufficiently competent, skilled, and motivated. And the developers don't build their software in isolation from each other and the rest of the world. Developing any good software requires great deal of communication--interactions among the developers and other stakeholders.

Often people misinterpret this and other assertions of the agile manifesto, suggesting that agile software development means no process, no tools, no documentation, etc. But that is completely missing the point. So at the risk of being repetitive, let it be stated that agile methodologies recognize that we need processes, and we need tools to build any software, but individuals and interactions matter more than processes and tools do.


2. Working software over comprehensive documentation.

This is the source of one of the greatest misconceptions about agile methodologies. Many people believe that agile methodologies = no documentation. That's not true at all.

We need documentation for any system other than the most trivial ones. Users may need some documentation to refer to. Architects, designers, developers--all need documentation to refer to. Maintenance and support personnel need documentation to understand a system and solve problems. There IS value in documentation. But there is greater value in working software.

However, documentation does not solve the customer's business problem. Working software does. Therefore, the greater priority for the developers and the customer is working software. Keep this in mind while writing documentation. Create the minimal documentation required by the development team, the customer, the support personnel, etc. Don't create excessive documentation, just for the sake of it.


3. Customer collaboration over contract negotiation.

If you build some software for someone else and expect to get paid for it, you will have to negotiate the terms of the engagement. You will want to ensure that you get reasonable compensation (and more, if possible) for your efforts.The customer will want maximize the return on their investment. But more important than contract negotiation is continuous engagement and collaboration with the customer.

Great software is more likely to be built in a collaborative environment with open communication between the developers and the customer. Throwing it over the wall ("here are the requirements, go and build the software, come back to us when you are done") never works in software development.


4. Responding to change over following a plan.

To build anything except a trivial system, we need to plan. We need to understand the requirements, we need to estimate the effort involved and cost, we need to provide for the necessary resources, we need to indicate delivery dates, we may need to get people trained. Planning is important.

But we also need to remember that things change, despite the best laid plans. Customers' requirements change, priorities change, technology changes, people working on a project change. Change if inevitable. A rigid plan that does not accommodate changes such as these, never works. We need an approach to software development that does not resist change, but embraces change and lets you respond to it gracefully.

These four points from the Agile Manifesto, capture the essence of the agile methodologies quite nicely.