Why Are Teams So Slow to Adopt Simple Continuous Delivery?

Becoming a signatory on the MinimumCD movement

Releasing high quality features sooner is a mantra you will hear a lot working with me. Trunk-based development, features flags and hyper-frequent deployments are immediate minimum quality controls that I adopt with every team that I lead as I join them. Nowadays, I coach other teams how to accelerate their own adoption.

This is why I signed the Minimum CD manifesto. The mission is clear. Remove needless cruft in the teams processes by eliminating batching.

How to Address Your Team’s Objections

Batching occurs during any “waiting time” that occurs naturally by switching tasks or leaving your workstation — whether you committed your work or not. This is followed by unnecessary delays in code review, merging long-lived feature branches and needless manual QA or testing cycles.

I’ve listed some of the most common objections that reinforce these process smells needlessly. Starting with…

💩 “I need to stay on a branch so I don’t break stuff“

Developers who do not practice CD love this idea. Merging is scary, let’s avoid it. Sounds silly doesn’t it when what you want is to get valuable changes out to a user.

Branches give a false sense of security. The valuable work of every engineer happens when his or her changes are merged and deployed. This is the only way feedback is gathered and value is created for the end-users.

However, branching does not aid in making merging easier. In fact, it makes it much much harder the older it is as other developers also isolate themselves, then race to merge first to avoid the dreaded merge conflicts so they can deploy on time.

💩 “Our users are happy with one release every month“

Quoting from Work in Small Batches:

This comes from a misunderstanding of what CD is for. Yes, we can deliver features with continuous delivery. However, a primary purpose of CD is production support. When production has an incident or we have a new zero-day vulnerability, they do want changes that frequently to resolve those problems. Can we? By improving delivery frequency, we are continuously verifying that we can still deliver those fixes safely.

It’s not just about your features. One task. Done. Two tasks done. A well-functioning team optimises the process of build a product continuously and without synthetic interruption to deploy.

A new feature requires a component update? You can deploy the component update before you start implementing the feature to make sure you have no surprises when the feature is actually done.

💩 “Deploying our system is complicated and delicate“

This screams “the most senior person has a long list of procedures they follow by muscle memory and everything has to be orchestrated by hand or production breaks.”

I have news for you. That person’s long list can be written down. Their clicks, commands and key presses can be captured in scripts, tests and deployment automation. Nowadays, even if that includes verbal commands.

Once you have written it down, a computer can follow it.

---

And last but not least…

💩 “We don’t have tests and do QA manually“

I interview teams that do this often. I ask them how stressed they are about deploys and how much confidence they have in releasing changes. The answers are usually this:

• Person 1 😱

• Person 2 😱

• Person 3 😱

• Person 4 😎

• Person 5 😱

I know you’re wondering who Person 4 is. It’s the QA person who sees a synthetic testbed of regression tests and it’s always green.

Silly, of course it’s green! Most of the important features are not test-covered.

The reality is:

This kind of team gains confidence their changes will work in production only after they have deployed to production.

This kind of deployment process is high-risk, low-confidence by default. It follows logically that there is no additional risk in deploying automatically and starting to write tests. It merely exposes the risk that has been shadowed and gated by that QA person with a false sense of security.