Twenty years ago, an agile rebellion started among a small pocket of besieged software developers. Today, the benefits of agile methodologies have improved stock trading, federal bureaucracies, celebrity chef-led humanitarian efforts. Yet Agile has started to lose favor. This has prompted us to get back to basics and start a series focusing on the Principles of Agile.
We covered the first and second principles recently, now let’s look at the third:
The Third Principle of the Agile Manifesto fully states:
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Feels familiar, no?
Focus on software utility? Check.
Focus on routine delivery? Check check!
There are strong similarities between the first and third principles, so why dedicate a whole other principle to something already covered?
Pure conjecture on my part, but I would guess it is because the goal here is to be more specific and practical. The first principle speaks aspirationally, and this one is starting to define some of the boundaries around those aspirations. We talked extensively about short intervals of delivery in the first post, but the third principle delves deeper into the regularity with which updates should come.
Good, or Good Enough?
So how can we define “working” software?
In my estimation, “working” is in the eye of beholder — so in other words the customers.
There’s no objective measurement, but we still have plenty of ways to parse it out.
First, if you need a mental model to work from, Clayton Christensen’s Jobs to Be Done framework is a great start. How are people doing this job prior to your software? How relatively painful (or soothing) is the switch to your current version?
The less painful, the easier the switching cost to your “working” software.
Second, if we want to get deeper there’s some generally accepted methods. We can look at validated acceptance criteria, sufficient (e.g. 80%) passing grades on test coverage, and a signoff of the product owner who has both validated and approved the work.
A Walking Bundle of Frequencies
The next part of the principle talks about the importance of frequently delivering software. The shorter the feedback loop between new features or refinements, the lower the risk and the lower the likelihood that large changes will be asked to be incorporated late in development at the last minute.
This re-representation of the classic meme from Henrik Kniberg, kind of explains. On the top line, the customer isn’t happy until the car is done. On the second line, the skateboard would be hard to take on the highway but could be used to travel short distances.
In the first line, the leap of faith is taken only in the final stage, whereas on the second that leap of faith is smaller in increment and taken at every step of the journey.
This also encourages the customers to provide feedback and become active participants in the continued development of the product.
Back in MY Day …
By modern standards, the delivery of working software in “weeks to [..] months” feels quaint.
Even just a decade ago, very few tech juggernauts seemed to be aggressively deploying multiple times a day. In 2021, one doesn’t need to work at Netflix or LinkedIn to be pushing intraday changes. Even small bootstrapped teams can practice this level of continuous integration and delivery.
Twenty years ago, pushing software updates was significantly harder due to the ubiquity of distributed and thick client architectures. These were required due to the immaturity of the internet as a viable distribution medium for software. At that time, updates were either painfully slow across the internet or in need of being deployed by admins across local networks, or even worse, read-only media drive by drive. We’ve come a long way!
Shorter ≠ Better
If we transported the seventeen software developers from 2001 who met in Snowbird, Utah back to create the Agile Manifesto to the modern day, would contemporary practices give them whiplash?
Back then, developers preferred measuring cycles in fortnights, now we measure them in minutes or hours. I have to imagine the development cycles of contemporary software must appear utopian. Shorter development cycles are wonderful, but there are tradeoffs.
As someone in a comic book movie once said, with great continuous deployment pipelines comes great responsibility.
Shorter cycles are not the goal — increased feedback is.
Shorter cycles might increase the likelihood of heeding the feedback, but we still have to listen to and internalize the requests before picking up our next card at the top of the TO DO column.
In the end, those signers of the Agile Manifesto would laud short cycles, as long as user feedback was taken into consideration for the next leap of faith.
If we are just pushing commits to production more quickly without considering what users now want, then we might as well revert to the monthly deploys our programmatic ancestors dreamed of twenty years ago.
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
