Agile Values Explained
Google “agile” and you’ll likely be overwhelmed with jargon, acronyms and hype. It’s become big business. Systems are selling like hotcakes to eager companies wanting to “go agile”.
And who wouldn’t? Agile seems to be the magic fuel that’s been rocketing the new cool multi-billion tech companies into affinity and beyond!
Healthy scepticism
One of the problems of successful revolutions is that the reason for them is quickly lost in the new scrabble for power.
Much of the alien terminology surrounding “agile” has been about turning an inclusive concept into an exclusive commodity.
Guarding against this, I’ll be keeping the buzzwords to a minimum and will simply highlight the values of the “agile manifesto”
The dawn of the internet
By the late 1990s numerous software developers recognised that the traditional ways of working were not delivering value to the customer.
17 of these got together and agreed on the Manifesto for Agile Software Development made up of 4 values and 12 principles.
It soon became apparent that this was not something only for software developers. Even the most established industries could benefit from adopting an agile approach.
Let’s explore the 4 values of the manifesto. They have the same format: what is on the left of the statement is favoured OVER what is on the right. I shall be adding something about how I interpret them.
1. Individuals and interactions over processes and tools
I think of this as:
“don’t hammer square pegs into round holes.”
This agile value puts people at the centre of everything. It’s people working well together that makes a success rather than processes or tools.
We want to avoid rigidity and an overreliance on tools and concentrate on better collaborations with our customers.
Agile values soft skills. The magic comes from unique personalities and skill sets interacting together.
I remember one agency was having admirable success in a niche market. Their clients wanted almost exactly the same outcomes and had almost exactly the same content. It followed that the content gathering could be turned into a process.
Money was spent on creating an automated custom solution only for it to fail. What worked more efficiently was a face to face call. Overall, the same process was carried out, but the human interaction made it smoother and provided insights that otherwise wouldn’t have been gathered.
In many ways, it should be obvious that forcing your agenda on the people who are paying is a bad idea, but it’s too easily justified by the need to show expertise.
For those of us in the now commercialised and saturated WordPress space, it is easy to be lured into the idea that the more complex tool holds the answer to our problems. It can lead us to forget we are in the human business of providing a client service.
2. Working software over comprehensive documentation
With traditional (scoped) projects, 75% done means 75% progress and 0% done. For those making progress there generally needs to be some documentation to tell others what is going on.
This may not waste too much time on small projects, but as a former manager in the British Civil Service, I am more than familiar with how much time can go into documenting things that will never be read.
With Agile, teams are small and self determining and include a client representative. The management structure is slimmed down.
With Agile we are working iteratively, so 75% done means 75% (of highest-priority requirements have been) completed.
All may not work well, but dreary documentation is replaced with active testing. This is likely to highlight UX issues not so easily spotted in the plans.
3. Customer collaboration over contract negotiation
We may not wish to admit it, but often projects start with a client pretending to know what they want and is reasonable to expect.
They find a vendor who similarly pretends they understand the client needs and what the cost of collaborating with them will be.
Together, they negotiate a contract to set the imagined product in stone
This is the traditional model, and it works well when:
- The variables are limited.
- It is impervious to outside forces.
- When the client leaves everything up to the designer.
- When everyone truly has a same shared vision from the beginning.
More often, people do not know what they want. They know what they don’t want when they see it. They learn and understand from doing.
There is a quote attributed to Henry Ford that, for me, sums up the futility of trying to fully scope a web project with clients:
“If I had asked people what they wanted, they would have said faster horses.”
Going agile does not mean there are no contracts. It means they should focus on ways the both parties can agree to work to realise a product that is the best it can be (rather than something imagined when both parties are less knowledge about what each can bring to it).
It can reduce a “us and them” working environment, which can either end badly for individuals involved or result in a horribly compromised product.
4. Responding to change over following a plan
If we accept we can’t know the end result from the outset, we become responsive to change. We become agile!
As web designers we may not be deploying new code to our platforms every 11.6 seconds like Amazon, but it is likely over the period of the project we will encounter things where we should change our plans.
For me, this value sums up why the agile ways of working has become necessary in a faster changing world.
It is why I think we should not be looking at websites as an end deliverable, but seeing them as inherently subject to change. This changes the relationships with clients from the beginning. Personally, it makes it easier for me to start talking about my hosting and care plans from the beginning.