Anti-Agile
How Agile Methodology Destroys Products
A Startup Crisis
Something is deeply wrong with the way startups approach building a product.
90% of startups fail.
In any other industry, that kind of failure rate would be a cause for alarm at the least — but it’s more like a full-on crisis.
90%!
Even allowing for the uncertainty of innovation which makes building any business somewhat risky, 90% is alarmingly high.
And Agile product development lies at the heart of this failure rate.
Let’s say that 20–30% of those startups would fail regardless — due to the simple fact they have no clue what they are doing or aren’t fully committed to it from the start — that still means that over half of startups who apply an Agile product development process will fail.
And yet, despite this fact, everyone simply continues using this model — a model that objectively dramatically reduces their chance of success — without questioning it.
I mean, why would they? Everyone is following Agile. Everyone, that is, apart from a handful of startups who share my view that there is another, far more effective way to build products better, faster, with a far higher rate of success.
Why Agile Doesn’t Work
In theory, Agile methodology promulgates a data-driven, customer-centric approach to building software — and building it & adjusting to new information fast:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
— The Agile Manifesto
Yet what that means in practice is a whole lot of low-impact busywork.
Teams respond to every user request, saying, “Our user, Sally, would like to update her email address on the Settings page”.
They rush out new features as they respond to what Sally might have said or needs, feeling pretty good about themselves that Sally can do whatever Sally wants to do with their product.
They proudly boast about dynamically responding to change, jumping from here to there to adapt to all Sally’s wants and needs.
But I’m yet to see a single team follow this process and not simply optimise for efficiency — for simply getting more stuff done in a shorter space of time.
The theory (one that supposedly provides a robust platform for building a profitable, successful product) simply doesn’t work in practice.
The reality doesn’t match up.
Agile focuses on efficiency, not on impact.
By quantifying what a team is getting done, through carefully considered estimations of how long & how complex a task may be, as well as running weekly sprints to put a quantifiable number on how much we are getting done — and how quickly — we focus on something that simply doesn’t matter.
Whether you mean to or not, your team will optimise for efficiency when efficiency is the thing being measured.
Humans optimise for whatever is quantified. Teams optimise for whatever is being measured. A simple metric put on our work makes it easier for us, as humans & team members, to feel like we are progressing and contributing towards our team’s goals.
So we end up trying to get more done each week, ruminating on how we can optimise our process & move faster.
We become stressed, we sleep less, we think less, and busy ourselves with inconsequential tasks as we relentlessly strive to just get more points on the board — to get more done — whilst ignoring the blindingly obvious problem with this approach:
That efficiency doesn’t matter. That impact does. And that actually making significant impact with our product with bold new features & deliberate, strategic decision-making is the only way to do that.
That Sally’s endless feature requests & your rapid response lead you down a road to failure: One where you build a stream of low-impact features that may be built quickly, but never help you build a simple, high-value product for your customers.
Another Way
Imagine, instead, if your team actually focused on what mattered. Actually measured and optimised for impact. On how much each feature is expected to move you towards achieving your goal — maybe a bold metric of retention or of paying customers.
Imagine how that would change the very nature of the work you do?
Imagine how, as an individual, your day would look if you focused on high-quality decision-making, focused on building one high-impact thing, instead of rushing around in a panic, trying to busy yourself with as much work as possible?
Imagine how, as a team, your work would change. Less agility, more deliberate, carefully considered decisions being made about what really matters. More effective collaboration towards a common goal. A culture that values a calm, mindful workspace conducive to high-quality decision-making, rather than the usual mad panic of most startup offices.
Imagine how your approach to product development would change. Instead of optimising for how much you get done each week, you optimise for the impact you are actually having with everything you do. A measure of learning and of concrete progress towards your goals as a team, rather than whether you hit your arbitrary sprint targets or not.
That’s where my approach to building successful products comes in — one focused on building a team of high-quality decision-makers focused on impact over efficiency, guided by a tried-and-tested product development process for building successful products.
Join the product leaders who do things differently. Check out my upcoming book ‘Why Your Startup is Failing’.
