Let's start off with some definitions:

  • Iterative development — a software development concept in which software is developed incrementally in iterations
  • Continuous integration — a software development concept in which the development team integrates their work frequently

The concepts of iterative development and continuous integration have been around for quite some time and many organizations have incorporated some aspects of both ideas into their development processes. Having worked in several organizations that have implemented iterative development processes and established automated test and build platforms to support continuous integration on software projects, I found that the most important benefit gained from these concepts is the feedback the development team receives from the automated test and build results and the users and testers verifying the software after each iterative build of the software. Most organizations typically choose iteration lengths between one week and one month, but why not take iterative development to another level by making iterations shorter and increasing the feedback frequency from testers?

I would like to call this more extreme form of iterative development with continuous integration "continuous iterative development." This is how I imagine continuous iterative development would work:

The smallest unit of work that would be sensible to iterate development over will be a single requirement or feature

Features / requirements will need to be broken-down into smaller portions so that each item can be completed within several hours

Features / requirements will need to be ranked from 1 to N (in terms of priority and risk) and the order of tackling those items will be in that order to prevent "planning overhead" (development team waiting to figure out what to work on next)

  • Instead of scheduling iterations, the ranking of the features/requirements will be continually adjusted based on new information over course of the project
  • Only the top N features/requirements will need to be ranked immediately
  • Less important items can be left in a feature backlog that can be ranked when time permits

After each feature that has been completed, a suite of automated tests is executed and an automated build of software is initiated

  • The state of the software must be in a functional state after each completed feature
  • If there are blocking bugs, the development team will address them before implementing new features

The Quality Assurance team will test the latest build of the software by using the most recent automated build of the software

  • The quality assurance team will rely on the release notes from each build to determine what bugs were fixed or new features were implemented since the last build they tested
  • Bugs discovered in testing are immediately reported and the development team is notified immediately

The automated build platform must support the automated deployment of the software to a fresh environment to reduce the deployment overhead. The automated deployment process should involve the following steps:

  • Restore an image of an operating system in a virtualized environment
  • Silent installations of software required by the latest build and the actual build itself
  • Automated smoke-test/integration test of the build after the installation

User acceptance testing can be scheduled anytime.  Less technical members of the team such as the project manager or business analyst will be able to locate a previously tested and stable automated build of the software and initiate the automated deployment of the software to an user acceptance testing environment using the automated build platform without disrupting current development or testing