StupidToScaleAfilonius Rex

Cordoba, 12th May 2019

Ladies and gentlemen, the performance is about to start!

In 1998, as Programme, Product and Competence Centre manager at Hewlett-Packard, I signed the Agile Manifesto.

At that time, I had been using elements of the Agile-method mindset for the best part of sixteen years.

Previously, in 1995 I was trained and certified in Iterations, an iterative and agile-like methodology for building, maintaining and expanding data warehouses and data marts.

So, I don’t really hate Agile, although there is plenty about it to detest; the way rituals are interpreted, the ceremonies that are anathema to the culture of most Europeans, and the cloyingly happy-clappy attitude-changing mind-numbing gob-smacking contradictory-dreck of so much of what it has become. And, I especially despise the way that Agile has been embraced by some folk, which truth-be-told seems to border on manic, religious and lewd fervour.

Now that I have made myself clearer I wish to try and progress with a more positive attitude. So, let’s see how that goes.

Now, I’m not claiming that Agile is a cult, even though it is, because that isn’t really helpful. Neither am I saying that Agile isn’t helpful, as it frequently isn’t, because that doesn’t tell the essential elements of the story that needs to be told. Nor am I here to bash Agile into submission, not that it doesn’t deserve it, because what is needed are sensible is strategies and not solutions for organising the ‘what, where, when, who, why, how and how much’ of what we want to achieve.

I think Agile has a place, especially in the world of software application development, especially in building the kind of software that businesses frequently use in the client and employee aspects of their day-to-day operations.

Done right, Agile can make the difference between great success and a painful failure. Done badly, and you might suffer a worse fate than a badly applied top-down Software Development Method or Software Development Life Cycle methodology. Done well, Agile will oil the wheels of the machine that gets things done and be grown to encompass all software development and testing in organisations.

However, the success of Agile as practiced by highly skilled and experienced development teams has led to some common misconceptions:

  • Agile teams do not require the best and most motivated software development engineers. That Agile will be a success regardless of the collective knowledge and experience of teams.
  • That Agile-to-scale can be applied to every aspect of IT, not just software development.
  • That Agile and Agile-to-scale can be successfully implemented in off-shoring.
  • That DevOps and Agile are complementary.
  • That Agile-to-scale can be applied to every aspect of the business organisation, regardless of domain or function.

I am particularly impressed by how Agile-to-scale, as a revolutionary cause, has been embraced by a number of seemingly competent organisations.

Now, I ask you this. Why would a corporate business put its entire operations and existentiality in peril by insisting on imposing an enterprise-wide transformation programme based on some incomplete, half-baked and badly defined methodology that originally came out of one of the least trustworthy parts of the organisation? Or to put it bluntly, agile-to-scale as a corporate strategy is a monstrous aberration and it would be risky enough if corporations just tried to apply it to all of its IT, so why do it?

But, now everywhere you look it’s there, like a spreading toxic mess within the corps politique of businesses.

Why do I say that?

As part of product design back in the early eighties, I used the Sperry Universal Methodology and also the Sperry Phase Review Process as the guidelines to follow for designing and developing proof of concepts in R&D and subsequent productisation – product development. With mindful management, the corporate methodology could be used in the timely delivery of relatively complex quality products, such as high-performance mainframe compilers, high-volume real-time transaction managers and robust, tremendously secure and blindingly fast database management systems.

As mentioned previously, I am one of the very few certified IBM Iterations practitioners. This was basically a complete end-to-end iterative methodology for data warehouse and data integration programmes and projects. It was comprehensive, clear and complete. It was also agile and iterative by design.

When I used to talk about these methodologies with my Sprint board touting, Java oriented, Scrum process focused software development colleagues they were horrified by the number of details in the old methodologies.

The thing is, that none of these legacy methodologies that I have had the pleasure of using, and using successfully, come anywhere close to the unnecessary complexity, silly bureaucracy and appalling density of the Agile-to-scale methods that I have had the pleasure to see, up close and intimate.

So, it’s come full circle and then more.

The self-chosen light-weights have taken their light-weight cult approach to software development, which to all intents and purposes was just a rehash of rapid application development with some elements of joint application development – which for the most art worked – and over time have turned it into a god-awful mighty tome of Homeric proportions with one big hairy recipe for a mega-dish that includes data, process, procedure, policies, interfaces, events, inputs, outputs, gates and artefacts, etc. – up the wazoo – and that far exceeds anything seen before in terms of size (it’s a bull), complexity (it’s a spaghetti monster) and potential for confusion, misunderstanding and misalignment (it’s the digital tower of Babel, writ large).

The Agile-to-scale commandments are being refined as I write. I do hope that there is no modern-day corporate Moses willing to consider, adopt and willingly spread this nonsense. In the end, the consequences of adopting such toxic ideas could have a far bigger impact than even the crash of 2008.

So, what can be done instead?

If you are that keen on knowing what should be done then drop me a line or leave a comment here. You can also contact me via Twitter at @GoodStratTweet

Many thanks for reading.

Have a beautiful May 2019.

Afilonius Rex