Bootstrapping Agile Development

If you’ve ever sat down in the first meeting with a product owner at the beginning of a new-from-the-ground-up Scrum-managed project and said “Ok, let’s create the stories!” you’ve probably seen it go one of two ways:

  1. The product owner has no idea how to explain any part of his vision into anything remotely resembling a decent story and starts free-styling ideas that may require mind-reading technology from the year 2068.
       -OR-
  1.  The product owner starts down a list of incredibly detailed features she has in a spreadsheet and 5 hours later neither of you have any idea how any of it fits together, but you are both bitter that you missed happy hour.

If you’ve seen the rare-bird third option and the product owner hands you a stack of well thought out story cards that form a coherent, straight forward product, and the development team can easily start discussing and estimating them, congratulations! You are lucky, but the product owner probably got hired away before you started the project.

And those are the challenges in dealing with the stories. When you try to figure out a project’s user experience, deal with technical challenges, and other nasty real world problems, you’ll often find yourself thinking “Man, I wish we had just thought through that ahead of time.”

So Scrum is great for managing development but is silent on how to get the ball rolling. In fact, since Scrum is a reaction to Big Upfront Design, it purposefully (I think) skirts to the issue completely so that it can remain conceptually pure.

But those of us building new absolutely new things run into this problem all the time. If you are building anything mildly interesting and you just “do Scrum”, you’ll have a mess of a first few sprints as your development team flounders around trying to find a product’s essence (soul?) and end up wasting a lot of time.

So our solution to this is what we call Sprint Zero. We define it as “just enough up-front thinking so that we can efficiently start a Scrum development process.” We know there’s lots of talk about what to do before development, and usually the term “water-Scrum-fall” comes up. Besides being a painful to type, much less say, in practice this sort of bastardized thinking leads you down a dark path that combines the worst aspects of Waterfall with the worst aspects of agile practices. For example, this approach usually winds up locking the development team down to can’t-miss-or-our-project-is-hosed sprints and ignores the actual benefits of Scrum such as embracing feedback and enabling constant course correction. Maybe some people can both use this term with a straight face and create an effective practice out of it, but more often than not, we are helping clients clean up from the mess when it goes wrong.

And yes, this “sprint 0” thing is a term that’s been debated before. Mostly people seem to talk about it in terms of activities like setting up build environments and developer workstations. Sure that’s stuff that needs to be done, but to us the most important thing about Scrum is its strength in mitigating risk. If setting up a workstation is risky for you, you need to either choose different technology or choose a different development team.

So what do we do during our Sprint Zero thing that’s different? First thing we do when we start a new project is that we have to understand why we are even bothering to build this thing. Sometimes it’s as simple as getting a simple vision statement from the product owner that guides the whole project; other times it’s a series of brainstorming and other exercises designed to explore the value to be found in a particular market segment.

Once we’ve got that “why”, it’s on to the “what”. This is the real heart of the matter for most projects, and we split the work into three basic paths that can progress more or less in parallel (as long as the different people on the team are communicating and collaborating). These are:

  1. What’s the risk? Every project has some sort of unknown to it, and that unknown is by definition the risky part, and we always want to eliminate risk early and often. This could be integration with some 3rd party system, a complex algorithm, or obscene scaling requirements. Regardless, we usually use some quick prototypes to test and assess those risks so that we can reasonably account for them in our story estimation and backlog grooming.
  2. What’s the overall experience? This is where we do some basic research to find the direction for the UX of the product. Depending on the complexity of the project, it could range from some simple mockups and wireframes to full-on persona creation and pixel-precise renderings.
  3. What’s it really need to do? This is generating some definition of the project that is one-step more specific than the product vision (the “why”) and one-step less concrete than user stories. Call these work products “epics”, “use cases”, or even “high level requirements” if you must, but the point is to start exploring and putting some stakes in the ground about what the product really does and doesn’t do.

The main thing necessary to keep those reasonable activities to spiraling out of control and degenerating into Design Documents and Requirements Specifications is to set a time-box on them. For us, a single sprint-sized length of 2 to 3 weeks is perfect. Much more than that and you quickly start getting diminishing returns on your work. When we do need to need a little more “thinking time”, it’s usually for a specific reason such as we are replacing an existing system that needs to be understood well. In those cases, we work in “mini sprints” each with a set of goals to keep the amount of up front effort in check.

We’ve found that just that tiny bit of, yes, up-front work pays back big time since it keeps developers from building stories that ultimately don’t make sense or having a large development team bog down trying to figure out how a disjointed set of stories are supposed to fit together. It works for us, even if it’s not by-the-book Scrum.