December 2016: How Would You Like Your Eggs?

Waters has covered the Agile software methodology consistently over the past two years, but one aspect that we haven’t delved into are the vagaries around the frequency of releases and how firms should go about determining the optimal length of their sprints. It’s a question that all software development entities need to consider carefully. Note that I did not refer to them as software firms or providers, given that almost every capital markets firm develops software in-house for their own end-users, even though their core business is anything but software provision. 

Release too early and too often and you end up chasing your tail in a never-ending cycle of impractically short sprints and software updates, a scenario likely to alienate even the most supportive end-users, given the sheer volume and disruption of constant change; or, instead, release too infrequently and you end up mimicking the Waterfall methodology that you most likely jettisoned somewhere along the road to software enlightenment. 

A way of illustrating this challenge is by way of eggs. If, for example, a consumer wants an egg a day on an ongoing basis, what’s the best way to ensure that that happens? Do you buy chickens, build a barn, and collect a single egg every morning and deliver it as required? Do you go to the barn weekly and collect a box of seven eggs and deliver that box on the same day each week or whenever it’s most convenient? Do you collect and deliver eggs fortnightly or monthly, and if so, is there a risk that those eggs might go bad before the time comes to consume them? Or do you ditch the barn idea altogether and instead go to a supermarket and procure your eggs that way?

The same principle applies to Agile. Do you release small pieces of functionality on a daily basis? Is that practical, is it necessary, and is that what the consumer wants? Would it be better to release fortnightly? How do you go about determining the right release frequency (cadence) for you as a provider, for your clients as consumers, and significantly also for the products or services you provide? Well, the short answer, like so many things in our industry, is that it depends. Your cadence can and should change according to your clients’ needs, and, to a (slightly) lesser extent, your ability to meet those needs as a provider. In fact, re-evaluating your cadence is crucial to ensuring that the service you provide delivers value to consumers when they want it, and not necessarily when it suits you, the kernel around which pretty much the entire Agile methodology is spun.