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

Comments

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




    Agile Software Development with Scrum

    ReplyDelete
  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?

    Thanks,

    Adrian

    ReplyDelete

Post a Comment

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

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. From http://www.yogawithjohn.com/tag/yoga-class/ 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 a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica