Agile is undead

Just in case you were under the impression that Agile is intended to be a simple alternative to humungous bureaucratic nightmares of various kinds, along come Deloitte with their terrifying vision of Agile 3.0 (right-click to expand). Looking at their very pretty little diagram, it’s not hard to conclude that:

  1. This is about selling consultancy services (Why buy consultants if it’s basically easy?).
  2. No-one at Deloitte has any idea what Agile means.

 

Having said that, I can’t actually disagree with the diagram. All these things are there, and the online savaging this diagram (and its author, Chris Webb) received is not wholly justified. So Jason Yip and Craig Brown both seem to have called it about right. (Deloitte’s own rationale for this thing can be found on their website.)

Yet the failing in the diagram is not that it misrepresents Agile – Agile really is a rapidly burgeoning mess – but that the source of the failing it documents is not mentioned.

In reality only about half the things on this diagram deserve to exist. That’s not just because some of them seem just made for the purposes of creating a USP for some consultancy or tool vendor, but more because many of these tools and techniques overlap and many are simply confused. Oh, and quite a few look like queasy attempts to smuggle old waterfall concepts back into Agile. Because, as we all know, waterfall works so well.

So what is the underlying problem? In a nutshell, one of Agile’s great shortcomings continues to be its lack of true abstraction. It has consciously stripped delivery of every complication and eliminated everything that smacks of telling professional developers how to do their own job, but the very reduced list of ‘Agile methods’ that leaves has only made it easier to do just that – have a list. Not a rational model or a defensible analysis of delivery or software engineering as a discipline or professionalism, or any of the other things that make Agile special.

And the problem with any list is that you can always just add another item. And another, and another. Until you have the sort of monster you see here. And no, drawing your list to look like a subway doesn’t mean it’s anything but a list.

A proper logical analysis, by contrast, results in a model that at least makes clear not only a) what is really part of Agile but also b) what really isn’t, and c) what is simply a variant on an existing theme. On this basis, Agile could be kept small & simple without losing any of its power or openness to future improvements.

To make a rather forced and pretentious analogy with physics, if you understand what the terms mean, E = mc2 really does encapsulate the whole large-scale universe – but only if you understand what the terms mean. Einstein arrived at his famous equation only after a mass of predecessors had defined all the other terms that you can’t see in the equation, but which explain what the relationship E, m and c actually tells us.

Likewise a proper definition of Agile would allow us to identify what really is part of Agile, to rationalise what is confused about Agile and prune out what simply doesn’t belong. Then the various attempts to smuggle in obsolete waterfall concepts would be exposed immediately. In fact it would be impossible to introduce them in the first place.

Arriving at such a definition won’t be easy: at risk of another ridiculously pretentious analogy, Agile is a bit like quantum mechanics: unlike other scientific theories, quantum mechanics was discovered before anyone understood what it was (i.e., it wasn’t built up progressively), and even with some pretty smart contributors it was a decade or so before even the basics were properly sorted out. Agile is similar, at least in the sense that it was invented before it was understood, though I have slight doubts about how smart its architects are, at least compared with Einstein, Bohr, Heisenberg, Dirac, Shrödinger and quantum theory’s other major architects.

Anyway, assuming that we could construct a proper model of Agile, I would guess that at least half of the items on Chris Webb’s chart are the same as some other item on the chart but in a slightly different guise, created for a slightly different purpose or represent only a slightly different flavour of the same thing, possibly for sales purposes – after all, its author is a Director in the Enterprise Information Management at Deloitte. In fact I would guess that the whole map could, with a little thought, be replaced by a small number of key abstractions, and individual tools and techniques could be derived from those abstractions, as and when needed, much like solutions can be derived from equations in physics. And then we could stop representing Agile as a subway map crossed with an octopus and forced through a shredder, and start to pull out true engineering principles.

Like Craig, ‘I wonder whether the rain of criticism showered on Chris is because he has in fact revealed the irony of the industry’. Indeed, the fact that Agile has become such an industry is the problem, not least because, as I suggested above, Agile is fundamentally so simple that we don’t need an industry to support it.

So if this is Agile 3.0, please God get us to Agile 4.0 ASAP.

By |2018-02-08T18:37:46+00:00Monday, December 19 2016|Categories: Agile, All, Bureaucracy, Consultants, Process and method, Thought leadership|0 Comments

About the Author:

Chief Architect, Agile201.com.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?             
error: Agile201 is wholly copyright and copy-protected.