Martyn Richard Jones
San Martiño de Bandoxa
21st April 2020
ADVERT:
LAUGHING@BIGDATA – THE GREATEST DATA STORY EVER TOLD!
A new ebook about Agile, AI, data, deep learning, IT, machine learning and more.
It’s highly polemic, contrarian and insightful. It informs, educates and entertains. And there’s a lot of it. You won’t be left indifferent.
Here’s an update on developments.
For greater convenience my Brand new ebook Laughing@BigData (Kindle Edition) is now available at the following Amazon locations:
USA (around 9.98 USD): https://www.amazon.co.uk/dp/B086HS6VWX
United Kingdom (around 7.99 GBP): https://www.amazon.co.uk/dp/B086HS6VWX
Germany (around 8.99 EUR): https://www.amazon.de/dp/B086HS6VWX
France (around 8.99 EUR): https://www.amazon.fr/dp/B086HS6VWX
Spain (around 8.99 EUR): https://www.amazon.fr/dp/B086HS6VWX
Italy (around 8.99 EUR): https://www.amazon.it/dp/B086HS6VWX
Netherlands (around 8.99 EUR): https://www.amazon.nl/dp/B086HS6VWX
Japan (around 1,099 YEN): https://www.amazon.co.jp/dp/B086HS6VWX
Brazil (around 24.99 BRL): https://www.amazon.com.br/dp/B086HS6VWX
Canada(around 9.99 CAD): https://www.Amazon.ca/dp/B086HS6VWX
Mexico (around 149.99 MXN): https://www.amazon.com.mx/dp/B086HS6VWX
Australia (around 10.99 AUD): https://www.amazon.com.au/dp/B086HS6VWX
India (around 449 INR): https://www.amazon.in/dp/B086HS6VWX
Please consider sharing these links and a recommendation with friends, connections, groups, colleagues, partners, peers, family and bosses.
Oiling the wheels-of-industry during COVID-19.
Thanks a million! Stay safe and keep well!
Martyn
“It takes courage to makes things simple.”
E. F. Schumacher
The prologue
Peter: So, Dud, that jolly of a job you were on in Brussels last month, how did that work out?
Dudley: Oh, it was good, Pete. Nice city. Nice people. Good bars. Plenty of great stuff going for it.
Peter: I know that Dud. But how did the job go? You were doing some Agile action on the gravy-train as far as I recall. Right?
Dudley: Well, to be honest, Pete? That was a bit of a laugh, in a non-funny “hahahahaha” way.
Peter: Oh, yeah. Are you going to pony-up what happened or is it a secret, like that “secrets of big-data success” stuff you did with that jakey twit from Milton Keynes?
Dudley: Well, I was at this big place, and the bloke running the project says to me “we are going Agile at scale, for the whole business. Because that’s where it is at!”
Peter: Oh, bloody hell, no! And what did you say to the dope?
Dudley: Well, I asked, didn’t I. I says “And why would you want to do that?”
Peter: Go on!
Dudley: And he says “we want to reinvent ourselves as the European equivalent of Spotify.”
Peter: Oh, he didn’t? Oh, bloody hell, not again. What a dope!
Dudley: So I say, “why would you want to turn an old, large, reputable and internationally recognised European financial institution, one with many customers. Into a hipster business whose primary job is to provide music on demand over the internet?”
Peter: That was telling him right and proper! What did he do then?
Dudley: He went off in a sulk didn’t he.
Peter: What a dope. You are better off out of it, Dud. Fancy another pint?
To begin at the beginning
To paraphrase the advertising legend, Bob Hoffman. ‘Just when you thought that if evangelists for Agile were to generate one more ounce of bullshit, the entire f****** solar system would explode, what do they do? Exceed expectations.’
And how do they do that? Ladies and gentlemen, I’ll let you into a little secret about this Agile@Scale stuff, including a brief tour of some of the miscellaneous, spiced-up and vainglorious crap-on-the-side that accompanies it.
But first, a quick summary of Agile.
What’s Agile, Mart?
For me, Agile is many things. But initially Agile was the way I worked in the early eighties.
An example of this agility that comes to mind is this. I once had an engagement with a company who wanted to do multi-currency consolidation of all their operations across Europe. It was an urgent requirement.
So I drove over to the border with Wales and met the guys working for the client. I sat down with the Chief Financial Officer, and he said: “I’ll tell you what we want, and you’ll make it happen, right?” And “By the way, it’s must be done today. Otherwise, I’m going to get heat from Stateside.”
Ten minutes into the conversation I said: “Look, I don’t know what this all means and I don’t know what to do, we’ll have to do this another way”.
“Which is?” he asked.
I replied “You’ll sit here with me until we have it done.” and “You’ll explain, in enough detail. Not the theory of multi-currency reconciliation, but how you would do this without a computer. And I will ask lots of questions and do the typing – make the database structures and code. All right?”
The CEO poked his head around the door. In a flash, we had a deal.
We hit mid-afternoon and along came a bit of a side issue—a spanner in the works.
The CFO says to me “Look, we overran big-time on expenses for a European get together of CFOs and CEOs – what you’d call a jolly – and we spent quite a bit of money – on ‘things’. Things which we need to reallocate and subsume somehow. So that we don’t get hostility from our cousins at HQ.”
So, I said, “okay, how would you do this if there were no computers?”
So he told me.
And as he spoke, I asked questions, typed and constructed the solution. Continuously coding and testing as we went along – it was, in fact, nothing less than rapid requirements gathering and test-driven development, on speed.
By the end of the day, we had a comprehensive multi-currency reconciliation report.
The CEO stuck his head around the door again, on his way to the car park.
“All done guys?”
“Yep, all done!”
“Great. Go and have a couple of beers on me.”
It was a brilliant case of IT reflecting business. And, happy days they were as well.
For me, that’s simple and Agile. And, that’s how we rolled.
But what about proper Agile
“Yeah,” you say “but, that’s just simple rapid application development, Mart. Just because you can do three months’ work in a day doesn’t mean it’s Agile or to scale. Go on tell me, humour me, what is proper corporate-strength Agile?”
Well, here we go.
Well, there is Agile, and there’s Agile, and they are not the same thing. Then there’s iterative processes and development, Kanban and Scrum, amongst others.
There are quite different views about what Agile is.
The roots of Agile are many and varied. And those roots go back at least to the early eighties. Which was when I started to dabble in application development using a 4th generation language called Mapper. Most of the time, I worked, analysed, designed, developed and tested alone. Two things influenced the way I worked:
- The advice and guidance of my boss, a coach as well as a manager.
- The youthful belief that no problem couldn’t be resolved.
My first big analysis, design and development assignment was to build an application for Sperry Univac’s software and documentation ordering, registration, fulfilment and distribution function. My boss at the time set some conditions that shaped the way I approach software development:
- That the user interface was seamless, intuitive and very easy to use, and all complex aspects would be hidden from the user. So that the user could learn how to use the application in the shortest possible time with the minimum number of steps and errors. The application was heavy on the validation of user inputs and choices, and there was plenty of simple online help.
- It would also be made with the view of ensuring that the user was isolated from committing any avoidable error.
- That all bugs would be reported and fixed as a priority.
- That requirements would be set and prioritised continuously.
- That the cycle of development, testing and deployment were short stages of usually no more than a week. A species of Dev-Ops.
That way, I ended up creating my application development method. It was Agile, but at the time, I just called it ‘doing stuff’.
So when Hewlett-Packard got Agile in 1997, it was already something with which I was quite familiar.
Then in 2001, along came the Agile Manifesto, which for some strange reason led many people to believe that Agile was invented in the 21st century. Which, from observing the historical record is not the case.
The Agile Manifesto was not about a software development methodology but more about approaches to the task of software development, a way of thinking of software development. The four main values of the Agile Manifesto being:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
Which I interpret as:
- Always put people first and foremost; contented people deliver successful projects.
- Always deliver that which was requested; the most successful businesses do this.
- Ensure that you always know what is requested; always keep the client engaged.
- Ensure that you emphasise flexibility and adaptability; embrace reality and tame it.
- Items 1 through 4 always have priority over processes and tools, just enough documentation, contracts (such as service level agreements), and plans.
Nothing about data-by-design, built-in-quality, epics, lean budgets, portfolio Kanban, release trains, learning journeys, stories, value streams, weighted shortest job first, and all the rest of the boloney now found in what is euphemistically termed Agile@Scale.
Can you use Agile to fight a war?
One of the questions that I ask about methodologies, and which for some unknown reason hugely irritates the Agile evangelists is this: can you use Agile@Scale to fight a war?
And they ask “Why would I want to do that then, Mart?”
And I explain. If you are proposing that every possible aspect of the business, and not just IT or software development, should become subject to Agile@Scale, then I want to know if you can use it to fight a war, or even several wars simultaneously. And I’m not looking for just a yes or no, but the high-level details of how you would do that.
And tangible, coherent and verifiable answers there came none.
You see, in my mind, if you can’t use it to fight a war, or even a battle, it’s not appropriate to try and apply it to every aspect of your business. Anything else is reckless and abusive power-creep writ large.
Upwards and onwards
Agile@Scale is taking IT bullshit to an entirely new level, in a wholly new dimension and on a completely different planet, and it’s not a good look.
Historically speaking, this species of Agile@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 ignoramuses, egomaniacs and code-bodgers. The very same people who brought you extravagant claims about the power, sophistication and cost-effectiveness of HTML, Java and Hadoop, and all that jazz.
Just look at it! Agile@Scale is immature, ill-conceived and superciliously complex. 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 gets included in this lame excuse for a universal method.
In my view, there are three main areas of concern regarding Agile@Scale:
- It’s not Agile.
- It’s like kryptonite to effective communication.
- Criticism of the cult is worse than heresy.
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@Scale method and start asking questions about it:
- How do you manage requirements in the process?
- How do you manage change in the process?
- How do you manage quality in the process?
- How do you manage data in the process?
- How do you attain and maintain an overview of the process in each real case?
- How do you manage the process?
- How do you ensure the coherence of the process model?
- How do you ensure the usability of the process model?
- How do you ensure an adequate auditability of the process model?
- How do you model the non-linear triggering of events in the process model?
- How do you cater for unplanned events?
- How can the approach be broken?
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 between people, as with many other things, that simplicity is power. Maybe I think this because one of my academic loves is philosophy.
Much has been written and discussed by Chomsky, Adorno and others about the importance of terms and more significantly, the accidental and intentional abuse of terms.
Working in IT for as long as I have, I got much exposure to this. I know that term abuse has always been there. But in the last decade, the bullshit jargon bingo has gone supernova-pro, big time.
As alluded to previously. I have heard people use terms like vision, strategy, learning journey, by design, operating model, data dictionary, support points, roadmaps, GDPR and other data protection regulation, and, Lean-Agile mindset, amongst others.
Sometimes, out of idle curiosity or when these terms have come up in conversation, I have baulked at accepting such them without question. My awkward squad training has meant that I have asked questions. Questions such as ‘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, and I use that term advisably, you would be right 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 vacuous bullshit term. A term used to pretend that something is new when it isn’t. And a term used to build credibility for a new fad when in fact it’s just a new label for something less than credible that was borrowed from an old method.
What did we do before data-by-design, data-by-accident, data-by-implication or even data-less-apps?
Of course, this is total nonsense, all of it.
Worst of all. This term abuse hurts effective communication. Because you get situations in which no one knows what they are talking about. Yet no one will admit this. As everyone is pretending that they know what they are talking about. And it’s frankly absurd.
But the proof that bullshit pervades every aspect of communication within Agile@Scale is in the inability to deliver what might be required. Because the requirements are so mixed up with the bullshit of deceit that they are barely discernible. And they are frequently unrecognisable. And therefore don’t get implemented.
Criticism of the cult is worse than heresy
The fact that if you criticise the cult, you will be signalled-out as a heretic is an aspect that I have touched on elsewhere, in articles and blog posts.
If Agile is a cult, then Agile@Scale is like the not-so-great pieces of Scientology, the Vatican, the Eastern Orthodox Church and the Church of England all rolled into one handy but extremely complex take-away. Elegant and eloquent it is not.
What I want to do here is emphasise several proselytising behaviours and quirks found with some examples of Agile@Scale that I have seen up-close and intimate:
- Delusions of grandeur.
- The worship of half-baked ideas.
- The sycophantic adoration of the Führer and the Führerprinzip.
- Despotic and bullying attitudes of the Agile@Scale gang.
- Fixation with liturgy and fetish.
- The belief that data is oil.
- Commitment to the data-driven enterprise.
One could almost speculate that if Agile@Scale were political, it would be a rather nasty totalitarian formation.
On top of all that it’s divisive, expensive, insincere (bordering on mendacious), ingenious, vague, vacuous, trite, unaccountable, cult-like, confessional and hit and miss. It’s not a good look.
Again I’ll lean on the words of Bob Hoffman when I state that these ‘Agile@Scale folk are so monumentally full of shit that they make bozos like me seem sensible in comparison’. Do 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 deception and fraud.
You know, there are two kinds of people: people who simplify things and people who complicate them.
The Agile@Scale crowd love to complicate things, and 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@Scale.
People who know, know how to simplify. People who don’t know how to simplify always need to bullshit, otherwise they are exposed as the poor charlatans that they are.
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 silly claims any more believable, acceptable or useful.
Many thanks for reading.
GOOD STRATEGY 