Of all the principles of the agile manifesto, this is the most outdated one.
Back in 2001 the authors of the manifesto defined “frequently” as two months to two weeks, with a preference to the shorter timescale.
And Working Software means just that – a product increment that is deployed in whatever production environment it is intended to work on.
A truly agile organization is capable of a software delivery frequency of minutes, hours or – at most – just a few days.
This, BTW, has nothing to do with iteration length. A team can work in a 2 week iteration and still release software dozens of times per day.
If you’re already practicing continuous delivery and are able to deploy new features to production multiple times a day, read no further.
If, however, you wish to increase the number of deployments per day or even per month, this post is definitely for you.
This post is the 4th in a series on Agile Manifesto tl;dr. Click here to go to the first post including an index to the others posts.
Why shorter releases?
Many organizations that operate on long releases (say 3 months or more) find themselves struggling to enjoy the benefits of their agile journey:
They want to have shorter releases to reduce the TTM – Time To Market.
By shortening the release cadence they often find that they deliver less content while keeping a large overhead each release.
Less content builds pressure, which, in turn, increases errors and people’s burnout, which, in turn, reduces content even more, which, in turn, builds more pressure etc.
What’s holding them back from enjoying the fruits of their efforts?
Typically it will involve some kind of disconnect between development and operations.
And it’s a vicious cycle:
OPS experts don’t trust Dev teams to keep a healthy production environment. So they block access to critical systems.
Dev teams don’t have access to the critical systems, so they release substandard code to OPS due to ignorance to the implications.
Mistakes prove OPS experts’ point, so they keep Dev teams away from production.
And on it goes.
It’s no one’s fault, and yet this is a great recipe for blame culture.
Dev + Ops === DevOps
In a nutshell, to enable continuous deployments the following groups of experts must be able to work directly with one another:
- Developers (aka programmers, testers, DBAs, FEDs, etc) and
- OPS people (aka infra, ITS, pipeline group, etc)
If you are struggling with the idea of dev and ops people working together without boundaries, I have tl;dr-ed for you the now seminal DevOps talk – “10+ Deploys per day”:
They – Dev + Ops – should be able to seamlessly do:
- Automated infrastructure – an orchestrated collection of tools to automate where you want to deploy to
- Single shared version control – so everyone knows what “trunk” means, and everyone means the same thing.
- One step build – so everyone builds the same way
- One step deploy – so as to remove all manual and error prone deploy activities
- Feature flags – so everyone can ship changes over trunk with minimal risk of side effects.
That means you can do private betas and dark launches to get confidence in the field with new features prior to enabling features to the wild.
This also means that you can quickly and risk-freely switch on and off any feature that misbehaves.
- Shared DevOps metrics – so everyone is aware of the impact on runtime of whatever is running at the moment
- Alert robots – so no one has to sift through logs to find or to understand known problems
Succeeding in achieving this list is made possible through encouraging an organizational culture that is based on:
- Respect – A culture that appreciates that everyone wants the success of the organization and that respects differences between people and does not stereotype.
- Trust – A culture that encourages transparency, visibility, honesty
- Healthy attitude towards failure: A culture that is forgiving failure while encouraging technical and operational excellence. This is made possible by learning, deliberate practice
- Responsibility – A culture that encourages responsibility and discourages blaming.
What to do next?
If you are currently struggling to figure out how to do a release cycle that is shorter than a work week, I have no silver bullet to offer.
It will be a long journey.
But it will be one that will quickly bear sweet fruit. Typically quicker than you imagine.
Here are some useful resources to take with you on your journey:
Where to begin?
Of course, none of this is mandatory or essential.
A long release cycle may not be what you need. So maybe it’s not worth the effort.
However, recent history teaches us that changing priorities quickly is becoming ever more critical for business success. Some of the most pressing requirements became irrelevant when COVID-19 surprised all of us. And new and unexpected ones became critical to the business.
Organizations with a robust deployment pipeline change priorities almost instantly. As recently done by scores of companies.
Also, nothing here is new: Toyota has developed SMED (Single Minute Exchange of Dye) between 1945 through to the 1990s, and reducing dye change time from 12 hours (or up to 3 days) down to 180 seconds.
Software organizations reduce build times from around 12 hours to a few minutes in a matter of months or weeks. Sometimes a few years. So your prospect of developing your own SMED is far greater than that of Toyota. And, in contrast to Toyota, most DevOps problems don’t need reinventing a new technology. It’s mostly a people problem, not a technology problem.
This is just to say that one must begin somewhere.
Address low hanging fruit and high impact steps first, and perpetually progress towards perfection.
And keep telling yourself: There is no Dev vs. Ops, and there is no Dev vs. DevOps vs. Ops. There is just DevOps, and the various disciplines must be able to work together as a team.
Image source: https://pixabay.com/vectors/stop-alloy-sign-road-sign-street-355294/ by kropekk_pl