You are here

Iteration Zero (Before you start your engines)

There is some controversy about this.
One view is that it is a misused phrase used to describe the planning that occurs prior to the first sprint, another is that it is that work that is needed prior to initiating development work, still others claim that this pre-work part of the project charter.

For a team new to agile, and a lot that aren’t, you need some space between the project charter, all the budget work and goals and vision nonsense to do some work before the start of development and all hands on deck. This is what most people refer to as iteration 0.

It makes sure that when Iteration 1 is started the team can hit the ground running and deliver that visible business value
The type of work that would be addressed includes work along the lines of:

  1. Making sure that the initial backlog is as complete as you can make it at this stage. Make sure that every known feature has a place on the backlog and is estimated. Even a rough estimate is better than no estimate.
  2. Key architectural decisions should already have been made these should be supported by high-level business process and architectural diagrams. If not, make the decisions and publish them along with the diagrams. This is key to reducing initial churn and making sure that early planning meetings and initial sprints are as productive as you can make them.
  3. Get the initial backlog into a structure that makes sense to the product owner, Scrum master and if you have the luxury the business analyst.
  4. While this is happening things like sorting out initial team seating arrangements, the first pass at the scrum/kanban board can be addressed
  5. Agree and diarise meetings including the daily scrum, planning sessions, reviews and retrospectives.
  6. Agree and publish initial and following iteration lengths and dates.
  7. Decide on the tools you are going to use as well as how you are going to use them. Do you even need tools, or are index cards and sticky labels going to suffice
  8. It is also where a small amount of ”engineering work” that the development team needs to have in place before starting work is completed. Things like:
    • Creating and configuring the source code control system
    • While you are about it make sure that the engineering practices are usable documented (yes I used that word) and everyone knows where they are.
    • Make sure that there is an initial build script in place and working
    • Decide on the unit, system & integration test framework
    • Choosing, creating and configuring a baseline continuous integration process is n absolute must. If you don’t have one the get one (Team City & Hudson are both affordable and work well)

I talk about initial team seating arrangements. What I mean is not where the team will initially be sitting, but there the initial team will sit. In most cases, it is foolish to start off with the full compliment from the start. There will be some churn and non-productive time while everyone finds their feet. Wait until the dust settles and then beef up the team to full compliment. This should not take more than and iteration, and at the most two (2 to 4 weeks in my book).

More mature teams and organisations will already have a proportion of the pre-work in place or will be able of address any deficiencies during iteration 1. For new teams or organisations all of this is scary, new and not the norm. Take things slowly, take the time to get the right things in place to ensure that while there is change, it is managed change.
Make sure that there are no obvious impediments to the process and that you have done everything you can to make the initial introduction to Agile as smooth as you can