The concept of Agile software development has reached primacy within so much of the technology industry. For certain types of software, it seems to be proven through popularity if nothing else that Agile produces better software. But what if the answer to the challenge you are facing isn’t in code?
In the world of startup, the answer is probably that Agile development of software that is attempting to answer a non-software problem is failure. It seems to be widely accepted that 90% of software startups fail – and that’s presumably a number that doesn’t include a far greater number of embryonic ideas that don’t even make it to startup stage. Some of that failure will be because of lack of luck, some because of poor management, but many will be because they are half-arsed ideas to non-problems (“Hey, it’s like Facebook, but for frogs!”), and the others are because they are trying to address something through software which has other factors in the way (usually: people).
I don’t know many organisations that can significantly fund projects (particularly internal technology projects) to 90% rates of failure. In fact, most organisations have systematic processes in place (investment proposals) that are designed to mitigate against such numbers. Whether those processes work or not it a moot point.
But investment processes tend, from experience, to test the idea against other similar ideas or doing nothing; a proposal for investment in technology will be compared against other technological approaches. And the processes themselves become self-fulfilling prophesies because the people involved are so focused on the success of their idea.
From a business management perspective, the software option is compelling: hard, nasty, intractable problems like changing people’s behaviours can be circumvented through the rainbow-pooping unicorn of software. Especially if that rainbow-pooping unicorn comes in new App/big data/cloud/wearable/AI flavour (delete tech buzzwords du jour as you see fit).
If anything, the current trends around digital, agile, cloud and the like are making the issue of “stupider, faster” even more acute. Everywhere you look in the media at the moment is reinforcement that software is the answer to everything.
So how to look at challenges from a broader perspective? I have seen little over the years better than the benefits mapping technique I was first introduced to 15 years ago. Having a discussion about what an organisation is trying to achieve, how it might know if it’s achieving it, and what changes (people, organisational, customer, legal, behavioural as well as technological) might push such changes is hard to beat. The most success I’ve felt in my career without a doubt is when I’ve helped organisations to see that they can achieve the same or more with a bit of better communication between people and a few tweaks to working practice than from major and risky investment in software.
I realise that this “No software” approach challenges current orthodoxies, but within organisations today I’ve no doubt that we are seeing real issues and opportunities being ignored in the pursuit of the rainbow-pooping unicorns.