Not(!) My Hero, Sprint Zero**

tl;dr

If you are about to have a Sprint Zero that intentionally does not deliver anything of value to the Product Owner, you are making a mistake.  Please reconsider.

the rest of the story

Like everything else we humans get our hands on, the concept of Sprint Zero is being abused lately and used as an outright retreat into practices we know don't lead to business value.  I am going to come right out and assert that at the heart of the matter is fear...at the team, leadership, and maybe even organizational level.  How we behave when pressed to deliver is a great litmus test for the character of our development culture.  Sometimes, as with these sprints designed specifically not to deliver anything of value, we don't pass that test.

Every one of us worth our salt knows the code we write will tell us if our project structure is any good.  The humans writing the code will tell us what they still need to learn.  The tests will tell us if our product is shippable.  We also know that no matter how much we plan, many of our assumptions and approaches will change as we learn.  The shortest duration to turning over all the rocks along our path and seeing all the truths about the software we are attempting to conjure is to try to write it and observe what happens.

So why then do we not just start every project by trying to deliver some part of the value?  In most cases, whether justified or not, because we are afraid to be wrong and especially with an audience.  We want to design a little more, learn a little more, delay a little more...and hopefully stack the deck in our favor so that there is something impressive for the demo at the end of Sprint...ONE.  This is a very human thing to do, but still wrong.  It signals to me that we have not yet overcome this silly fear around performance, or worse, that something about the environment makes it an unsafe place to be wrong and sometimes both I suspect.

We are humans.  It is OK to be imperfect in this creative process.  As a matter of fact, it is one of the ways we learn most effectively.  Dive headlong into the ambiguity and start trying to put the 1's and 0's where you think they belong.  You will know in short order whether or not you got it right and you will learn loads of useful things for the effort.  If you feel like you need more architecture, oversight, and process to keep your teams out of trouble...you have much bigger problems.  And they will not be solved with any amount of code...or architecture, oversight, and process.

Less chatter...more code!

**For the record the original title of this post was "!My Hero, Sprint Zero" but I was not sure the less technical types would pick up on the "!" as meaning "not"  :-)