Are sprints incompatible with Continuous Deployment?
It's been common for me whilst working on software projects to have work organised into sprints or cycles - a period, usually between 1 and 3 weeks, where the team is working on stories and tasks for that project.
In my experience, those changes are usually released at the end of that cycle. But it seems that's not always the case; see release sprints:
A specialised sprint whose purpose is to release deliverable results; it contains stories specific to release activities and finishing undone work. A release sprint usually contains no additional development.
If we worked in two-week cycles and released at the end of each one, it would be at least two weeks before a change could be deployed to production. But what if we wanted to follow continuous deployment and release more frequently? Maybe daily or hourly?
Instead of waiting for a release sprint, if we released multiple times within a single sprint, how would this fit into or affect the process?
Does the release cycle need to be tightly coupled to the sprint cycle or can they be separate and independent of each other?
I've worked on projects - including a current one - where I've done multiple releases in a sprint, so of course, it can be done from a technical perspective, but how do we get the best from both processes - whether they work together or separately?
This is something that I'm going to continue to experiment with, iterate on, and learn more about going forward.
- Oliver
