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