Mark Needham

Thoughts on Software Development

Parkinson’s Law and Iteration Zero

with 3 comments

I’ve been thinking a bit about Parkinson’s Law recently and its’ applicability in software development.

Parkinson’s law is defined as follows:

Parkinson’s Law is the adage first articulated by Cyril Northcote Parkinson as the first sentence of a humorous essay published in The Economist in 1955:

“Work expands so as to fill the time available for its completion”

My colleagues quite frequently reference this law with respect to stories taking the amount of time that reflects the story point estimate assigned to them.

I haven’t noticed this so much but I think we’re more susceptible to the law when what we’re working on doesn’t have a clear goal or doesn’t have a fast feedback loop.

One of the times where I think we run into this problem is in the agile ‘iteration zero’.

Iteration Zero is an iteration reserved at the start of a project for setting up project infrastructure, building a walking skeleton and other such tasks. It’s typically a week long.

While I think it’s useful to do some up front work like this what I’ve noticed having participated in several of these is that we probably don’t need a week for this type of work even though it will easily fill a week if it needs to.

Despite my belief that the work fills the time it’s interesting to notice that we still don’t get everything perfectly setup in iteration zero and probably wouldn’t even if it was 2 weeks long instead.

We need to actually start driving some user functionality end to end and getting it deployed across our environments so that we can get proper feedback on the work that we’ve done.

For example one of the tasks of an iteration zero might be to have all the developer work stations ready to go by the time we start.

It’s certainly possible to get the work stations to a stage where we think we’ve got everything setup correctly but it’s not until people are actually using them that we know for sure.

The idea of an iteration zero is still useful but we should try to keep it as short as possible and accept that we’re still going to be learning/spending time in the first few iterations on iteration zero type stuff and expect a ‘slower velocity’ accordingly.

Be Sociable, Share!

Written by Mark Needham

June 13th, 2011 at 11:02 pm

Posted in Agile

Tagged with

  • Re-using tools and configurations from previous projects would also help reduce iteration zero. This only works well where projects might use the same technology stack, but it is something to remember.

  • >>The idea of an iteration zero is still useful but we should try to keep it as short as possible and accept that we’re still going to be learning/spending time in the first few iterations on iteration zero type stuff and expect a ‘slower velocity’ accordingly.

    Have you tried to get rid of Sprint 0 and deliver some business value immediately? Maybe just commit to less but at least deliver “something” in Sprint 1…
    In my eyes Sprint 0 highlights:
    1. Not following lean practices
    2. Reduced skill set of team (which is OK, but acknowledge it 😉

    Even after your “Sprint 0” not everything in your infrastructure is ready yet, so you need to spend some time in Sprint X anyway…

  • @Peter yeh that’s where my thinking was going, iteration 0 seems like  big up front infrastructure setup to me which as you point out isn’t really very lean or agile! 

    Plus then you have the awkward explanation to the product owner of why exactly you spent one week doing stuff which has no visible benefit!