Agile development has grown deep roots in the software development world. But it’s well past time we recognised that it isn’t doing what it was meant to do. In fact, it’s doing exactly what it was meant to replace – wasting money and time on processes that slow down putting software into the hands of users.
Let’s be really clear. The concept of Agile Software Development — the simple, clear manifesto of principles set out by a group of 17 developers back in 2001 — is at its heart an excellent ideal for how to make software that delivers fast and stays focused on solving real business needs.
Interactions over processes and tools, responding to change over following plans, early and continuous delivery of software to solve real problems for real users, and iterating quickly based on real user feedback — these are all powerful ideas in smart, effective development.
It’s not one thing. It’s an umbrella concept to work in a way that keeps the emphasis on putting software into the hands of users as close to the start of the project as possible.
How many of those ideas are recognisable in the typical agile “process” many experience today? I’ll bet you a million JIRA tickets and Trello cards that nine out of ten agile projects are not.
The evolution of SAFe (Scaled Agile Framework) is a laughably complex approach to development. With massive process diagrams and language of “patterns” and “frameworks” all trying desperately to avoid the word process, there remains an awful lot of demand on individuals and teams to follow a plan that was defined at the beginning of the project.
Of all the failures of agile, it’s this question of following a plan that has sent us back to the 1980s. As soon as organisations put costly pre-project planning back into the development cycle, they turned agile into little more than performance art.
With detailed pre-planning, approval processes, and promises of certain things to the people who give us the money, we’re back in the land of contracts and documentation and scope. If we’ve pre-defined a technical design, we’ve stopped being agile. It’s as simple as that, and it is fundamental to why so many “agile” projects spend all the money building one thing and discover way too late that it wasn’t what the business really needed. What’s agile about that?
I’ve spent a lot of my career working with organisations to solve problems after they’ve spent millions of dollars trying to fix it. Problems consistently relate to rigid “agile” plans that pointed all the money at building an inflexible answer that had little to do with what users could have told them they needed.
In one case, I worked with the Victorian Government after they spent $2M on two failed projects to bring efficiency to its ministerial briefing paper processes. One SaaS failure and one software customisation failure. That’s two million dollars and two years of being stuck with the existing problems that were impacting staff wellbeing.
How did this happen? In no small part, we can look at the Agile Manifesto again and realise that for all its ideals, it doesn’t offer any actual advice on how to “do” agile. I hope my own experience can help paint a better picture for how real agile teams deliver fast results and massive cost benefits to the organisations we serve.
In our approach, we find that by maintaining a simple target of delivering a solution to a real-world problem and not a “piece of software,” it only takes a few meetings to understand what we’re trying to achieve. Having a clear discussion about the real problem we’re trying to solve means we can price low-risk work that delivers high-value returns to the business.
In that Victorian Government example, we solved the inefficiency problem within nine weeks at just 10% of the cost of the money spent on those failed attempts.
In another project, at Sydney University, we saved admissions staff from thousands of manual support requests in less than three months, with a single course pilot live in four weeks and a pilot for all agents in just eight.
The key is in engaging directly with the users as quickly as possible to uncover exactly what they need. If you’re not tackling a real solution for real users fast, then you’ve disappeared into the land of performative agile.
So how can you tell the difference? You can identify performative agile with a simple question: how much of the allocated budget has been spent before a real user starts using your software in production? 10%? 50%? More? If it’s anything more than 20%, you can’t say you’re doing early delivery of software.
All too often, I see a million or two spent only to discover that a “solution” solves what it was defined to do but fails to make life better for users and customers. The money is gone right when you find out how far off-target your solution turned out to be.
Executives should care about spending the money on building real features users have actually asked for. To start, sit down and talk to people who will use the software. Ask them what to build. By connecting developers with users, you reduce your failure rate and become more efficient at delivering value.
You also simplify the maths when you aren’t wasting time before you start building while also reducing your risk. If you pilot for five users after one month of a twelve-month project, you’re getting great value from feedback at a point where too many other projects are still defining scope.
Real agile means proving a concept through production instead of defining a scope before you even start. It means developers get to work and embrace a direct relationship with users to build something useful. It means businesses invest in rapid prototyping and proof of value that shows results that can lead to faster cost benefits.
It’s time for more self-reflection amongst developers to call out the complexity that is undermining early delivery of software to real users.
Enough performance art. Let’s get back to delivering real value.
Get ThunderLabs to build you the right cloud solutions that create efficiencies where they are needed most. Contact us today.
Andrew Walker
CTO and Founder
The Impatient Futurist of the technology world, Andrew is on speed dial for the likes of IAG, Walmart, and NewsCorp. Andrew has built and sold businesses (making 11 people millionaires in the process), launched products, written books, and led projects for the world’s most complex organisations.
