In February 2001, 17 individuals came together and wrote the Agile Manifesto, which says:
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.
© 2001, the Agile Manifesto authors. This declaration may be freely copied in any form, but only in its entirety through this notice.
The Agile Manifesto in detail
But what does all of the above mean when it comes to carrying out Agile methodologies in practice? Let’s look at each point in turn – as our team use Scrum, that’s the framework that I will use for reference.
Individuals and Interactions over processes and tools
In Scrum, the team is all. They must work together to plan Sprints, estimate, do the work – the list goes on. There should be effective interaction both within the team and with individuals outside it so that the Scrum team can establish a good quality Sprint Goal and work towards it.
Regardless of who the interactions are between, the most important aspect is to ensure free flowing communication. This can be achieved by:
- Creating a blame free culture
- Ensuring individuals are able to speak up (see planning poker and silent writing)
Working software over comprehensive documentation
The aim of each Sprint is to produce a working increment of potentially shippable product. Agile values an increment of working software over large amounts of documentation which likely provide no business value.
However, we still need to create documentation as long as it doesn’t interfere with the development of the increment. I would also say that user guides, for example, can create business value – without it, users may be unwilling to use your product.
Customer collaboration over contract negotiation
Only by collaborating with your customer can you understand what they want. You might think you know what they want, and you can even suggest this to them. But ultimately, you need to build a product that has the features they require.
This is even more important in Agile, where we focus on adding features that will add business value. The Product Owner (acting as a proxy for the customer) doesn’t want extraneous features adding, just because the development team thought it’d be cool. I’ve seen examples of this and it’s a perfect way to really annoy your customer.
I would say that once you start to have an idea of requirements, this can be put into a contract. But the contract needs to allow for changing requirements. If we were doing Waterfall, the contract would be set in stone, alongside the requirements, at the start of the project.
But we’re doing Agile, we expect the requirements to change, so that contract needs to account for this.
The beauty of Agile is that the requirements will naturally emerge as the project progresses. The customer sees the increment during the Sprint Review and this allows them to feed back on what they like and what isn’t as they expected. This feedback is then used to adapt the increment in the next Sprint.
Underpinning all this is communication. If the developers aren’t sure what the customer wants, then ask the customer. If you ask them straight away, you can prevent minor issues from growing into large problems.
Responding to change over following a plan
In the Waterfall model, we create detailed plans right at the start of the project. But this is the time when we’re least equipped to plan – we don’t know enough about what’s required from the product. Once you realise that change is required, it’s often too late.
Agile accepts that requirements will change and emerge as the project progresses. We do plan in Scrum, but it’s a continuous process. By utilising relatively short timescales (the Sprint) we are offered more frequent opportunities to inspect the product and adapt it.
If a plan isn’t working, then why stick to it? Look at why it isn’t working (inspect) and change it (adapt) based on past experience.
We also ensure that we don’t plan too far ahead. If we plan too far in advance, by the time comes to implement the plan, the product and environment are likely to have changed, rendering the plan useless.
When working on a Scrum project, it’s important to try and keep the Agile Manifesto at the back of your mind. Think to yourself:
- Are my interactions with others adding value or are they causing impediments?
- Do we need this amount of documentation or can we take advantage of “Simplicity – the art of maximising the amount of work not done”
- Are we effectively collaborating with the customer?
- Is our plan working, and if not, why not? Are we able to inspect and adapt it? Are we planning too far ahead?