The aim of this new leg of our journey to try to survive The Hitchhiker’s Guide to Killing Agile is to talk about a worrying trend I’ve been recently noticing among some of the so-called Agile coaches, gurus, heroes and evangelists.
As you may know, as much in the case of systems as in the case of people, inconsistent behaviour is one of my pet peeves.
So, I think it’s high time I ranted about the lack of coherence, if not integrity, of some alleged Agile professionals.
At the beginning, not only do they carefully explain Agile values and principles, but they also responsibly warn you about the risks of cargo cult.
They also mention that it doesn’t make sense to adopt the Spotify model if you are not working at Spotify.
After all, even Spotify doesn’t use the Spotify model anymore…
But then, when a big customer calls them to “build squads” —probably because someone from upper management has distractedly read something about that on a business magazine or has heard a competitor mention it at a conference—, they quickly accept this kind of (usually well-paid) assignment, without batting an eyelid.
If you ask them what happened to the values and principles they were diligently spreading, chances are they initially look puzzled.
Once you point out the inconsistency between what they used to preach and what they are currently doing, they are probably going to explain that one thing is the theory, and another thing is applying it to practice; they might also pompously add how difficult is the situation at that large organization they are currently consulting, and that a cultural change within a so big corporation is really cumbersome; they might even allege that, after all, they have to do what the customer asks for, and they need to adapt to the customer’s context.
All in all, they are just trying to justify their conspicuous paycheck.
And in doing so, they don’t even look uncomfortable at all: they are so experienced at forgiving themselves for their lack of congruence…
Just to make it clear: to me, accepting the task of “building squads” without any previous assessment means making a living as irresponsible installers of cargo cult.
What’s more, some of them have started promoting also the Atlassian QA process, selling it as the panacea for software testing.
So, now it seems that, regardless the sector they are, the products or services they sell, or the problems they have, all the organizations need one and just one tester… ehm, pardon me… one and just one quality assistant, being this concept usually presented as a kind of best practice for Agile Testing.
Again, they are just fostering more cargo cult.
And in this case it’s even worse, because most of the time those Agile coaches, gurus, heroes and evangelists have no idea about what testing is really about.
They might be familiar with the concept of checking that a system does what it is expected to do, but they aren’t able to get what exploratory testing is about and don’t have the mindset to understand the need of investigating how a system might not work.
As easily they bought the unfortunately popular model used by Atlassian, as they are now trying to sell that new ridiculous trend just for the sake of looking like the experts in the room.
The only explanation I can find to such an inconsistent and harmful behaviour is that they might believe in some kind of homeopathic agility.
After all, aren’t they acting as though a practice that causes the symptoms of a disease in healthy organizations would cure similar symptoms in sick organizations?
Let’s inject a bit of Spotify model here; let’s add a pinch of the Atlassian process there.
Let’s dilute Agile values and principles in squads, tribes, chapters and guilds; let’s eventually take advantage of a quality assistant to deliver the finishing blow.
That’s all!
Well, as far as I know, the effectiveness of homeopathy has not been proved yet.
Nevertheless, it’s clearly a profitable business for those who sell it.
Exactly like homeopathic agility…
Love the reference to the cargo cult (how many agilists can do that!), and I think you make some good points. I am of two minds. I think your principled approach has much to recommend, but I also know that there are teams that can’t or won’t adopt everything agile has to offer. That doesn’t make them bad teams. I think a better approach might be for these teams, whenever they want to deviate from agile principles, document that with a justification for doing so, and what advantage they think they will achieve. That way, six months or a year down the road, they can revisit those decisions to see if they actually had the benefits the team thought they would.
Thanks for your comment, Peter.
I see your point and I absolutely agree that Agile doesn’t suit every context.
Having said that, if an organization decides to follow Agile principles, it shouldn’t be for the sake of Agile, but because they believe it can help them improve.
So, once they decide to give it a try, they shouldn’t forget the importance of consistency.
In other words, as long as inspect-and-adapt principles are in place, people focus on continuous improvement and, above all, keep thinking, I don’t see any problem with starting from a not ideal approach.
Problems usually arise when organizations just copy and paste someone else’s approach and stop thinking.
I’m not quite sure where to begin, Ileana. The article is excellent, as one would expect from you!
When I followed the link to the Atlassian QA process, I was incensed by what I read , not least by their “reuse” of Cem Kaner’s “quality assistance” term.
I was equally incensed by a claim made recently where I work, that one of the leading causes of agile failure is “Lack of automated testing”. For me this is an excellent example of a cargo cult that has penetrated the minds of some. Wikipedia says that “A cargo cult is a belief system among members of a relatively undeveloped society…”, so some people may feel insulted by the connection between automated testing and a cargo cult ?
As you rightly say, “most of the time those Agile coaches, gurus, heroes and evangelists have no idea about what testing is really about.”. I think this also applies to a lot of project managers and CTOs, for example. This results in those without neither clue nor integrity, selling snake oil to the equally clueless.
BTW, this is something I wrote over 5 years ago, https://bit.ly/2Ic17ft which I think complements your article.
Thanks for your comment and for the link to your (as usual) thought-provoking article, Ralph.
If you don’t mind, I take the opportunity to recommend also its sequel: https://thefragilistblog.wordpress.com/2016/01/02/agile-the-programmers-revenge/.
I wish I was there to witness that “sublime moment that could change the world”! 😉
I love the blog!
and I will use your blog in addition to my story in what I called the Agile elephant in the board room
https://www.linkedin.com/pulse/agile-elephant-boardroom-ard-kramer/
thx for your observations!
Thanks for your comment and for sharing your article, Ard: I found it really worth reading!