We have 4081 guests and 9 members online

Video Spotlight

Home > Blogs > Featured Blogs > Plan and Deliver > Iteration Zero

Iteration Zero

Written by Peter Schuh   
Tuesday, 02 September 2008 18:20

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

Iteration Zero
Posted: 2008-09-03 02:20:30

Read Full Article

Comments (0)Add Comment


Write comment

You must be logged in to post a comment. Please register if you do not have an account yet.

busy
 

Agile Marketplace - Announcements and Special Offers

Webcast:  Moving Build and Code Quality Upstream
This interactive panel discussion moderated by Bob Aiello, Editor-in-Chief fo the CM Journal brings industry experts Anders Wallgren, CTO of Electric Cloud and Gwyn Fisher, CTO of Klocwork together for a candid discussion of the cost savings, productivity and quality benefits that can be achieved by stabilizing builds and code quality as early in the development cycle as possible.
Register Now!

Collabnet -TeamForge 5.3
CollabNet TeamForge 5.3 includes Dynamic Planning—providing flexibility to model release scope and timeline in a single view. Now, you can easily manipulate/adjust release data.
Download Your Free Trial

Requirements-based testing (RBT) can help to ensure comprehensive test coverage, reducing the risk of failure and improving software quality. This white paper details how application lifecycle management can be used to more effectively implement RBT processes, offering greater collaboration, traceability and control.can help you increase efficiency, reduce project risk, and improve overall software quality. Learn how MKS Integrity for application lifecycle management enables RBT, delivering full lifecycle traceability to help ensure that project requirements have complete test planning and execution coverage.
Download the Requirements-Based Testing whitepaper

PureCM –SCM for Agile Teams
PureCM helps you to manage development in short iterations: keeping track of changes, supporting automated builds and preserving frequent snapshots of your projects.
Get the free trial now