I do continuous deliver, why should I Sprint?

Topic(s)
Audience

Everyone

Many folks believe that a Sprint is an arbitrary length of time in which you create and release software. They look at their continuous delivery pipeline and say to themselves; “Why would I limit myself to shipping only once every two weeks?”

UPDATE: Scrum.org just posted my Scrum Tapas – Scrum and Continuous Delivery which is posted inline below.

To that I say: “Where in the Scrum Guide does it say that you can’t release every day?”

You will not find it, I know as I have looked. I work with many teams that release software on a continuous delivery model of everything from a few hours, to a few days, and often on-demand. Can you say that they are not doing Scrum? Of course not.

So why would you want a Sprint at all?

  • A Sprint enshrines your empirical process by providing a maximum delivery cadence
  • It increases communication and alignment
  • It Adds some predictability to the unpredictable nature of software by evening the batch sizes.
  • A Sprint is a container for planning!

As far as the Scrum Guide is concerned you must deliver working software at least every 30 days, but there is nothing to stop you doing it more frequently than that. Indeed continuous delivery and Scrum go together quite well in my experience.

A Sprint enshrines inspect and adapt by containing your other feedback loops:

  • Sprint Planning – Inspect the Backlog and Adapt the plan for the next Sprint
  • Daily Scrum – Inspect progress and adapt the plan for the next 24hours.
  • Sprint Review – Inspect the Increment and adapt the Backlog
  • Sprint Retrospective – Inspect the Sprint and adapt the process.

Without a Sprint when would you bring all this together? The Sprint makes the effort required to pull your work together and create a Done increment of software mandatory. It is absolutely crucial to understand that if you don’t at least have working software that meets your definition of done by the end of the Sprint then you are not doing Scrum.

If you are an awesome disciplined team then by all means do something that looks a little more like Kanban, but if you don’t have the discipline to follow the rules of Scrum, how would you expect Kanban to work.

Communication & Alignment

An additional benefit of Sprinting is that it gives a cadence that your management, and other dependant teams, can follow easily. If you are coordinating work, then having a common frame of reference, Sprint 231, will aid in communication.

Creates Predictability

Software is inherently unpredictable. The standard deviation between the amount of work required for seemingly similar tasks is so big that it is very difficult to gain predictability. A Sprint creates an artificial batch of a fixed size (or at least less varied) with a time boxed Sprint so that you can create that cadence of predictability.

Conclusion

A Sprint is a container for planning rather than releasing and while Scrum requires that you have a working increment of software at least every Sprint, there is nothing to stop you doing it more often. Indeed the recommendation from Scrum.org is that you not only ship your software at least every 30 days, you should endeavour to do so more often.

Scrum.org recently changed its mantra from “Improve the profession of software development” to “Improve the profession of software delivery” to start to enshrine the idea that delivery, to your customers, is no longer optional to get significant actionable feedback that you can reflect on.

In short, while the Scrum Guide does not explicitly state it, it is no longer optional to ship your software to production at least every 30 days if you want to stay competitive and build the software that your users deserve.

Create a conversation around this article

Share on Facebook
Share on Twitter
Share on Linkdin

Read more

Martin Hinshelwood
For a long time now I have been searching for that perfect domain that epitomised the vision, the why, of what I am trying to achieve with my customers and the industry at large. Now I have found it in http://nkdagility.com
Martin Hinshelwood
At the MVP Summit I was appalled by the number of people who asked questions about new features for supporting hierarchical tasks! I shared a disgusted look with Peter Provost and we had a quick (and I mean really quick) conversation that resulted in this post. it really comes down …
Martin Hinshelwood
In my journey of delivering an immersive Product Development Mentor Program over the last eight weeks, a compelling narrative unfolded that beautifully illustrates the essence and true strength of Scrum. This story, rooted in the practical application of Scrum through Minecraft, unveils the depth of adaptability and resilience that Scrum …
Martin Hinshelwood
The Boards in Azure DevOps are a powerful tool that your teams can leverage to enable transparent visualization of the current state of value delivery.  However, the inclusion of Blocked columns can stealthily erode the very foundations of efficiency these boards are meant to uphold. By obfuscating the state of …