I have rarely scheduled an Iteration Zero for my private sector projects, but wouldn’t do a federal project without one.
There are the known unknowns of working in the federal space – the byzantine processes required to get approval for behind the scenes tools such as open-source code clean-up applications, for example – but there are also too many unknown unknowns that can trip up any project, so mitigate some of that risk with an Iteration Zero.
Iteration Zero basically refers to the preparatory activities that take place prior to the first iteration and is usually time-boxed to the standard iteration for that project.
The specific activities required in Iteration Zero will vary considerably but there are three basic issues that I like to address in order to establish a shared understanding with the customer:
- Do you know where you are going? And why?
The foundation to any project is shared agreement on the problem to be solved and the approach to be used. Your project backlog will provide the answer to this question.
So at the end of iteration Zero, there needs to be a feature level project backlog with enough user stories prepared for the first release. Also, ensure that you are all clear on the scope of the first release, which will be clarified in release planning.
- Do you know how you want to get there?
This is the technical counterpart to the backlog, so there needs to be a clearly developed and articulated technical vision. At minimum, you will need visualizations of high-level application architecture, data flow and how the components will interact along with identified technical risks and constraints.
This will also include establishing the necessary configuration management processes, such as procedures for and access to version control, change control and build management activities. I would strongly recommend making the case for implementing automatic builds in Iteration Zero, whenever possible. Implement just enough CM practices to provide the groundwork for Agile teams.
- Are you ready to start the full software development cycle in iteration 1?
This means having in place the necessary infrastructure, tools, and environments so that the development teams can have truly hit the ground running. Specifically,
- Ensure all necessary tools have been approved and are in place. Think downstream and anticipate 3-6 months ahead of development teams.
- Set up all necessary environments and access privileges (explicit notation of any differences from production environments)
- Understand release process including any contractual deliverables. For example, your contract might require design documents even for an Agile project, so work toward shared understanding of what a design document can or cannot be.
As a project manager I’ve previously worked with used to say, “Agile requires you to have your sh– together on day 1. You don’t get to BS around.” Or you will drain value from the first few iterations and will be playing catch-up afterwards.
In addition to these core processes, Iteration Zero helps build the culture of collaboration and conversation required for successful Agile projects. As a happy byproduct, it helps assuage the fears of those who worry about the presumed “lack of planning” in Agile. So, a win all around!
By the way, one interesting factoid I picked up is the source of the term Iteration Zero. Apparently it evolved from something called a ZFR – Zero Feature Release. Makes sense, though I just assumed it was logically constructed as the predecessor to Iteration 1.