The Math of Continuous Delivery

I was surprised when I found out that agile is getting to it’s 20 years anniversary. It got me thinking and here is what I realized:

1. I’m doing a version or another of agile since forever now
2. I’m getting old - Ha
3. In a hurry I can’t produce a great answer why I love Agile. I can enumerate it’s benefits but that’s about it.

People that know me, know that I’m a huge fan and supporter of continuous deployment and it’s relatives: agile, continuous integration and test automation. And as a confession, during my career, I took unnecessary risks just to figure out how to push the boundaries of continuous deployment and see what are it’s practical limits. I also applied it in personal life, in the way I organize my daily tasks and in the way I interact with other people ( you can imagine that it’s not always a good idea :) )

However after all this I learned quite a few things about agile and it’s extreme application, continuous deployment. If I’d have to summarize the most important takeaways, I’d leave two:

1. The frequency of deployments and the speed of which you can make changes to your product is in direct relation with the quality of your product. Higher the quality, more confidence in changing process, more often you will do changes.
2. It’s the best stress mitigation approach if you are in the business to delivering technology. It also sets you and your team up for the long race at a stable pace.

Let me detail each one of them.

Let’s take a simple example that can be applied in multiple aspects of a tech product. You want to change one word in your product - and you can imagine that situation happening in multiple place when it comes to a tech product: website, backend up in the cloud, a mobile app, firmware, package, a marketing campaign, a print out on your PCB or a label on the back of your product, etc. I’d say that in every single case faster the change, higher the quality of your team, technology, processes and ultimately the products is. People tend to resist and add extra time if they are unsure about the risks and/or implementations of the changes. Technology tends to buckle under pressure and high speeds (hence the stress test) - changing a word in a 1980s printed news paper was a way grater deal that it is now in the online news era. Processes, are typically added in place to mitigate problems with people and or technology - so more convoluted processes you have more problems you have. So ultimately all of these factors build up in a product or deliverable that has deep inside it’s guts a quality level - that in my opinion surfaces in it’s most crude way when you try to change something.

Have you been lately thru the process of releasing something after one or multiple years of work? I’ve been - the stress level is insane. It’s all this anticipation and ridiculous amount of expectations that builds up over time. Stakeholders can’t wait anymore; your team it’s in trenches delivering miracle after miracle. I can say that being in the mixture of all that has it’s rewards, but it’s crazy stressful. Sometimes there are legitimate reasons to have this approach but for an established product I can’t name a solid one.

The way to get out of this kind of approach in my experience has two steps: 

1. Have stakeholders that are competing for your time, do it in a coordinated way so they can all agree on the priorities. Always drive towards a forced stack rank list of priorities. There cannot be 2 P0, 2 P1 and 4 P2 - there is 1 P0, 1 P1, 1 P2, 1 P3 and so on. You got the idea. It doesn’t mean that you won’t do things in parallel - it just gives you and your team an idea of what is the most important thing to work on. It gives you focus and clarity of execution and eventually a more aligned stakeholders team.
2. Provide a constant pace for delivering. Shorter the release cycles more flexible the stakeholders will be. In reality, at the time of deciding what goes in a release, some of the requests from stakeholders won’t be clearly specified. Having a weekly or daily release cycle will put people at ease that if they missed the current release there will be one soon enough to address their request.

This is why I love agile - It makes things better.