If you think Agility is expensive, understand that it’s a risk premium
In software development, we can’t stress enough the importance of doing small things: small user stories, small refactorings.
Do small things and push them into production as you go:
-
To get user feedback and confirm that we’re on the right track (Agile 101).
-
To secure what has already been done: code that isn’t in production is code on borrowed time.
-
To always have something to deliver, because sooner or later, you’ll run out of time.
In other words, to minimize the tunnel vision effect, the leading cause of insomnia among managers.
However, an objection quickly arises:
Yes, but at every new stage, this forces us to undo a little of what was done previously. Agility is one step back, two steps forward!
In a sense, there’s some truth to that.
Example: You’re an animal welfare organization and want to show families all the cats and dogs waiting to be adopted. You might consider the following steps:
-
A simple page listing the 177 animals available for adoption. Name, photo, metadata, and description all on the same page. A bit rough around the edges, but for anyone looking to adopt a four-legged friend, the information is there. To reduce load time, you add pagination.
-
Feedback: That’s a lot of information; it’s confusing, and it’s not effective since most people have a preference regarding the animal’s gender and age. So you add filters. However, filtering makes pagination a bit less necessary, which creates some awkward edge cases, so you decide to remove it.
So you spent a week painstakingly setting up pagination only to remove it a few days later 🤨
Let’s see what happens if we put numbers to what just happened: if the goal was to reach 100%, we didn’t go from 50% to 70% to 100%. Instead, we hit 50%, then dropped back to 45%, before actually reaching 70%, dropping again to 60%, and finally reaching 100%:
- Theory: 50% → 70% → 100%
- Agile practice: 50% → 45% → 70% → 60% → 100%
Which translates to a slightly greater effort:
- Theory: 100 - 0 = 100
- Agile practice: (50 - 0) + (70 - 45) + (100 - 60) = 115
Strictly speaking, one would have to take into account the cost of removing a feature. Going from 50% to 45% entails a cost of 50 - 45 = 5. Thus, the gap between theory and practice widens:
- Theory: 100 - 0 = 100
- Agile practice: (50 - 0) + (50 - 45) + (70 - 45) + (70 - 60) + (100 - 60) = 130
Looking at the numbers, one might think that working in an agile way costs more. Let’s say that’s true, and that’s fine with us, because the additional cost (30% here) is the cost of certainty. It’s a risk premium: by working in an agile way, you’re buying certainty—namely, the certainty of building a useful product, the certainty of always having something to deliver, and the certainty that the work already done will never be lost, because it’s in production.
Yes, you could move faster by aiming directly for 100%. Except that this reasoning is flawed, because 100% cannot be defined in advance. You can’t say what those 100% of features are, because the need is discovered through use (even your users don’t know in advance!). So there’s simply no basis for comparison. If you start with an ambitious 100%, there’s a good chance you’ll have built unnecessary features and will have to go back much further—perhaps to 50%, or even further—to then build another 100%.
Conclusion: Agility doesn’t cost more; it increases the chances that your product will “connect” with its users. Without it, developing your software is like a game of dice…