As promised, this segment will not discuss Agile, but it will discuss agility, the namesake thereof. I even hope to work in fragility or else the title will make no sense. Stream of thought exposition without a net.
Agility is something that even enterprises should aspire to, but agility can only manifest as a tradeoff for stability or predictability. One can’t simultaneously have both. In the Information Technology space, Gartner Group has suggested a bimodal model where an enterprise can support both the stable big projects, e.g. infrastructure and software delivery product projects, but one can’t deliver the stability of an infrastructure project with agility. You may want to argue that you can deliver it relatively more agilely than some other possibility, but this is akin to Elon Musk travelling to Mars (please, oh, please) one mile an hour faster and calling it an accomplishment.
Agility is the ability to change on a dime-—whether abondonning an intended inclusion or introducing a last-minute change without materially affecting delivery.
Don’t get married to your output
Agility is the ability to pull a feature that didn’t quite pan out. It’s the ability to cut one’s losses and ignore sunk costs for budget already incurred, but feel free to shed some sentimental tears. Early in my suite of careers, I was a recording engineer and producer. I worked on many projects that never saw the light of day despite my having worked on then for weeks or months on end. It happens. I remember working for 50 hours over a weekend to ensure a final mixdown could be at LAX by 10AM on Monday morning, so they could commence filming in Spain. The tapes were still in flight when the project was cancelled. The moral of the story is don’t get married to your output. Don’t even get attached to your work in progress. Let it go. As the second Noble Truth reminds us, suffering is due to attachment. Dukkha.
But companies will usually opt for stability and predictability over agility—pretty much every time. In a vacuum, they’ll tell you they want agility, but when push comes to shove or in a forced ranking, it will move down in the list.
I know I promised not to discuss Agile, but one of the other benefits—and this does tie into agility—is the early and frequent releases to realise value. This value may be new revenue, revenue protection, cost avoidance, or information. If the feature is successful, presumably it will benefit your top line sooner. If it fails, you may avoid spending budget later on ancillary or tangential features. In between, you may learn something and pivot or just tweak something to get better traction.
What about fragility? Nicholas Taleb wrote about anti-fragility and black swans. Whilst fragility is inherently the quality of being easily broken or damaged or the quality of being delicate or vulnerable given some eventuality, antifragility is the quality of getting better given the same eventuality. Antifragility is a property of systems in which they increase in capability to thrive as a result of stressors, shocks, volatility, noise, mistakes, faults, attacks, or failures. Clearly, this might be the Holy Grail.
With stability comes fragility. It’s easy for a project to derail. In fact, this is why over eighty per cent of large projects are challenged or fail. They are fragile. One cannot plan for a stable project outcome and not have a degree of fragility. Moreover, the level of fragility will be high. Agile only lowers this factor, but it never gets to an anti-fragile state. No grails to be had here, but we can still minimise development risk through agility. Risk gets manifest relative to stability, so we need to get the balance right.
One thing management types request is predictability because they are so used to implementing projects with long development times. With shorter release cycles, the need for predictability is ostensibly reduced because with each feature release, uncertainty converts to certainty.
Say that I have an idea for a software product and can envision what it could look like in a year given the lay of the land today. I could spend time designing and architecting a solution for three or four months, developing for a feature release every six weeks. I could have said two or four, but I’ll give a typical rather than best case scenario.
As an economist by training, I understand the concept of the time value of money. This says that in an inflationary environment—which is to say pretty much every environment—, a dollar (or shekel) today is worth more today than tomorrow or a year from now. The sooner you can realise value, the better because you can invest it elsewhere if so desired. Waiting longer to potentially realise value is simply not good financial management.
Add time value of money to uncertainty of adoption and the cost savings of taking a minimum viable product, and you should have everything you need to convince you that long planning cycles are a bad idea from the get go.
The funny thing is that we already know this intuitively. The question is why do we still insist on long planning cycles, copious documentation, and overstuffed feature development cycles? You may defend that you do know better, it’s management on high who doesn’t know this. But they do know it, so what gives?
If comes down to trust. They simply don’t have faith in the process, and they don’t trust you to deliver, so they kid themselves by introducing an illusion of control. The punchline is that they would have greater control if they released in six-week cycles, as each cycle would deliver more certainty. This isn’t to say that every delivery cycle will be a success, but you will know if the idea was a good one soon after you make it available. And if it is a good idea, you can cash in your chips. If not, you didn’t go all in, and you can play a few more hands.