Skip to main content

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
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.

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.


  1. Great thoughts you got there, believe I may possibly try just some of it throughout my daily life.

    Agile Software Development with Scrum

  2. Hi Elena,

    Great article. I loved this line:

    Questions like "what will I get by the end of the summer?" are waved away with "gotcha--we're agile now."

    I am currently looking for help in the 'Lean Business Case' area... do you have any links or blog posts on that?




Post a Comment

Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

How To Write A One-Page Proposal to an Executive

One day you may need to communicate with an executive. Pro tip 1:  executives do not have time for you to dim the lights and show them forty slides with charts composed of animated dancing leprechauns and flashing arrows that emerge from the void in a checkerboard pattern. Pro tip 2:   Guys, and gals with deep voices, executives also don't need you to use your "Radio Announcer Voice."

As a rule, what executives want is simple: one printed page. No matter what it is, it should be one page. And it should be printed, not emailed.  You should plan to hand it to the executive, and then you should be quiet when they read it and wait for their questions.  It's harder than it sounds.
 So how do you do it?  Here are the steps:
Write the deck that expresses your proposal in as many slides as it takes.  Use imaginative animation and blinking letters if you must.Remove your title slide.Insert a new slide at the front of the deck with "Appendix" written on it in big …