Agile is, in fact, so commonly done wrong ( or not, in fact, done at all ) that there is an acronym for doing it wrong ! Agile In Name Only is the term used by Agile evangelists ( there sometimes seem to be more of them than mere practitioners ) to describe a whole variety of different situations in which the label 'Agile' is slapped on to something that patently isn't. There are an almost infinite number of blogs out there from persons vastly more evangelical than me that will attest to this.
Why do people do this ? Agile is not, in fact, terribly hard to understand. But it is terribly different to the way in which established businesses, particularly large businesses, typically like to think about product creation. And this is the first lesson :
1. Agile is not only about how software people should develop software - it's about how a business, and all the people in it, approaches creating product.
'Becoming Agile' is not a change that can simply be made behind the doors of the software development department - it impacts everything, from Sales and Marketing through to HR. There is, as usual, a huge literature on what constitutes an 'Agile Organisation', a lot of it from consultancies who will be glad to 'advise' you ( cough ).
In other words, any business that wants to do Agile and get the benefits it appears to dangle like some sort of magic golden apple, needs to examine it's processes from top to bottom, and change them to fit.
Most businesses don't want to do this. It's scary, it looks expensive, it probably is expensive, and habits ( not to mention personnel ) are hard to change. It certainly can't be done quickly, or by just sending people on a training course, no matter how expensive.
Much easier to cherry pick one or two Agile principles that look like low hanging fruit, try to implement those, start saying that you are 'Agile', and simply hope that some benefit accrues. This is particularly the case when senior decision makers are far removed from the coalface, and/or have no technical background, and inhabit a world in which buzzwords are inclined to take on a life of their own.
There is in fact nothing wrong with cherry picking one or two Agile principles. For many businesses there are really good reasons why full-fat Agile is not viable. For a discussion of 'blended methodologies', see here for example.
However, the big problem is that the Agile Principles are not independent. In fact, I believe there's a power law involved :
2. Each of the Agile Principles that you do not implement halves the benefit of Agile.
In other words, the Agile Principles are tightly bound together, and as soon as you start treating them as independent and just picking the ones you like or the ones you can do easily, you very rapidly start to lose the promised benefits of Agile. The golden apple turns out to be 99% worms. You become AINO.
This is, I believe, a situation that many companies find themselves in, possibly without even realising it. The problem is not confined to companies developing software internally for their own use - even experienced software consultancies with lots of Agile experience will happily do AINO if it seems like the best ( or possibly only ) way to win the business.
What I'm going to try to do here is to explain why the Agile Principles are actually so tightly bound.
In broad terms, the answer is simple - the principles are not requirements invented to define a new methodology, each principle is an objective observation, albeit from a different perspective, of what actually works.
Agile has, in a sense, got the Giraffe problem - it's hard to assemble a picture of an unknown animal by reference to known animals, but nonetheless there is a singular creature lurking beneath, and when you actually see a Giraffe, everything falls into place.
But, to milk this analogy for more than it's probably worth, chopping one leg off the Giraffe doesn't give you three quarters of a Giraffe, it gives you a large dead animal. Agile is a bit like that.
I'll take a look at the relationship between two particular Agile Principles as an example. I'll use Principle 7 ( "Working software is the primary measure of progress.") and Principle 4 ( "Business people and developers must work together daily throughout the project."). Let's see what happens when we attempt to have one without the other.
The first problem we run into is how to define 'working'.
'Working' from a developer perspective may mean 'passes a bunch of tests'. Or even 'passes one particular test'. But how were those tests defined ? Maybe the developer wants to be satisfied that some edge cases are handled, because they would otherwise be responsible for a disproportionate number of bugs. Maybe the developer has a systematic way of creating tests based on coverage analysis. Perhaps there are corporate standards that the developer knows must be met.
However, the above paragraph misses the point entirely. The point is, the developer is not the product owner. The product has to work for the product owner. The only way to be confident that this is so is to ensure that the product owner is involved both in defining what the product shall do, and in verifying that indeed it does what is expected. In other words, there is no such thing as "'working' from a developer perspective", there is only 'working for the product owner', and therefore without implementing Principle 4, Principle 7 becomes largely meaningless.
In fact, it's even worse than that. Because the dependencies between Principles are more akin to a mesh than a simple hierarchy or list, the potential for widespread knock-on effects is substantial, and this is the root cause of the problem.
© Mark de Roussier 2021, all rights reserved.