Are Sprints Just a Way to Organise Releases?
I’m increasingly convinced that some teams cling to Sprints / Timeboxes because they facilitate release planning. A Sprint = a mini-Release = real simple. However, continuous delivery means these “Sprints” are not real Sprints.
I used to be a great fan of timeboxes / Sprints but abandoned them when Kanban came along. I now use Continuous Delivery by Default; Timeboxes by Exception.
Despite what I think, many teams stick with “Sprints” and despite the Scrum language I’ve noticed these teams increasingly do releases mid-Sprint. They are (rightly) starting continuous delivery – after all, continuous delivery is inevitable.
This is not Scrum. These teams don’t care whether tickets run into the next Sprint or not. They are breaking a cardinal rule of Scrum – to produce potentially releasable code at the end of every Sprint. They don’t need to because they are releasing when they need to mid-Sprint.
These are not “Sprints”. The teams I’m talking about are not actually doing Scrum style sprinting. The supposed “Sprints” are not timeboxes as they do not constrain the work to fit the effort available. These “Sprints” are just measures of time.
I suspect these teams are just using the “Sprint” as a bucket for release planning. Chunk the backlog into two week blocks so they can report up the line on which features are expected to land when.
Personally I think these teams should abandon the Scrum terminology and revert to weeks and/or months on their release plan. Rather than “What will we do in Sprint 37?” they can ask “What will we do in September?”
This mid-way between continuous delivery and sprint planning seems to be a common theme and even more so with teams handling multiple work streams. Using sprints to help bucket work to a single delivery date does facilitate communication as well as control re-prioritization disruptions. Batching work planning is more effective as long as the batches are small. Also a routine/rhythm generally helps align expectations and keeps exceptions at bay.
I do think when continuous delivery is observed during sprints, it should be accepted when it makes sense and the resources are behind it. At that point it is important to define the procedure to fast-track work. How much time is allowed for the fast-track per sprint? What is the real reason for deployments during the sprint? Are some of the dependent elements of implementation actually not in the scrum team?
Steven,
Could it be that sprints are useful for measuring our expectations and gathering feedback from our team, but truly code goes out in a Kanban style.
The organizations I have worked / work for need to be able to forecast what we can deliver and when. It is my job to deliver process that allows this. I like to decouple this process from my team by delivering units of work to them via the process. With continuous delivery, the code goes out when it is ready. Sprints are my feedback loop to help me fine tune.
I like your ideas and love that you are blogging your experience. Kudos!
Just my point Darren. Organisation do want to predict when features are delivered. Typically, in an Agile team, this would be shown in a release plan. So teams retain the sprints as a measure of time. I argue that, if this is the only reason a team retains sprints, they may as well talk about time directly, e.g. weeks and / or months. So report what is going to be delivered in February 2017 rather than in Sprint 236.
lol, I started writing this with cadence in mind and then looked at your comment in Plan Do Reflect Improve…
Ultimately, I guess it’s finding your team’s sweet spot and call it what you like 🙂
If it’s a month, call it a month…
———————————-
Before reading the other post:
My argument would be this is more about the results feedback loop for fine tuning. If you have quarterly releases, you are better able to measure performance in small sprints. (say two weeks) It provides feedback for fine tuning your team’s ability to perform and estimate.