Thread by @SteveSmith_Tech

Thread!

If you've decoupled deployments from customer launches, well done 👍

*But* bear in mind #ContinuousDelivery is about increasing throughout to meet customer demand. So it's the frequency of customer launches you need to increase, not just deployments 1/n

Deploying more frequently to production reduces technology risk, overheads, inefficiencies, etc. It's a good thing.

However, it's customer launches that create opportunities for validated learning 2/n

#ContinuousDelivery was named after the first principle of the Agile Manifesto agilemanifesto.org/principles.html

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software"

It is a means to achieve customer satisfaction 3/n

If customer demand is X, your launch frequency is Y, and you increase your deployment frequency to X, you have not achieved #ContinuousDelivery.

Minimising deployment risk and creating more launch opportunities is important, but insufficient 4/n

In some cases, an increase in deployment frequency without any change in launch frequency might create a false sense of confidence

For example, on a rewrite of a legacy app where customer launch waits on feature parity 5/n

If legacy app A1 is launched monthly when daily is required, it might be rewritten as A2. Monolith to microservices, on-prem to cloud, etc.

If A2 deploys are daily but launch is delayed for weeks/months until A2 = A1 feature parity is achieved, that's *not* #ContinuousDelivery

There are other implications to this - such as Launch Throughput being a more useful, actionable measure than Deployment Throughput... which means leanpub.com/measuringconti… could be better. But let's not go there 7/n