The Agile Manifesto is a cornerstone of agile software development methodologies. It's a short document created in 2001 by a group of software developers who met at a ski lodge in Utah.
But what does it really mean? How can it be applied? Let's try to explain the four points of the Manifesto, but first let's take a look at it:
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.
Individuals and interactions over processes and tools
Software is all about people. People commission it, people write it and people use it. Those three parties, the investors, the developers and the users must interact and collaborate to create software that will meet all their expectations.
It's never enough to make a plan, get some tools together and put a process in motion. If there's no counsel, feedback and adaptation, the software will not meet anyone's exceptions. Neither one of these three parties has all the know-how to create a profitable software masterpiece. It takes all of them working together.
It's also about trust. The three groups need to trust each other that they're experts in their particular fields. The investors know the business side of things, they know how they can make money on the software. The developers know what technology to use, how to write it and how much work they can realistically take on. And the users know what they'd like the software to do and how they'd like the interface to look.
The investors need to trust the developers and the users and let them do what they do best. And the developers need to trust the investors and the users for the functionalities that are needed.
Working software over comprehensive documentation
"Working software" is the key in all agile development. When software is created using agile methodology, the software is always kept in working, potentially shippable state.
When traditional software development methods are employed, comprehensive documentation must be developed first in order to know what to build. It all needs to be drawn from start to finish before the development process can begin.
And although documenting the software is still very important, in agile environment it gets documented step by step as it gets created.
This makes a huge difference and it's what makes agile so unique.
Customer collaboration over contract negotiation
We're coming back to the importance of people over tools. Customers are people, contracts are tools. We need contracts, they're the basis for legal cooperation between companies and individuals. But we can't be blinded by the contracts and expect them to solve the problems that should be solved by people.
The developers need to collaborate with the customers. And they need to do it on the ongoing basis as they iteratively add new functionality to the software. It's all about feedback and active collaboration of both parties.
So instead of insisting on rigid contracts and setting everything in stone at the beginning of the project and then insisting that the parties abide by the iron rules, we need to leave ourselves some freedom to modify the requirements and the direction the project is going. Because it seldom goes according to the original design.
Responding to change over following a plan
It's a very comfortable feeling to create a detailed plan at the beginning of the project and expect everything to go according to that plan. Unfortunately software development is one of those unique areas where this approach rarely works.
Agile is all about taking things step by step, inspecting the results as we go and modifying the plan as needed. In other words, responding to change.
Agile software development should be alive, it should flow like a stream down the mountain, always responding and adapting to the obstacles and opportunities it meets along the way. It should not be a steamroller that rolls in a straight line flattening everything on the way and ending up in a deserted place, outdated and useless.
Conclusion
What is agile development then?
Agile development is individuals interacting with each other while developing working software, using customer collaboration and responding to change.
Of course, not neglecting the processes and tools, documentation, contracts and plans.
But remembering that first and foremost it's all about people.