So I got exposed to the old Extreme Programming ideas at the start of last decade and really liked them; they focused heavily on the idea of negotiating time/cost/features really sharply and more realisitically than older metholdologies and it seemed really flash, but it suffered from a flaw that it wasn’t really end-to-end - it focused on how a programmer and a client rep could do things more realisitically; it was IMO really only effective with small company/client combos, working on straighfoward, standalone projects.
Agile has the great advantage that it’s more designed to work with more complex businesses: delivery contracts representing the web of dependencies prjects can have across the organisation, making project sponsors responsible for more of the operational costs so they aren’t tempted to skimp to get over the line, and so on. It bundles up a lot of principles of ongoing, negotiated deliverables that XP had, and has a lot of broader business smarts.
But there are problems.
Most of the criticism of Agile I’d have aren’t of the idea of Agile itself, but of how any number of organisations adopt it:
- There’s no buy-in from finance1, so everyone is expected to pitch 1, 2, 3, or longer year plans and commit to the numbers in them, with means one of the key sliders around financials aren’t available.
- This also means projects end up to making all sorts of decisions around tech, design, etc, up-front instead of ongoing as they’re supposed to
- There are no financial mechanisms for recharging operational costs back to sponsors. This encourages old “do a half arsed job,chuck it to the run teams, let them sort it out”, which is one of the things Agile is supposed to mitigate.
All of these are problematic, but the first is the most fundamental issue. Core to the ideas around accelerating delivery, whether from older iterations on the idea like XP, Agile itself, or whatever becomes the successor of Agile2 is the idea that trying to know the future down to the last detail doesn’t work: plans don’t survive contact with the reality. But since you’ve got your finance team insisting that you must meet your goals around money, you:
- Lose the ability to adjust the cost slider: you aren’t allowed to spend more to meet your feature sets or delivery times, because then you’ll blow this year’s budget. It doesn’t matter if the product owner or the sponsor thinks that’s worth doing - too bad, the departmental finances show failure if you choose to spend more.
- Lose the ability to adjust the time, feature, and quality sliders: that’s because you’re also measured against the benefits you said you’d realise. So you can’t spend the same and deliver later, or a smaller set of features, because you won’t realise the benefits you laid claim to.
So what to do? Given that you’ve taken away all the tools Agile says a team might use to deal with the challenges of delivery, this pretty much adds up a lot of toxic old behaviours (no documentation, cutting corners for delivery, and so on)being labelled “agile”3, which brings the idea into disrepute.
Unless people are actually prepared to align their financials and incentives to the way Agile is supposed to work it’s always to to struggle and may even make some things worse, not better.
-
When groups used to thinking in terms of manual checkpoints, such as infosec or change management, don’t buy in to trying to do things differently, that’s extremely unhelpful as well, but none of them can cause the damage a determined finance team can. ↩︎
-
And there will be a sucessor, because the basic ideas driving the adoption of Agile methodologies, not just as a way of building software, but as a more generalised way of thinking about running a business. ↩︎
-
“Oh, but we didn’t ditch documentation, we put it on as a backlog item!” Which will of course never be looked at. ↩︎