Why Agile Doesn’t Work

I’ve started to try and look for a pattern in everything. Specifically, with my approach to product, I try to look out for the one thing that either makes everything else easier. Russell Brunson has called this ‘The Big Domino’, as it represents the one thing we can do that knocks everything else down & makes them irrelevant. Other entrepreneurs have used another word for it, but it’s essentially the same concept:

If we can work out which single belief or action will have a huge impact on helping us achieve our goals, then we should focus all of our energies on that one thing.

If, for example, we are starting a new product, if we can work out which one feature we can launch that will help us achieve profitability - or simply our first paying user - then all the other user requests & concerns simply don’t matter. We’ve knocked down ’The Big Domino’ that makes all of those concerns irrelevant.

Unfortunately, this concept also works the other way. And a misguided action or belief can make it near impossible to help us achieve what we want to achieve: In this context, building a product that delivers value for users & turns a profit.

Say, for example, you believe that the Bible was written by God. That ‘Big Domino’ assumption means that we generally also believe everything that that assumption signifies: that we also, therefore, believe that homosexuals should go to hell, that marriage is sacred, that we go to Heaven, etc.

And one of those ‘Big Domino’ misguided beliefs that undermines product success is a belief that Agile is the right process to help you deliver significant user value whilst also turning a profit.

And because so many teams blindly trust in the Agile process, they have essentially blocked themselves from ever knocking down ’The Big Domino’.

Why Agile Doesn’t Work

Agile as a theory promulgates, at it’s core (according to the original Agile Manifesto from 2001), the idea that teams should consider user needs above all else, and to adapt quickly to a changing context & new information, as opposed to arbitrarily planning too far ahead.

Yet the way Agile manifests itself in practice tends not to reflect these values (as they were intended to be practiced).

 1. User-centric decisions

Teams create tasks with the user in mind, for example, defining tasks by stating that ‘Our user wants to change their password because …’ Yet too many teams fail also to consider the somewhat more important point here:

That we must consider the amount of value we are delivering to that user and that, if that value is too low, then we simply will never deliver enough value for the user to use - & ultimately pay - for our product.

We can give them the best ‘Settings’ page they’ve ever seen, but, considering every team has limited resources, that almost always means we aren’t being ruthless & focused enough on just iterating the one or two features that deliver massive value to our users (our ‘Big Dominoes’).

2. Adapting to change

Quite simply, chaos reigns.

Walk into most startups these days and you will see a lot of activity, a lot of people rushing around, a lot of people busying themselves, but almost always lacking a clear direction.

We can be agile - and move and adapt quickly - but if we do not understand to what end, then it’s all wasted energy.

It’s just effervescence.

In practice, it is far too common for Agile teams to lack a clear strategic direction for their work. And without a clear strategic direction to move in, all of our experimentation and adaptation and changing based on new information is largely wasted.

43% of all adults suffer adverse health effects from stress, as well as 75-90% (!) of all doctor’s visits stress-related (sorry, I’m not willing to assign the time this week to track down where these stats came from, which are in the book somewhere, so you’ll have to just trust me (or not trust me and ignore this paragraph).

And there is a huge amount of evidence now to demonstrate the negative effects of stress not only on our health, but also on our decision-making.

So again, when we consider the need to adapt our strategy to constant experimentation, changing macro-events & new information coming in from our users, teams are under too much stress to really approach how they adapt clearly or logically.

This is why chaos reigns and most startups just bubble with energy, rarely progressing tangibly towards their goal of building a profitable business.

Agile isn’t Human

Low-impact decisions about what to build for our users, as well as a chaotic environment that seemingly adapts at random are problems, sure.

But they can be improved upon - and they can also easily be attributed to the failings of each individual team in not hiring the right people, building the right culture, etc.

But the really ‘Big Domino’ that undermines a startup’s success is this:

That Agile optimises for being efficient at the expense of being effective.

That it focuses us on getting more done (more code, more tasks), rather than working out what the one or two things we can do that will have a huge impact on our user (‘The Big Domino’ that makes all other tasks irrelevant).

Let me be clear: This is no critique of the theory. Agile as an approach to developing products clearly states that delivering value must lie at the core of any product process.

But the physical manifestation of Agile in how we practically manage the day-to-day process of building things completely blows this theory out of the water.

Scrum = Being Efficient > Being Effective

Scrum, if you haven’t heard of it, is a methodical approach to managing product development.

It helps us align a room full of people around what the goals are, who is doing what, and how & when they will execute.

It’s a more refined to-do list, to not get too much into the details.

However, one fundamental thing to know about it is that Scrum is based on a metric of story points - estimates we assign to each task to determine how long it will take (or sometimes how complex we expect it to be).

So let’s say we are working on a new task:

‘Our user, John, wants to upload his holiday photos to our app.’

The Scrum Master (essentially a product manager that organises the team) will maybe get a designer & a developer in the room and ask for an estimate on how much complexity the task might involve and - ultimately - how long it’s going to take them to finish.

Theoretically, this works out pretty smoothly.

The Scrum Master should have thought through what makes sense to build (i.e. what ‘Big Domino’ could we work on that potentially delivers huge value to the user).

But usually they don’t.

Because they aren’t really incentivised to do so.

They are incentivised by the metric they see right in front of them: Story Points.

And when we are given a metric to track progress, it’s human nature to optimise for that metric. It makes us feel like we are progressing, and it’s a simple way to measure how are team are supposedly progressing.

But the problem there is that it means we default towards optimising for efficiency (i.e. getting more stuff done) and not pushing ourselves to optimise for impact (i.e. building things that deliver huge value).

And users don’t give a shit about how much time & effort went into something (I’d love it if they did!). They simply don’t know and they simply don’t care. They want to know whether the product solves their problem effectively. If it doesn’t, see ya later. If it does, great, give me one of them and here’s some money for it.

So, clearly, if, in reality, the outcome of Agile theory is a misapplication of that theory and a tendency to optimise for getting more done (the whole reason the Agile Manifesto came about in the first place!), then Agile simply is not working and we need a new approach.

That approach, one I outline in detail in my upcoming book, is one where we take the principles of Agile - of focusing on delivering user value and adapting strategically based on new information & a changing context - but apply them in practice with a process that optimises for impact. Where each task becomes an experiment. Where each thing we do is in the pursuit of discovering ‘The Big Domino’ that will help us reach our next ambitious milestone. Where we stop worrying about the bullshit of stress, of trying to squeeze 10% extra from each day, of busying ourselves with endless rubbish.

My process is a tried and tested way to actually build products that matter - that deliver value and turn a profit.