I do continuous deliver, why should I Sprint?

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?”

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?

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:

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.

Who is naked Agility Limited — Martin Hinshelwood

Martin Hinshelwood is the Founder/CEO of naked Agility Limited and has been their Principal Consultant and Trainer on DevOps & Agility for four years. Martin is a Professional Scrum Trainer, Microsoft MVP: Visual Studio and Development Technologies, and has been Consulting, Coaching, and Training in DevOps & Agility with Visual Studio, Azure, Team Services, and Scrum since 2010 and has been delivering software since 2000.
Martin is available for private consulting and training worldwide and has many public classes across the globe.

Originally published at nkdagility.com on May 17, 2017.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Martin Hinshelwood

Martin Hinshelwood is a Professional Scrum Trainer and Microsoft MVP. He has been Consulting, Coaching, and Training in DevOps & Agility since 2010.