Deploy != Release

Chaitanya: We follow two-week iterations. What should we do with iterations, if we are deploying continuously?
Me: If we complete a feature within two days of starting an iteration, why should we wait for another week or 10 days for the poor users to start using it?
Chaitanya: Yes, that is true. That makes sense too. But the question is what are iterations for?
Me: I would recommend using iterations for retrospectives and planning. Use those for pausing, zooming out and thinking ahead. But that doesn’t mean that the users need to wait that long for the changes to reflect in the product.
Me (contd): This is also less risky because you get better feedback when you deploy in small chunks. And it helps you to analyse better when something goes wrong in production. You know what changes have gone when.
Chaitanya: Hmm. That makes sense. Something to think about.

The conversation occurred during my talk while I was referring to Decoupling deployment from releases. The decoupling helps to lower the risk of releases using:

All the above helps for faster feedback and learning.

Chaitanya is mentioning about decoupling iterations from releases. I was wondering how much Chaitanya and team missed the power of early and frequent feedback by delaying deployments.

We started with coupling the deployments with fixed length iterations. But after a while, we realised we don’t need to and started with Continuous Delivery. It gave us great results.

What made the shift possible? As a team, we focussed on continuous value delivery to the end users. The practices used for delivering software was not that important.

Nowadays we hear about Docker vs Kubernetes, React vs Angular, Serverless vs Containers, Micro-services vs Monolith. And many vigorously argue why one choice is better compared to another.

The question is how each of the above help in accelerating value delivery. The users don’t care. They stay as long as the value flow exists, not based on the cool technology choices.

Related posts

Decouple Deployment and Release

Continuous Deployment: No Sprints Required