Concept: Iterative Development Approach
Iterative development approach helps the team deliver software frequently, thus promoting stakeholder feedback. This concept page also introduces how iterations are planned and some myths around iterative development.
Main Description

Overview

The iterative development approach is the "heartbeat' or "pulse" of the development organization. The primary goal of this approach is to deliver to the project stakeholders the working functionality that they can use and provide feedback based on their experience. The other artifacts are secondary to working code, because they are less representative of progress than the working code is. However, artifacts such as requirements documents, architectural models, business cases, and so on are needed to gaining agreement on what goes into each iteration. The larger and more complex the project, the higher the number and the ceremony of artifacts might be necessary. 

An iteration is a time-boxed milestone that is used to measure a project progress based on working software. The product development team chooses practices to be followed and sets up the needed infrastructure in such a way that the team is able to deliver small subsets of functionality that are useful to the stakeholders' business purpose. This approach is new to a lot of development teams as many are used to a traditional waterfall development process, where progress is measured by sign-offs of deliverables (such as documents, plans, models, etc) other than working code. 

Before performing an iteration, there needs to be a well defined iteration plan. This plan should provide clear understanding of what needs to be accomplished during the iteration. Prior to the assessment at the end of the iteration, the functionality and other goals of the iteration have to be tested and validated. In addition, in each iteration the team has to make sure that work done during the current iteration has not broken functionality added in previous iterations.

In summary, the following are the key aspects of iterative development:

  • An Iteration has to end with working, production-quality software that can be tested.
  • Each iteration should deliver new functionality and not re-work of old functionality.
  • Each iteration has to have an iteration plan which will specify what goes into each iteration. 
  • Each iteration will have an iteration assessment that will highlight whether the objectives have been met or not. The feedback from the assessment will be rolled into future iterations.

How Iterations Are Planned

Sequencing iterations: The sequencing of iterations is guided by the project lifecycle the team follows. For example, on an architecture-centric process that is driven by risks, we tend to attack the higher architectural risks in the early iterations. Other processes might decide to focus on the value to the clients, so the teams might perform iterations where the highest value to the clients is provided on the early iterations. Some teams will balance risks and value at the same time.

Length of iterations: There are two primary approaches on how you plan the length of an iteration, as described below:

  • Uniform iterations: In this approach, each iteration has the same time interval. For example, you might want to have monthly iterations. Or in other cases it might be six weeks long. You can add and de-scope functionality to fit into the time frame. For teams new to iterative development, this is a good way to getting introduced to the habit of performing iterations. Another benefit is that your customers and other stakeholders expect something they can use at the end of each month (or whatever the length of the iterations is). Be aware that your users have an expectation of when some functionality will be delivered.
  • Non-uniform iterations: In this approach, you size the iterations length based on the functionality, bug fixes and enhancements you want to deliver. Some iterations might be three weeks long and others six weeks long. For this approach to be successful, you need to have a very good idea about your team's ability to work in an iterative environment. You will also need some estimation experts on the team. Typically you will want to have at least a couple of projects using uniform iterations before trying the non-uniform approach.

Some Myths

Iterative approach does not need planning: This is one of the biggest myths. Iterations are well planned events. They are actually much more rigorous than the traditional approaches. An iteration is guided by an iteration plan. An iteration plan tells the team which risks and enhancement requests are being addressed, and what functionality is expected at the end of the iteration. Once the iteration is completed, you compare the iteration results with the iteration plan. The results and lessons learned during an iteration help update the plan for the next or future iterations as needed.

The code delivered does not need to be of good quality because we can always fix it in the next iteration: This is also not true. The functionality delivered by iterations is meant to be incremental. In other words, you deliver additional functionality with each subsequent iteration. The code delivered has to be production quality so that the Quality Assurance organization and users can test. An iterative approach is not a playpen for developers.

You start day one of the project with the first iteration: As iterations are meant to deliver production quality code, you need to do some planning on what functionality goes into an iteration. In some processes where the project lifecycle is organized into phases, this planning is typically done during the first phase. This planning session should involve project manager, project team and stakeholders. At the later iterations, there need to be wrap-up activities like integration testing, training and turning over the software product to the operational teams. When a team wants to adopt the iterative approach on a project, the team needs to have a short initial phase that allows for planning out the iterations goals and a final phase that ties all the loose ends together. The iterative approach is not a sequence of iterations tied together with no room for initial planning or final close out of projects.