Agile Manifesto

In 2001, different agile representatives sat together to device a new framework. This is how agile manifesto came into being. It was a group of 17 people who met at this historical event which was held at “Salt Lake Valley, Snowbird, Utah” in 2001.

Now this is probably the most important slide of the course, Agile Manifesto. Each and every word/phrase is so important to get the basics and foundation elements of agile framework.

Agile Manifesto starts with a very interesting line. “We are uncovering better ways of developing software by doing it and helping others do it”. Agile never says other frameworks are redundant or not required or after this only agile is going to be there. It just says, we are uncovering better ways, which means earlier ways are good but we are coming up with something different and new which is the next step to evolving.

Let us discuss all the five elements one by one:

#1: Individuals and interactions over processes and tools:

This line is self explanatory that Processes and tools are important but it’s individuals who choose them as per their need. Individuals are most appropriate to choose which process and tool will work for them. Self-managed teams are the basis of agile. Face to face interactions where individuals collaborate and come to consensus is preferred than some sophisticated tool for interaction. It is believed that without much of the processes and tools, there is a good possibility, that a group of skilled and motivated individuals deliver successful projects.

#2: Working software over comprehensive documentation:

There is a myth about agile on documentation. First thing to understand is, agile doesn’t say No documentation. It always gives its preference over comprehensive documentation and believes lean documentation with actual software works better. If we move our focus from giving long documents to working software to customer, it will be very efficient and easy for the customer to provide feedback. There is nothing that the customer has to assume or try to visualize. Working software (even with small number of features) helps the customer to see the actual work and check if it’s as per requirements. Agile believes in free flow of communication and not through static documents. Long documents without any kind of actual software will not have any business value. Agile thrives for delivering Business value to customer at an early stage. As mentioned earlier, Agile doesn’t say no documentation, rather documentation should be a driver to support common understanding of the team and goal should always be to deliver a working software. The biggest drawback of documentation is once we get a change in requirement, it becomes stale. No one goes back and updates it thoroughly. Also in agile changes are welcomed anytime which further makes comprehensive documentation a complete no-no.

#3: Customer collaboration over contract negotiation:

Again when this element says contract negotiation, it doesn’t mean that contracts are not required and in agile money is not important. Projects work on money and organizations work on contract. The idea is: Customers is valued the most and always near to the team, ideally part of the team. It's difficult for anyone to give all required information or deliverables upfront and when the start is not the agile way. Customers are within team and they keep on giving requirements, priorities and also changes in requirements. This implies the goal here is to understand what customer needs, what gives business value to customer and work on it. As the world is changing dynamically, frequent flow of requirements is an inevitable part of the projects. Cost and time is decided but scope is something customer decides/updates/changes during the course of the project by being in the team. Upfront contract negotiation and then requirement gathering is not preferred in agile.

#4: Responding to change than following a plan

Change is the integral part of the project. With the market dynamics, quicker turn around, customers can change their mind anytime to improve their ROI/Business value. Agile welcomes these changes at any point of time as far as customer is in agreement of it and it is giving value to the customer. Agile doesn’t stick to the plan rather believes in progressive elaboration using a top-down approach. Plans should be adapting in nature which welcome the change and accommodate it naturally.

#5 While there is a value in the items on the right, we value the items on the left more

This is a very important term, Manifesto emphasis that we do agree that there is value in the items on the right but we as agile, value the items on the left more. We as agile believe that we can deliver projects better by valuing and incorporating items on the left more in software development.