The four values of the Agile Manifesto
The Agile Manifesto consists of four key values:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
Let’s take a look at each one in detail:
Value 1: Individuals and interactions
In the past, a lot of software teams would concentrate on having the best possible tools or processes with which to build their software. The Agile Manifesto suggests that while those things are important, the people behind the processes are even more so.
Having the right group of individuals on your software team is vital to success. The best possible tools in the wrong hands are worthless. Perhaps even more important is how these individuals communicate with each other. The interactions between team members are what helps them to collaborate and solve any problems that arise.
Value 2: Working software
Previously, software developers would spend ages creating detailed documentation. That was before they even started writing a single line of code. And while documentation isn’t a bad thing, there comes a point when you should focus on providing your customers with working software.
The Agile Manifesto places shipping software to your customers as one of the highest priorities. You can then gather feedback to help you improve future releases.
Value 3: Customer collaboration
Once upon a time, contracts were king. You would draw up contracts with your customers who would then detail the finished product. As a result, there was often a contrast between what the contract said, what the product did, and what the customer actually required.
According to the Agile Manifesto, the focus should be on continuous development. You need to build a feedback loop with your customers so that you can constantly ensure that your product works for them.
Value 4: Responding to change
Can you imagine a time where you would draw up a roadmap and it would never change? Well, in the past that’s exactly what happened.
The trouble with static roadmaps is that we don’t live in a static world. Needs and requirements are always shifting, and priorities are always changing. That static roadmap will soon grow outdated.
That’s why the Agile Manifesto suggests that a software team should have the ability to pivot and change direction whenever they need to, with a flexible roadmap that reflects that. A dynamic roadmap can change from quarter to quarter, sometimes even month to month, and agile teams are able to keep up with those changes.