Iteration Zero
Posted in Agile Practices, tags: adopting agile, iteration management, iteration zero, planningIn my last post I mentioned the Iteration Zero technique in passing. I’m going to tackle it head-on today.
Agile teams strive to deliver functionality that can be touched or even used by the customer at the end of the first iteration. Sometimes, however, it does make sense for the team to focus on building its foundation before delivering functionality. This may be the case for larger applications, for teams new to agile development, or for projects where the the features are still extremely fuzzy. These are perfect opportunities to execute an iteration zero.
An iteration zero does not deliver any functionality to the customer. Instead, the project team focuses on the simple processes that will be required for the adoption and use of most agile practices. From a programming point of view the features delivered in an iteration zero may include:
- Source control system installed and operational
- Initial build script written and checked into source control
- Initial promotion and deployment scripts written and checked into source control
- Automated test framework selected and implemented with an empty test suite
- Construction of a rudimentary continuous integration process
One good method of performing these activities is to rapper them around a “Log In” feature. (If the application does not have log-in functionality then a simple “Hello World” screen will do.) “Logging in” can then be the first piece of functionality to pass a test in the unit test framework. It can be the first thing to be automatically compiled, run through the continuous integration process, checked into source control, promoted to the testing environment, and automatically deployed.
From a management point of view, iteration zero outputs may include:
- Initial list of features identified, estimated, and prioritized
- Project planning mechanism (spreadsheet, simple database, index cards, or other planning tool) identified and agreed upon
- Identification of and agreement upon a team customer, essential stakeholders and business users
- Agreement on the initial approach to the iterative planning process (for example, the time of the planning meetings and the length of iterations)
The activities performed in an iteration zero are analogous to learning the letters and numbers of a foreign language. Before learning to read a foreign language we need to know how to pronounce the letters in that language. Similarly, before writing tests we need to have a unit test framework, and before prioritizing and planning features we need to have a simple system to track and organize those features. Finally, assigning this foundation-level activity to a single short iteration timeboxes the work, which guards against gold-plating, analysis paralysis, and a host of other project villains.
UPDATE: Want to read more thoughts on Iteration Zero. Check out An Iteration Zero for Project Recovery: Starting Again Without Starting Over
Entries (RSS)
[...] New Project Iteration Zero » Sep 01 [...]
Great Post. I am tremendously inspired by it.
That’s a good way of thinking about it. Handy to have a concise name for it also!
What do you call bug fix only iterations or house cleaning iterations where you just focus on reducing technical debt?
Most teams that I’ve worked with add tech debit and bugs into the feature catalog (or backlog) to be prioritized alongside everything else, so we almost never have iterations dedicated to these activities. I have heard arguments for dedicating an iteration to tech debt–or refactoring–but haven’t come across a name for it.