Understanding Agile Manifesto

In February 2001, seventeen software developers met at ski resort in Utah with the objective to find better ways to develop softwares. In their discussion they found consensus on four major values, now known as “Agile Manifesto”. All of us who practice agile, might have these values on our tips but its always good to periodically look at these values and check what they mean to us today.Agile Process

The four values of Agile Manifesto :

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. 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.

One good way to look into manifesto is, it defines preferences, not alternatives, encourages focus on particular area but does not eliminates others. It does not eliminate value in items on the right, it just encourages focus on the ones at left which can lead to a better software quality with high success rate. Lets discuss the each value in a bit of detail.

Individuals and interactions over process and tools : 

Softwares are built by team of people and to do that effectively they need to work together. As with the time processes and sophisticated tools were developed, focus shifted from individuals to tools and processes. Vendors are selling tools and processes as a solution. But all along it is still people who develops solutions. There is an old saying “A fool with a tool is still a fool”. So to me this point means  that the tools and processes should be minimum needed for a given situation. The focus should be more on individuals and interaction between them. For example QA team should not be isolated from dev team and similarly any other team committed to the delivery of product.

Working software over comprehensive documentation:

In a traditional waterfall model, customer is asked to explain the requirements and document it. Then the implementation team develop and test the software as per the documented requirements. Virtually its impossible for customer (infact anyone) to document the software they need. Even if it is, the requirements may change with the time and at the time of delivery customer might have different requirements as per the market at that time. The agile approach of building increments of ship-able product is very effective. At the end of every sprint customer can see the product and hence can come up with more idea or improvements he need for next sprint. This also builds the confidence of customer. But still there is some minimum documentation required. The question is, how much ? Agile says minimum documentation should be required for any software.

 Customer collaboration over contract negotiation:

Sometimes this statement is misunderstood as “we don’t need contracts and all collaboration is informal” which is not true. To me it means, our contracts should be flexible to accommodate the changes. Even with fixed price projects we can have flexible contracts. The changes can be discussed in sprint planning meeting and approvals can be taken for those.

Responding to change over following a plan:

Plans are made so complex and detailed that they are difficult to modify when change occurs. In agile process changes can be accommodated easily because it has simple artifacts like burndown charts. Progress can be tracked in agile process as well and its more transparent than waterfall model.


The whole Agile Manifesto is centered on delivering better software. Although waterfall model’s intentions were also the same, but it just didn’t happen. We focused on tools and processes so much that the real values were getting lost somewhere. Agile tries to fill that gap.

There are also examples where people have forgotten the values on right completely. This is also improper choice.

Remember, delivering a high quality software is still very hard.