As I’ve noted previously, I’ve given up wittering on about Agile and how poorly it is understood or implemented. Instead, I am going to focus on agility and the lack thereof. Despite having worked in a truly Agile setting, I’m not sure I am the proper authority to defend the orthodoxy. The detractors usually defend their misimplementation as part of the afforded flexibility. If you’ve ever been gaslighted, this might feel very familiar.
The reason Agile gets dragged into the conversation so often is that people use Agile terminology and and try to suggest it by adopting tired methodologies like SAFe (Shitty Agile for Enterprises), Wagile, Water-scrum-fail, and so on. To be fair, water-scrum-fail is a bit untoward. Perhaps, fail-scrum-fail would be a better moniker because it captures the points of process failure.
Water-scrum-fall fails at the start. The naming choice represents the injection of an Agile process into a meatless Waterfall sandwich, with Waterfall being the bread slices, though certainly not the best thing since sliced bread—the true marvel of the Twentieth Century.
The Water at the head of the beast is a load of administrative red tape and subterfuge. Those used to Waterfall are all too familiar with this bottleneck. One thing that makes Waterfall superior to this Wagile instantiation is that requirements are more buttoned up, so there is more information available for estimations of time and financial budgets. In fact, this approach trades off one time-related risk for another. Presuming to know all aspects of a large project is a pipe dream. Agile recognises this. But failing to collect this information upfront shifts the Discovery and Definition time-sink to the executional phase, denoted here by the -scrum- aspect of Water-scrum-fall.
In a true Agile setting, during what we are siloing as -scrum- here, we would see iterations and delivery of value every sprint or so—perhaps cycles of two or three sprints—, at each point releasing new feature functionality into the wild to test and learn. Continuous Integration and Continuous Release is the most agile of approaches as it allows for both the earliest feedback and the earliest value realisation. These are tightly linked to minimising costs on unadopted features, something Water-scramble-fall fails at.
In Water-scrum-fall paradigms, like SAFe, this -scrum- work gets queued up into a work-in-progress inventory staging area, where it accrues no value. Unlike wine and cheese, ageing doesn’t enhance value in a software delivery environment.
During the -fall phase and the tail, we see the work-product dequeue into a production environment. I’ll characterise this proverbially as a day late and a dollar short. We’ve missed the opportunity not only to realise value earlier, but we’ve also missed the chance to test and learn, perhaps even to pivot or abort our intended path. I’ve discussed this previously when a competitor in one industry was spinning up an initiative in an attempt to follow the industry leader. Little did they know that the leader had already determined that this idea was a dog with fleas and they were in the process of unwinding this offering and putting this flea-ridden dog to rest. Under NDA restrictions, I was not able to communicated this to them. The only thing I could do is to signal how bad of an approach it was to build out the entire solution that was destined to arrive dead on arrival.
That leads us to another topic that supports agility and incremental delivery over long cycles. Research shows that adding new feature functionality to existing products has a longer term adoption rate of about twenty per cent. New products fare even worse with an uptake of about ten per cent, and that’s if the product is adopted at all. This isn’t to say not to add new features. It’s to say, take an incremental approach. Add a feature, having made a hypothesis upfront around value and adoption. Monitor the feature in situ. Evaluate if the hypothesis is correct. Decide whether to cut your losses and pull the feature, to tweak your feature a bit, to pivot to a new direction or try a different feature, or double down and full-speed ahead because this new feature is getting traction. Pat yourself on the back for avoiding the temptation to add ten features, eight or nine of which are unlikely to be adopted enough to return net value.
One of my favourite test and learn stories—if not on accident—is the Domino’s Pizza story. This enterprise started in a dorm room. No garages here. The original offering was either cheese or pepperoni pizza and Coca Cola. No other topping options. No other beverage offerings. Keep it simple stupid. Easy on the inventory. Avoid the paradox of choice. And over a forty per cent all pizzas served in the United States are either plain cheese or peperoni, though this varies widely by state. For example, 40% of people in Georgia ordered pepperoni on their pizzas, while only about 20% of those in New York and California did. In most places, absent an option, many will be satisfied with either cheese or pepperoni in the first place. And Coke makes a stellar pairing. What more is there to say? That’s what I’m saying.
If you’ve even eaten Domino’s, you know it is barely palatable and only marginally qualified to be called pizza, but it is (or at least was) cheap and perfect for busy and otherwise starving college students. The point is they didn’t wait until they had 31 toppings to get started. The business took off, and they added some new menu items along the way. Don’t get me started on Dunkin’ Donuts.
The moral of this story is agility is the key. Although it has its problems, I am partial to Gartner’s bimodal IT model—at least over solely Waterfall or Agile and especially Wagile. Create a programme that allows projects to be delivered by Waterfall (or RAD, which is a favourite of mine) or Agile. Just don’t mix the two. That’s a recipe for disaster and an anti-pattern in waiting.
What are your thoughts?