Why Agile Fails – and how to avoid it?

I was talking to an ex-colleague who works for a large UK based bank, and he was complaining about the Agile fad. His assertion was that Agile does not change the ground reality of banking – delivery remains a challenge, they still suffer long delays – the only thing that it changes is that people work in sprits instead now. 

This is not the first time I have heard something along these lines.  For those of you facing a similar situation, I put together a real simple primer – only two things that you need to do to start reaping the vast majority of benefits from the Agile transformation.

Step 1: Acknowledge that you, the senior management, does not have all the answers

Senior management in most large companies is used to calling the shots and telling everyone else what to do. And by all means, that’s a good strategy if you know what to do. Maybe you run a business in a very benign environment or you are exceptionally gifted and know exactly the right answers to all that ails your company. In that case, Agile isn’t needed. In fact, a Waterfall approach would work better. Of course, since you know the answers upfront, that means the requirements won’t change midway through a project, right?

However, most large companies do not have this luxury, least of all banks. As Rory Sutherland, Vice Chairman of the ad-agency Ogily and author of  the Alchemy: The Surprising power of ideas that don’t make sense, says most organisations focus on establishing the why before they do the what. This is usually a great approach – issue is that over time we solve all  the problems that we can solve logically and the ones that remain don’t always follow logic. Take the example of Red Bull – the energy drink. When they first conducted market research on it, it utterly bombed in the research… people in research weren’t just lukewarm about the drink, they mostly hated it. In fact some of them even said that they wouldn’t drink it even if they were paid to do so. Fast forward to today and Red Bull is one of the most successful drinks in the world. Talking about banking, a big problem for Banks tends to be how to differentiate against their competitors, who have a very similar product offering and pricing – no one has a precise answer to these difficult problems.

Good news is that throughout human history, we have been a lot more successful with hit and trial to come up with solutions rather than figuring it out first and then creating it. That’s why the Wright brothers succeeded in building the first aeroplane, beating much better-funded competition and that’s how Edison created the light bulb (it is claimed that he failed a thousand times before making it work). In fact, that whole evolution is hit and trial too – random mutations, some of which work and most do not.

Agile follows the same philosophy – Empower small cross-functional teams (We call them squads) to own a problem give them autonomy to test and learn as they see fit. As a manager, you can help them to think – but the final decision is the squad’s. 

Step 2: Ruthlessly reduce time and cost to test 

If you acknowledge that you do not have all the answers, then logically you need to be able to test multiple possible solutions to come to an answer. In most companies, this is easier said than done. So here is a small guideline

1. You cannot invest enough in automated testing, deployment and data collection: If you are an IT manager, your teams should be able to deploy at least once a week, ideally more frequently. The longer your test cycles are, the bigger chunks of work will go in each test cycle. – this means for every experiment that doesn’t work, you will throw away more code. Very soon, the false economy of not investing in the testing infrastructure would be overtaken by the wasted effort of your squads. Similarly, if you can’t measure what impact your tests are making, there is no point in doing those tests. But if the analysis of the data is going to be tedious, it will slow down the squads and is again false economy.
2.  Make it easy to test multiple variants simultaneously: This is also called A/B testing but it is important that you can test as many variants as needed, with different audience in different contexts. The problem with us humans is that what’s acceptable in one context is not acceptable in another. For example, when I am watching Youtube, the ads don’t bother me that much. However, when my seven-year-old son is watching his videos, I am always worried that will he be shown age-inappropriate ads. Who hasn’t been to a holiday and discovered a drink that they really liked, only to try it again after returning home but this time the drink didn’t taste so good? That’s not because the drink has changed, but because we are no longer in the same environment, and strangely that changes how the drink tastes to you.
3. Do not design for the average: Do not try to come up with a solution that kinda, sorta fits the needs of everyone. Aim for either one, or if you have the money both of the two extremes – a super simple experience that even a child can use (in our cases, it is usually the older customers who have more trouble than children), or an interface tailored for advanced users. A halfway house is not going to please anyone, and the bad overall experience will also skew your test results. Not convinced? Think about which companies did well out of the financial crisis? Those who targeted the lower end of the market and those that aimed for the higher end – those that were stuck in the middle perished. Same applies to experiences. 

Try the above for six months, and I guarantee that you will no longer think that Agile is a passing fad, and you will have much happier teams and customers to boot.