Peeling the Agile onion
I once worked in a company where one of the directors was heard to say:
Opinions around here are like bum holes; everyone’s got one.
I believe this was an adaptation of a quote from the 1988 film, The Dead Pool (one of the Dirty Harry movies).
In any case, never has this quote applied more than to the Agile community. This isn’t a bad thing though – there is a good reason for there being so many opinions and an excellent solution for working out whether any opinion is worth its salt.
Why So Many Opinions?
- It isn’t prescriptive
- There are no rules
- The principles are sound
So it is no wonder that if someone asked a question about Agile hoping for a concrete answer, they could be given several different concrete answers that might even seem to clash to some extent.
Just think about estimation. You will get people telling you to estimate in days, weeks and ranges of real time, you’ll get people telling you to use something more abstract like points, you’ll get people telling you to break everything down to about the same size and just count the number of stories and you’ll get people telling you that the whole idea of estimation is waste and you should drop it.
They are all correct.
Using any of these techniques can be perfectly in line with the Agile principles. Agile doesn’t prescribe how you do estimation or even whether you need to.
So let’s re-frame these opinions. Because they aren’t really opinions, but examples of techniques that people have found to work within the context, environment and culture that they were part of at the time. So let’s not call them opinions, let’s call them options. Bear them all in mind when you design your own way of working.
Testing The Options
So when you are presented with a giant list of options from a whole bunch of people who mean well, but who may even believe they have The Right Way™.
It is actually very easy. You peel the Agile onion.
Start off by thinking about how each option would fit into your context. This is your first layer of juicy vegetable flesh that can help you to weigh the options against each other. Which ones seem to be a better fit?
Then you peel off that layer and think about your process. Whatever standard framework or method you are using, you almost certainly will have customised it. The opinions probably aren’t based upon your custom process, so use this layer to think about how things would work in your specific process.
Peeling back your custom process, you can look at the more standard version based on the framework you are using. If you were using Scrum how does each option fit in with what you read in the The Scrum Guide, or Essential Scrum or other Scrum resources?
Don’t stop there. Peel away again to use the Agile principles as a measure for each option. Do options conflict with a principle or fit well with the principles?
And finally you have the four powerful lines of the manifesto itself, which is too often forgotten when talking about these things.
So bear in mind that articles, discussions, books and conversation about how to run Agile (including anything I write) is typically devoid of context – so don’t blindly apply rules or procedures that people tell you must be done, peel the Agile onion and judge them against each layer. I promise it will cause less tears than trying to argue about the correct answer on a discussion forum.
I realise a certain pleasant linguistic balance in talking about opinions, options and onions. I’m happy for you to believe that it was deliberate.
Photo by Krzysztof Szkurlatowski