Exploring the 4 values of the Agile Manifesto

When I start learning new things, I like to come back to its source and discover where it comes from.

When you look at the Agile movement history, every source is pointing to the Agile Manifesto, back in 2001.

The beginning

At that time, a new project management methodology known as XP programming was trendy in software development. Other methodologies referred to as “Lightweight methods” were also emerging.

17 active leaders involved in these communities decided to meet at Snowbird Utah February 11-13 2001 to discuss what was common or what was different between all these methods in the field of software development. From these, emerged the agile manifesto, a statement of 4 values that capture the core ideas that all the participants shared during the meeting.

The agile movement was born.

The 4 agile values

Every value has the same syntactic construction: “statement A over statement B”.

This construction acts the necessity of reestablishing a new balance between the two statements. It is not a complete denial of statement B, neither it is an absolute supremacy of statement A. We should consider giving more importance to statement A than to statement B.

With that in mind, here they are:

Individuals and interactions over processes and tools.

When it comes to do some work, we often hide ourselves between our management processes and our tools.

We often forget that processes and tools are not working alone and that there are actually people who are still doing a major part of the work.

So work is all about people interacting with each others to complete some tasks.

In the late 90s, these interactions were really procedural because of work segmentation and specialization. Collaborators in big organizations were often working in silos and disconnected from the customers they served. Employees were mainly considered as valuable resources.

To overcome these communication problems, agile methodologies rely on frequent inspect-and-adapt cycles, on trust and respect between stakeholders, and on transparency of the data, actions and decisions.

Being agile is refocusing on people and how they work together. If you have it wrong, processes and tools won’t be of any use.

Working software over comprehensive documentation

In the typical waterfall approach, customers are audited to write down a requirements document. Then, the product is built while giving more documents to the customers about the production state. Then the product is tested and if tests passed, it is delivered to the customers.

The problem is that after the initial customer interviews, changes in requirements are hardly managed during the production process, and have to wait for the end of the build-test cycle.

So a lot of effort are wasted on deliverables that won’t fit customer needs.

Agile methods state that it is better to deliver working software at set intervals than docs about the production state. It means that you have to split up the end product in small pieces of working software that you can demonstrate to your customer.

This way, it is more likely you save time and effort working on useful deliverables, and get happier customers.

Customer collaboration over contract negotiation

Linked to the previous statement, having customers engaged during all the design and production process, instead of at the contract negotiation only, helps producing meaningful products.

A contract isn’t a substitute for communication.

The Agile Manifesto acknowledge that succesfull company listen carefully to their customers at any time in their development process and are able to adapt to follow changes.

Responding to change over following a plan

Having a plan is great, being able to change it is better.

Processes tend to rigidify organization, leaving them unable to adapt to situations like a customer changing its mind.

Agile Methods assert that we should welcome change, instead of fighting it.

Most of the agile methods set up iterative and incremental production, to give some place to feedback and learn from them.

Being Agile

We lean to rigidify all our behaviors and processes to feel safer about uncertainty.

This behavior leads us to waste so much effort and time when things don’t go according to plan. Moreover, team mates feel bad about producing wasted work, and customers don’t get what they asked for.

The Agile Manifesto stands for bringing back adaptability and flexibility to the table.

It promotes communication and collaboration between stakeholders, continuous improvement of the company and people, and iterative and incremental production on which feedback are asked for regularly.

This is something we deeply agree here at Kantree and we try to spread it in our work and product.

Useful readings on the subject

Martin Fowler on the origin of the Agile Manifesto: Martin was one of the 17 who wrote down the manifesto. He shared with us the story of the event.

Jeff Sutherland on Agile Principles and values: Jeff, author of the Scrum methodology, looks back to the agile values and explains them with his work on Scrum