cropped-p4010326.jpgMartyn Ricard Jones

Bruxelles 28th May 2019

To begin at the beginning

To paraphrase the great Bob Hoffman. Just when you thought that if evangelists for Agile were to generate one more ounce of bullshit the entire fucking solar system would explode, what do they do? Exceed expectations.

And how did they do that? Ladies and gentlemen, let me introduce you to Agile at Scale with all the miscellaneous, spiced-up and vainglorious crap-on-the-side that accompanies it.

Yes, Agile at Scale is taking IT bullshit to an entirely new level, in an entirely new dimension and on a completely different planet, and it’s not a good look.

Historically speaking, Agile at Scale has come out of the same idea-mangling, cult-ridden and learning-averse factory that was built on the back of an offshoot of IT by the very same ignoramuses, egomaniacs and code-bodgers that brought you extravagant claims about the power, sophistication and cost-effectiveness of HTML, Java and Hadoop, etc.

Just look at it! Agile at Scale is immature, ill-conceived and supercilious. It has ostensibly not learned from anything that came before it. Yes, there are references to history in some of the slide decks and posters, but that’s it. Nothing from the past that worked is actually included in this lame excuse for a universal method.

In my view there are three main areas of concern regarding Agile at Scale:

  1. It’s not agile.
  2. It’s like kryptonite to effective communication.
  3. Criticism of the cult is worse than heresy.

It’s not agile

If I had a euro for every mug who has told me that they are doing Agile, when in fact what they are referring to are fire-fighting bodges, inattention to reality and ‘making it up as you go along’, I could have bought a villa in Cannes on the proceeds.

Take a look at any Agile at Scale method and start asking questions about it.

  1. How do you manage requirements in the process?
  2. How do you manage change in the process?
  3. How do you manage quality in the process?
  4. How do you manage data in the process?
  5. How do you attain and maintain an overview of the process in each real case?
  6. How do you manage the process?
  7. How do you ensure coherence of the process model?
  8. How do you ensure usability of the process model?
  9. How do you ensure auditability of the process model?
  10. How do you model the non-linear triggering of events in the process model?

Asking these types of questions will inevitably highlight significant gaps, contradictions and inherent failings of the approach. It will demonstrate that the process is in far too many aspects structurally unsound, procedurally incomplete and business incompatible.

It’s like kryptonite to effective communication

I am convinced, that in communication, as with many other things, that simplicity is power. Maybe this is due to the fact that one of my academic loves is philosophy.

Much has been written and discussed about the importance of terms and more importantly the intentional and accidental abuse of terms; by Chomsky, Adorno and others.

I have had a lot of exposure to this, working in IT for a long time I have seen that the term abuse has always been there. But in the last decade the bullshit jargon bingo has gone supernova pro, big time.

I have heard people use terms like vision; strategy; learning journey; by design; operating model; data dictionary; support points; roadmaps; GDPR and data privacy; and, lean-agile mind-set, amongst others.

Sometimes, out of idle curiosity, and when these terms have come up in conversation, I have asked things like “so, for you, what is data by design?” or “from your perspective, what is this learning journey lark all about?” and in return have received that sort of look some dogs give you when you talk to them. Only, when it comes to humans you could be led to think “this person doesn’t have a fucking clue as to what they are talking about”. You know, that moment when you realise that the name of the game is bullshit; no understanding required?

Take “data by design” for example. It’s a classic bullshit term. A term used to pretend that something is new when it isn’t. A term used to build credibility for a new fad when in fact it’s just a new label for something borrowed from an old fad. What did we do before data-by-design? Data-by-accident? Data-by-implication? Data-less-apps?

Total bullshit. All of it.

Worst of all, this term abuse hurts effective communication. No one knows what they are talking about.

Everyone pretends they know what they are talking about.

But the proof that bullshit pervades every aspect of communication within Agile at Scale is in the inability to actually deliver what might be required, because the requirements are so mixed up with the bullshit of deceit that they are barely discernible and frequently unrecognisable, and therefore don’t get implemented.

Criticism of the cult is worse than heresy.

This is an aspect that I have touched on elsewhere in other blog posts.

If Agile was a cult, then Agile at Scale is like pieces of Scientology, the Vatican, the Eastern Orthodox Church and the Church of England all rolled into one handy but extremely complex take-away.

As an aside, there is a great take-down of Agile here, 10 ways Agile feels like a fucking cult, so I won’t simply repeat Agile Anon’s points.

What I simply want to do here is emphasise a number of proselytising behaviours and quirks found with some examples of Agile at Scale that I have seen up-close and intimate:

  1. Delusions of grandeur
  2. The worship of half-baked ideas
  3. The sycophantic adoration of the Führer and the Führerprinzip
  4. The bullying tyranny of the Agile at Scale mob
  5. Fixation with liturgy and fetish
  6. Belief that data is oil
  7. Commitment to the data driven enterprise

One could almost speculate that if Agile at Scale were political, it could well turn out to be like the Nazi party.

That’s all folks

Again I’ll lean on the words of Bob Hoffman when I state that these Agile at Scale folk are so monumentally full of shit that they make bozos like me seem sensible in comparison. You get the picture? Knowing is one thing, but thinking you know when you don’t now is self-deceit. Saying or implying that you know when you know you don’t know is borderline deceit and fraud.

You know, there are two kinds of people: people who simplify things and people who complicate them. The Agile at Scale crowd love to complicate things, I’m of a very different view. For me, the simpler it is, the better it is. Many years ago I embraced the philosophy of Mies van der Rohe, “less is more”, and have used that to great success wherever I have gone, well, all places except those who indulge themselves in Agile at Scale. People who really know, know how to simplify. People who don’t know how to simplify need to bullshit, otherwise they are exposed as wanting.

So, remember folks! When you say something that isn’t true and no one believes, you are not only wasting time, money and patience, you are undermining your credibility and the credibility of your colleagues. And all the spurious PowerPoint “support points” and “roadmaps” in the world won’t make your absurd claims any more believable or useful.

Many thanks for reading.

All the best,

Martyn

Acknowledgements:

Many thanks to Bob Hoffman and Dave Trott for some great inspirational material.

“It is true that humans are not logic machines. But, remember, emotion is a response. Not a stimulus.”