Understanding Agile Manifesto

Introduction

In February 2001, seventeen software developers met at a Ski resort in Utah with the objective to find better ways to develop software. In their discussion they found consensus on four major points, now known as the “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.

The four values of Agile Manifesto

• 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.

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

Individuals and interactions over process and tools

Software is built by a team of people and to do that effectively they need to work together. As with the time processes and sophisticated tools that have developed, the focus has shifted from individuals to tools and processes. Vendors are selling tools and processes as a solution. But all along it is still people that develop 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 at the minimum necessary for a given situation. The focus should be more on individuals and the interaction among them. For example a QA team should not be isolated from the development team and similarly any other team committed to the delivery of the product.

Working software over comprehensive documentation

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

Customer collaboration over contract negotiation

Sometimes "Customer collaboration over contract negotiation" 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 a 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 a change occurs. In the agile process changes can be accommodated easily because it has simple artifacts like burndown charts. Progress can be tracked in an agile process as well and it's more transparent than a waterfall model.

Conclusion

The entire Agile Manifesto is centered on delivering better software. Although the waterfall model's intentions were also the same, but it just didn't happen. We have focused on the 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 the right completely. This is also an improper choice. Remember, delivering high-quality software is still very hard.