Sprint Zero, When You Can't Not Do It
As an Agile Coach with a past history as a developer, my goal is to get my clients building actual software quickly. Often, I would prefer not to do anything close to a Sprint Zero, because I've never seen a Sprint Zero that's about delivering working software. Just as often, I can't avoid it, because the clients I work with simply aren't set up to not do one.
I should probably define what I mean by Sprint Zero before diving into it.
When I talk about Sprint Zero, I am talking about performing all the tasks that are related to a team building software, but must be done prior to actually putting "hands on keyboards." This would include everything from building your product backlog to ensuring that you have a continuous integration server, from setting up a few team email distribution lists to installing all the software that developers will need on their development machines.
Why not to do one
As stated above, I'd prefer to simply get down to the task of writing working software. After all, that is clearly stated in the Agile Manifesto Principles -- "early and continuous delivery of valuable software" ... "deliver working software frequently" ... "working software is the primary measure of progress."
When Corporate IT Gets In The Way
But when working in many Fortune 100 environments, my experience tells me that environments are too locked-down for developers to deliver anything of value for a few sprints. I've seen environments where Java developers had to wait a week or more before being able to install Eclipse.
So you might as well call it a Sprint Zero. The goal of this period of time should be something along the lines of "Do Everything Necessary To Get To Go," meaning there should be nothing stopping you from delivering working software all the way to your closest-to-production environment once Sprint Zero finishes.
Sprint Zero Tasks
A sample Sprint Zero Backlog might contain some or all of the following:
- Install all software needed, both on your development workstations as well as on your deployment environments.
- Don't forget to track what these are, how you get them at your company, and if any have license costs or restrictions.
- Get access to the following tools:
- Story Tool (Jira, Mingle, Rally, etc.)
- Source Code Control (Git, SVN, etc.)
- Continuous Integration Tools (Jenkins, TeamCity, Sonar, etc.)
- As well as configuration and documentation on all of those tools.
- Create those aforementioned distribution lists
- Determine your tech stack, from UX frameworks to middle-tier to databases.
- Determine your tech strategy. Will you be creating a giant monolithic webapp or following a microservice architecture? Or maybe you're developing shrink-wrap software (is that even still a thing?) How much automation will you be doing? What about a test strategy (TDD? BDD? ATDD? OtherDD?)
- Gather environments and configure them.
- Can you do "Infrastructure as Code"?
- Create a basic "Hello World!" application that exercises your entire tech stack, commit it to source control, and run it all the way through your CI pipeline automatically.
- Create your Product Backlog.
- Set up your Team Room, if you're lucky enough to be colocated.
- Define team working agreements, such as:
- Definition of Ready / Done.
- Team Room.
- Meeting Behavior.
- How will your team be coding (Pairing? Mob? Ping-pong TDD? Solo?)
- How will your team handle bugs?
Sprint Zero is Finished!
OK, so your Sprint Zero is now complete. Hopefully you've been able to complete all of the tasks that you need above (and any others your environment requires) to start building software next Monday...Because once Sprint One hits, it's go time. So begins the process of delivering working software, which is what the game is all about, right?
I'd love to hear from you what other tasks you've had to accomplish in your Sprint Zero(s) that I might have overlooked. Please leave your thoughts in the comments below.