Scrubbing Sprint Zero

First published on Scrum.org, 19 April 2018 (syndicated).

There is no such thing as Sprint 0" - Scrum Developer Open Assessment, Scrum.org

I remember going on a PRINCE2 course a few years ago, and trying to determine how this celebrated stage-gated framework might be applied to an agile mode of delivery. I was employed in the UK public sector at the time, and I had come to know how instrumental "PRINCE2 compliance" can be to the striking of a defensive organizational posture. When all eventually fails you must be able to show that you followed appropriate procedure. And so it was that I eagerly sought out equivalences between work packages and increments, and between management-by-exception and the supposed empowering of teams. None of this changed anything those teams would do on the ground. I came up with all sorts of anachronistic mappings like this - irrelevant to value delivery, yet of indispensable value during a government audit. Compliance is a muddied conceit at the best of times and it can provide an enterprising knave with considerable sport.

What I learned from these high-jinks was how mutable "value" can be, and how easily a system ostensibly based on value can be gamed. Where real value is not being delivered incrementally, some proxy offering will typically be resorted to instead. For example, the generation of project management documents will surrogate for deferred value in most organizations, more or less by default. So insidious is this swindle that these documents are shamelessly referred to as "products", for all the world as if a "Highlight Report" or "End Stage Report" generates customer delight and evinces value to consumers. In truth such artifacts are nothing more than promissory notes for actual value to be remitted later...and very often by others who are subordinate to those making the promises. Framing these devices as "management products" arguably says more about certain parties who abstract themselves away from the hard grit of engineering, but who nevertheless wish to characterize themselves as being productive. Genuine value can only be attested to by the delivery, however marginally incremental, of actual working product. That's the key to empirical process control and the realization of an agile enterprise.

Of course, this gaming of "value" is only rarely acknowledged as being duplicitous or contrary to an agile way-of-working. Those who are involved in the game, whether they be managers or developers, are so used to a lack of of empirical control that its absence can hardly be missed when an agile initiative is attempted. When reminded of the manifesto principle that "working software is the primary measure of progress", it may seem fair to them to dissemble, on the grounds that current circumstances are special and that other measures of progress are not ruled out. "We don't have teams yet and Project Initiation Documentation provides value to the Project Board", they may say. The idea of what is meant by "value" can remain as distant from empiricism as it has always been, irrespective of any lip service paid to agility or any mappings conjured up for that purpose. Nowhere is this more evident than in the relationship between industry and the "Sprint Zero" antipattern.

The idea behind "Sprint Zero" is that, where initialization demands time and effort before any value can be delivered, it would be reasonable to account for this in terms of a Sprint of some kind. Remember that the Scrum Guide does not offer a prescription for essential set-up work. A Sprint appears to be a whirling grindstone where there is no initial momentum to be overcome. The economy of the Scrum Framework can look like an exercise in cartoon physics to those who are new to it. They find themselves up against real-world constraints in a real-world situation, and look in vain for specific guidance or at least some sort of clue. How do we get things started in an enterprise environment? To them a Sprint, however inappropriately, may appear to be the only means through which initialization can be accommodated at all. There has to be something like a Sprint Zero, they reckon. There's nothing else going.

This problem is an old one, and it was debated by two of the Agile Manifesto signatories back in 2008. In September of that year Alistair Cockburn remarked:

I have a sneaking feeling that someone was pressed about his use of Scrum when he did something that had no obvious business value at the start, and he invented "Oh, that was Sprint Zero!"to get the peasants with the pickaxes away from his doorstep.

... and then others thought that was a great answer and started saying it, too. ... and then it became part of the culture.

Ken Schwaber offered the following observation in reply:

Exactly ... sprint 0 has become a phrase misused to describe the planning that occurs prior to the first sprint ... and since planning creates artifacts that often change, it should be minimized prior to the first sprint, and then occur every sprint at the sprint review/sprint planning meeting (just in time planning)

Any work that must be done before a Sprint is not therefore a Sprint, and it ought to be minimized as far as possible. Indeed, Professional Scrum training currently remonstrates against any use of the term "Sprint Zero". For example the Scrum.org Professional Scrum Developer Open Assessment includes the following item in its question pool:

What happens during Sprint 0?

A) Requirements gathering, version control setup, and continuous integration setup.

B) Base system architecture and design.

C) Overall planning, base system architecture, base design, version control and continuous integration setup.

D) Establish base system architecture and design, install version control and continuous integration setup.

E) There is no such thing as Sprint 0.

I'll leave it to you to sweat over which answer is held to be correct.

Now, the bald claim that a zero-indexed Sprint cannot even exist may seem rather harsh. After all a Scrum Team may describe or number a Sprint in any way it cares to...as long as value is delivered by means of which empirical process control will be established. That's the critical problem with "Sprint Zero" though. A sham Sprint, where no releasable value is provided at all and only setup work is undertaken, is endemic along with that particular term which is used to describe it. Perhaps the best way to deal with the "Sprint Zero" antipattern is indeed head-on, and to dismiss the very artifice out-of-hand.

Is it truly an antipattern though? It's important to distinguish an antipattern from something which we may just not happen to agree with. There should be more bad consequences deriving from an antipattern than any good ones, and a solution to the problem ought to exist. The weakening of empirical process control, and the delayed delivery of value, might reasonably be identified as negative outcomes of a so-called "Sprint Zero" when all we get out of it is a fake agile wrapper for set-up work. There is also a danger in norming the idea of a Sprint which does not yield a product increment. Mike Cohn has objected to Sprint Zero on these grounds. "One of the biggest problems with having a sprint zero is that it establishes a precedent that there are certain sprints or sprint types that have unique rules", he says. "Teams doing a sprint zero, for example, will dispense with the idea of having something potentially shippable at the end of that sprint." Where set-up work must be done it would be better, he feels, to simply have a "project before the project".

Mike thinks it's important to understand "why having something potentially shippable is a central tenet of Scrum". He opines that this tenet should be applied in an "honest" way. Perhaps it's this sentiment which really gets to the heart of the matter. A Sprint which does not yield an increment of empirical value cannot really be a "Sprint". Even if nothing else about it were held to be objectionable, the subversion of the term for non-shippable work is inherently dishonest.

Any Sprint which does not deliver an increment of value, no matter how small, ought then to be dismissed as a canard. The ability to exercise empirical process control will simply not be there. Yet a "Sprint Zero" will often be appealed to on the grounds of pragmatism and the lack of a clear alternative. "What about all of that initial set-up work for an agile project?", we are reminded. Indeed, the concern of what to do about pre-delivery initialization does not go away just because the term "Sprint" ought not to be commandeered for it. What about those many things which must be done before any "real" value can be evidenced? Essential precursory activities can include the drafting of a Product Backlog, the determination of architectural foundations, the resourcing of infrastructure, and the recruitment of those agile team members who would deliver value in the first place. There can be many enablers to agile practice which must be brought into play. What then is the solution for dealing with them?

Part of the answer, of course, lies in minimizing start-up work as far as possible. The longer the empirical delivery of value is put in delay, the greater the leap-of-faith we will need to take when making any investment. We can call a set-up stage whatever we like, but not a Sprint. It is the minimum enabler to start Sprinting properly. If it is envisioned that multiple teams must work on a product, think about commencing real development with just one of those teams in place. Concentrate on ensuring that good agile hygienes are practised by just one team first, and only then think about scaling an initiative up. Consider the possibility of starting the first Sprint with just enough work articulated in a Product Backlog to frame a Sprint Goal which empirically validates the proposition, and then evolving the rest of the backlog on a just-in-time basis. Accept - from the very beginning - that architecture really ought to be emergent, and that frequent refactoring is not wasteful but a core development discipline.

Above all, start thinking about each deliverable in terms of an experiment and a learning opportunity. That is, after all, the true nature of a Minimum Viable Product. An MVP isn't something which necessarily represents an offering with a revenue stream. It's a tool for validating any assumptions you might make, and for minimizing stakeholders' leap-of-faith about the opportunity they've been invited to buy into. Don't therefore be afraid to plan substantial initialization work into the earliest Sprints. It could still represent the greatest part of the undertaking. The key thing to remember is that each increment must provide some functionality, no matter how trivial it may be. A skilled Scrum Team will select that functionality so as to validate the foundations which are actually being laid. This could be a transactional user story or "tracer bullet" which demonstrates that essential architectural layers are in fact working.

The toxicity of a "Sprint Zero" doesn't lie in the fact that set-up work is being undertaken. Rather, it's the lack of validation and empirical control. That's the problem. Paradoxically, that's also what makes the scrubbing of Sprint Zero so hard in many organizations. The concern for empiricism just isn't there, and agility degenerates into a game of mapping and illusion. Yet for those organizations which actually do put agile change to the forefront, the need to fake a Sprint soon fades away.

"So maybe Sprint Zero is an idea whose time has already come and gone." - Allan Kelly