Life Before Iteration 1

It was a bright and sunny day, and suddenly an agile software development project began.

Scott Ambler started his classic 2008 Dr. Dobbs article "Iteration Minus One" this way.  And of course he went on to drive home the point that projects don't just emerge fully staffed like Aphrodite from the waves. Somebody has to do the logistics.

Botticelli's Venus, from http://www.paleothea.com/Gallery/VenusSea.html

But how much planning and setup are you allowed to do on a project before they revoke your agile badge and change the secret handshake?  Although the Agile Manifesto celebrated its tenth anniversary this summer at the Agile 2011 "Return to Snowbird" conference, people seem as disagreeable as ever about what the runway should look like for an agile project, and how long it should be.

Just before that conference, Vikas Hazrati's InfoQ article urged readers to put their teams straight to work: "every iteration needs to produce working software."  He cited George Dinwiddie, Alistair Cockburn, and Ken Schwaber, concluding "there seems to be a general consensus that iteration zero could be best avoided, if possible."  Hazrati conceded that "chartering" could still occur, but not "building a detailed backlog and creating the infrastructure."

Are you kidding me? If we're working with software teams that currently think nothing of spending a whole quarter producing nothing but requirements, do we seriously have to be all macho about "showing the business side some working software" after an hour or even a week?

In most real-life corporate teams I have seen, "jump in and scrum" creates a situation where software is prolific and predictability is a four-letter word.  (Who's counting letters?  Pencil pusher!)  Sure, the old estimates were off, but the "just scrum" people are now telling the stakeholders that they are wrong to even ask for specific estimates around their return on investment.  Questions like "what will I get by the end of the summer?" are waved away with "gotcha--we're agile now."  Throw in concepts like the "overflow scrum," (where you do testing of the stuff you wrote over the last quarter or two to make it actually work), and IT has just used agile vocabulary to really screw over the businesses that fund them.  No--this vileness isn't "pure agile," but it certainly seems to happen a lot.

In non-theoretical situations I recommend would-be newbie corporate agilists to take deep breaths, take their fingers off the keyboard, and do three things before starting Iteration 1, the sum of which will more than pay for itself in project accountability, transparency, predictability, quality, and actual value to someone in particular:

1. Build a lean business case, comprised of a hypothesis that the business will gain more than it loses by investing in a software project with a particular direction.  The business case should include the specific measures the funding authority will use to test that the investment was worthwhile along the way.
2. A chartering, quick-start, discovery, or inception process, in which all relevant project stakeholders from business and technology (including "operations" people) meet together in person for a short amount of time (2 weeks should be more than enough for most projects--ThoughtWorks has even seen this work for a project lasting a year) to agree on the big picture from both a business and technical perspective.
3. An "iteration 0," "sprint 0," or "tech setup time," during which business-side people (product owner/business analyst/tester/UAT tester) begin working out details of the stories for iteration 1 (talking across the table as needed to their development and testing buddies), and technical-side people (devs and automated test experts) set up work stations, build, test, UAT, and production environments, along with a functioning continuous integration and deployment environment that does nothing more than build "hello, world!"

The Lean Business Case
Far too few businesses actually think through their project portfolio in terms of what the likely actual ROI will be for each project (increased revenue, decreased cost, increased customer satisfaction, faster speed to market, quality, or achievement of other corporate non financial goals).  Even if you did nothing else whatsoever to become more agile, really great things would happen at your company if someone wrote down ahead of time what the claimed ROI was for each project, and then compared it to what actually happened when the project was delivered.  And the "lean" business case would go further--calculate a minimum product to test in the market, actually measure how it does, and evolve from there, always measuring as you go.  But take baby steps.  Try for just ONE testable hypothesis for the whole project and see how you like it.  Success is contageous.

Quickstart
I've long outed myself as a fan of in-person kickoffs that go longer than the typical executive pep talk you may be used to.  I've now discovered that as usual, my "discovery" was covered in a book even before the Agile Manifesto--please read Kent Beck and Martin Fowler on "Planning Extreme Programming" for advice which is as true now as it was in 2000.  There are things you need to do even before you grudgingly start your "Iteration 0" concept, whatever that might be.  Get the whole team together, business and technical stakeholders alike.  Establish the relationships that will carry into phone and email conversations for months to come.  Let everyone understand what's going on.  And to give your business more predictability and control than they ever dreamed possible, go ahead and put together a "span plan" that shows what users will do with your software, divided into logical coding segments of no longer than an estimated 3-5 days apiece.

During this time, the group should put together a small charter document, a backlog of high level epics/features which comprise the current project vision, a high level set of scenarios for use of the software, a high level architecture, and a detailed story backlog for the first release where all stories have been sized at about 3-5 days, estimated in nebulous units of time.

Despite now-conventional-wisdom about "just scrum," please lay out a sensible and fairly complete initial "master story list" or "product backlog." up to the first release.  Allow some additional room in the plan for stakeholders to change their mind (say, 20%), figure out what the expected number of iterations will be and lay out which stories you'll do when.  The plan will change, but now everyone is looking at the backlog with a fixed cost and fixed time release in mind, and everyone understands that scope is the only thing you can play with.

Iteration 0
Once your release plan is done, plan for some time to prepare before you start to measure your velocity in Iteration 1.  You need some requirements to be well understood so developers can hit the ground running with those first stories on the first day of real coding.  You may very well do technical investigation work at this time ("spikes"), as well as setting up environments and detailing out initial stories and acceptance criteria.

Again, don't plan to do this for a whole quarter--if you're doing a 2-week iteration, start the project with a 2-week iteration 0 to get ready.  Don't belabor, don't buy all of your production hardware before it goes on clearance, and certainly don't lay out "the whole data layer" in Iteration 0 

NOW you're ready to jump in and scrum!  Go for it.