Which path to take?

I spend my time flitting from organisation to organisation, across many different sectors, and looking at often quite different challenges. Technology is usually the linking thread, although not always.

A question that I’m not hearing being asked in a structured way in organisations today is “Which approach should we be taking?”. What instead seems to happen is that organisations have either tied themselves to the agile mast and claim that everything is agile, even though if you lift the cover you’ll find things that look remarkably like waterfall projects, or alternatively you’ll find companies that haven’t moved to agile but have got pockets of agile stuff going on where the motivation is there to do so (not necessarily where it is most appropriate).

No matter which case exists, financial approval processes will invariably expect descriptions of known outcomes and benefits and exact budgets from day one, which in turn is about as agile as a marble statue concreted into the support pillar of a motorway intersection.

So what approaches should be being taken? Agile is not the answer to every problem. Nor is waterfall. And there are other approaches available too. So, just because I’m a sucker for a 2×2, here’s a way of looking at it…

It’s a kind of Rumsfeld analysis of scenarios on the basis of level of understanding of both problems and solutions.

The top right, Known Problem, Known Solution is the type of scenario that it seems to me most financial control processes expect The World to work to. If you are building a house or opening a new shop or installing a network, you can be fairly sure that you can know what you want (although to what degree of granularity is open to question), and also be fairly sure that it’s a path well enough trodden, that a plan can be drawn up in advance which will be accurate enough to be useful.

Where you know what your problem is, but you don’t know what the answer is, agile will give you the best options. Agile processes (or service design approaches) might well make you realise that you didn’t know the problem as well as you first thought. That’s not a bad thing. If you don’t know what the solution is, the best you can do is to understand what the problem is worth and then cut your investment costs accordingly.

Unknown problems and unknown solutions are where organisations (in my opinion) need to up their capability. This quadrant is where you explore the possibilities of new technologies. You should invest here on the basis that the main outcome will be increasing the organisational capability to deal with emerging innovation and ambiguity. Something else useful might emerge, but that shouldn’t be the main objective. Things like accelerator programs fall into this category.

Finally, known solutions to unknown problems are a terrible way to frame things. I’m hearing a lot of these at the moment in the context of “Blockchain” or “AI”. These are types of technology, not answers or solutions per se. Reframe the scenarios in one of the other quadrants (probably one where the solution is actually unknown).