Member-only story
The Third Agile Principle: “Release Often and Release Early”
My thoughts on the challenges faced in the execution of this principle
The next in this series of posts predicated on my assertion that Agile has failed (…to deliver on its promise).
I think that the simplicity of the Agile Manifesto has been a partial cause of its downfall. The twelve principles that are listed all seem to be intuitively a good idea and seem to be quite simple to implement. But all twelve of the principles require some individual/team /organizational changes that are far from straightforward.
That is not to say that the required efforts to ‘live the principles’ are not worth it — they most certainly are. The issue as I see it is that everyone has jumped into Agile ‘two footed’, and failed to take the time to really understand the changes they need to make.
In this series I’m looking at each principle one by one, commenting on why it’s hard, and then offering suggestions to move towards success!
In this post, I’ll look at the 3rd principle in the agile manifesto. Namely:
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
This agile principle can be summarised with the phrase “release often, release early”. A completed feature should be delivered to the client as soon as is practically possible, and not left to gather dust in a repository somewhere until the annual release date comes around!
These days, ‘release often, release early’ has become synonymous with CI/CD (Continuous Integration / Continuous Deployment). While not really required, CI/CD is (in many cases) the most practical approach to take — particularly with web-based software.
This has been touched upon already in the first principle, but this one calls it out directly. There is no reason to leave good ideas sitting in a GitHub repo for months.
