What is Agile?
Let’s start with the basics: what is Agile?
It’s an umbrella term, coined in February 2001 when the Agile Manifesto was created. The manifesto starts by saying: We are uncovering better ways of developing software by doing it and helping others do it. It’s important to understand that it says uncovering – it doesn’t claim to be the definitive How To for software development. Sixteen years later, I think it’s safe to say we are still uncovering better ways.
Although the Manifesto refers to developing software, many people applying Agile thinking to non-software development – one of my favourite examples is the WikiSpeed car project. I worked with an internal audit team to help them apply Agile approaches to their work, as well as helping them understand how the software teams that they audit have changed the ways they work.
The next part of the Manifesto lists some values (which I’ll deal with my next few blog posts) and then says That is, while there is value in the items on the right, we value the items on the left more. Ok, stop there! Before we go any further, let’s address a common misunderstanding: this says we value the items on the left more – it does not say that there’s only value in those things on the left. Bear that in mind as we step through the values.
For completeness, and so you can find my related posts, here’s the meat of the Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
But I can hear the reader saying “yes, but what is Agile?” I’ve read many descriptions, some of which I disagree with, but I think the diversity of these descriptions highlights the difficulty is giving a simple, definitive answer.
For me, understanding Agile starts with accepting that the work we do (usually software development but it doesn’t have to be) requires an adaptive, responsive, inclusive and collaborative approach in order to produce something valuable for your customer. I know that sounds vague and fluffy, so I’ll expand on those adjectives:
- adaptive: Very rarely do we know exactly where we need to end up, let alone how we will get there. How often do you hear people complain that the customer has changed their mind? Yet we (used to) ask them to create a requirements document, describing in detail exactly what they want at the end of a 12-month project. Those requirements are then signed off – they become a contractual agreement for which there are penalties when the customer wants to alter it, so the client often tries to include everything they might want. Instead let’s ask the client for a high-level view of their goals but only worry about the detail as it becomes necessary – hopefully, the customer can be fairly certain about their needs for the next month, but if that timeframe is still too much then Agile has ways to work with that.
- responsive: Businesses, especially online businesses, need to react quickly to changing market conditions or to introduce new products. If it takes months for a company like Amazon to turn a concept into reality, their competitors will likely beat them to it; different business domains will have different timescales (banks, for examples, might think a year is acceptable) but in general the aim is to be able to respond fast enough to beat their competition.
- inclusive: Teams are made up of people, and often there is a hierarchy imposed on (or sometimes, by) those people which can lead to some team members being marginalised or ignored. A healthy, productive team recognises the value in having diverse experience – when they are problem solving (which happens many times a day) a creative solution may come from someone with no experience in a particular field asking fundamental questions that the experts have overlooked.
- collaborative: Multiple people working together towards the same goal could be described as collaborative or cooperative – the difference is that a team could cooperate by dividing up the work and completing each piece in isolation, whereas a collaborative team has a shared responsibility and teammates engage on work together. Collaboration is harder; it requires people to put their egos aside and apply themselves to solving the same problem.
- valuable: The purpose of the team’s work should be guided by the customer – they are the ones paying for the team’s efforts, so they should be able to see the value in the team’s output. It would be nice if the client could say “feature X is worth $Y to me” but it’s rarely that simple, so value tends to be more abstract – the key thing is that the customer can identify the most important piece of work for the team to deliver next, and then the team deliver it. As I touched on in adaptive, the customer could change their mind, so the most valuable thing to do next might be to change something they have already delivered – that’s to be expected as sometimes the only way the client can describe what they want is to have something to critique.
Agile encompasses many approaches for tackling these challenges; the key is not to expect a simple “off the shelf” method which will work for everyone – instead, we need to continue uncovering better ways of developing software by doing it and helping others do it.