Determining the Length of each Iteration

We have defined an iteration as a rather complete mini-project, going through all major disciplines and resulting in most cases in an executable, yet incomplete, system: a release. Although the cycle [edit, compile, test, debug] sounds like an iteration, this is not what we mean here. The daily or weekly builds incrementally integrating and testing more and more elements of the system may also seem to be an iteration, but that is only a portion of an iteration, as we use the term here.

An iteration starts with planning and requirements, and ends with a release, internal or external.

How quickly you can iterate depends mostly on the size of the development organization.

For example:

• Five people can do some planning on a Monday morning, have lunch together every day to monitor progress, reallocate tasks, start doing a build on Thursday, and complete the iteration by Friday evening.
• But this will be very hard to achieve with 20 people. It will take more time to distribute the work, synchronize between subgroups, integrate, and so on. An iteration may take rather three or four weeks.
• With 40 people, it already takes a week for the "nervous influx to go from the brain to the extremities". You have intermediate levels of management, the common understanding of the objective will require more formal documentation, more ceremony. Three month is a more likely reasonable iteration length.

Other factors come into play: the degree of familiarity of the organization with the iterative approach, including having a stable and mature organization, the level of automation the team is using to manage code (for example, distributed CM), distribute information (for example, internal web), automate testing, and so on.

Be aware also that there is some fixed overhead in an iteration, in planning, synchronizing, analyzing the results, and so on.

So, on one hand, convinced by the tremendous benefits of the iterative approach, you might be tempted to iterate furiously, the human limits of your organization are going to slow your fervor.

Some empirical data:

• Iterations of more than 6 months probably need to have intermediate milestones built in to keep the project on track. Consider reducing the scope of the iteration to reduce its length and ensure a clear focus.
• Iterations of more than 12 months create their own risk, as the iteration spans the annual funding cycle. A project which has not produced anything visible in the past 12 months is at risk of losing its funding.
• Iterations of less than 1 month need to be scoped carefully. Typically, short iterations are more suitable for the Construction phase, where the degree of new functionality to be included and the degree of novelty are low. Short iterations may do little or no formal analysis or design, and may simply be incrementally improving well-understood functionality.
• Iterations need not all be the same length: their length will vary according to their objectives. Typically, elaboration iterations will be longer than construction iterations. Within a phase, iterations are generally the same length (it makes planning easier).

Once you have an idea of the number of iterations in your coarse-grained plan, you need to define the contents of each iteration. It is even a good idea to find a name or title to qualify the product you have at the end of each iteration, to help people get a better focus.

Example Iterations for a Private Telephone Switch

• Iteration 1: local call.
• Iteration 2: add external calls and subscriber management.
• Iteration 3: add voice mail and conference calls.

Determining the Number of Iterations

A very simple project may have only one iteration per phase:

• One iteration in the inception phase, producing perhaps a proof-of-concept prototype, or user-interface mock-up, or no iteration at all, in the case for example of an evolution cycle.
• One iteration in the elaboration phase to produce an architectural prototype.
• One iteration in the construction phase to build the product (up to a "beta" release).
• One iteration in transition to finish the product (full product release).

For a more substantial project, in its initial development cycle the norm would be:

• One iteration in the inception phase (possibly producing a prototype).
• Two iterations in the elaboration phase; one for an architectural prototype, and one for the architectural baseline.
• Two iterations in the construction phase to expose a partial system, and mature it.
• One iteration in the transition phase to go from initial operational capability to full product release.

For a large project, with lots of unknowns, new technologies, and the like, there may be a case for:

• an additional iteration in the inception phase, to allow for more prototyping.
• an additional iteration in the elaboration phase, to allow different technologies to be explored.
• an additional iteration in the construction phase because of the sheer size of the product.
• an additional iteration in the transition phase to allow for operational feedback.

So over a development cycle, we have:

• Low: 3 iterations [0,1,1,1]
• Typical: 6 [1, 2, 2, 1]
• High: 9 [1, 3, 3, 2]
• Very High: 10 [2, 3, 3, 2]

So, in general, plan to have three to ten iterations. Observe though that the upper and lower bounds connote unusual circumstances, so most developments will use six to eight iterations.

Many variations are possible depending on risks, size, complexity:

• If the product is intended for some totally new domain, you may need to add some iterations in the inception phase to consolidate the concepts, show various mock-ups to a cross-section of customers or users, or build a solid response to a request for proposal.
• If a new architecture must be developed, or there is a large amount of use-case modeling, or there are very challenging risks, you should plan to have two or three iterations in the elaboration phase.
• If the product is large and complex, and developed over a long period, you should plan to have three or more iterations in the construction phase.
• You should plan to have several iterations in the transition phase if, because you must minimize the time to market, you must deliver the product with a reduced set of functionality, or if you feel you may need a lot of small adaptations to the end-user base after a period of use.

Aligning the Traditional Waterfall Review Sequence with the Iterative Approach

The default review sequence for a waterfall life-cycle project has a single major review at the completion of the important work products, for example:

• System Requirements Review (SRR), at the completion of the system specification;
• Software Specification Review (SSR), at the completion of the software requirements specification;
• Preliminary Design Review (PDR), at the completion of the architectural design sections of the software design description;
• Critical Design Review (CDR), at the completion of the detailed design sections of the software design description.

In the Rational Unified Process (RUP), parts of the equivalent work products are reviewed as they are completed in each iteration, but the major milestones (and therefore reviews) are aligned with the completion of the phases, inception, elaboration, construction and transition. A Project Manager wanting to adopt the RUP may have to find a way to reconcile this apparent conflict, because of contractual obligations. Ideally, the Project Manager should convince the customer that the phase and iteration based approach in fact gives greater true visibility into project progress, and reduces risk, so that there is no need for an SRR, an SSR, and so forth. However, this is not always possible, and the Project Manager has to schedule these reviews at appropriate points. It is possible, in the RUP, to locate the points at which these important work products (actually, their equivalents in the RUP) are essentially complete, although this does not always neatly align with phases or iterations.

This is done here by assuming that the relative effort that will be spent on requirements, design, and the like will be approximately the same in the RUP as in the (ideal) waterfall life cycle - but that the effort will be distributed differently. The result is the following:

• the SRR (concerned mainly with the Vision) can be scheduled at the end of the inception phase;
• the SSR (concerned mainly with the Software Requirements Specification) at about 1/3 of the way through the elaboration phase;
• the PDR (concerned mainly with the Software Architecture Document) at the end of the elaboration phase;
• the CDR (concerned mainly with the Design Model) at about 1/3 of the way through the construction phase.

For efficiency, the Project Manager, in consultation with the customer, should attempt to combine these reviews with the prescribed RUP reviews. This is clearly possible for the SRR and the PDR, they can be combined with Lifecycle Objectives Milestone Review and the Lifecycle Architecture Milestone Review, respectively.

Project Organization

Just as the software process is influenced by the project's characteristics, so is the project organization. The default structure presented here (see the figure below), has to be adapted to reflect the effects of factors such as the ones listed:

• The Business Context
• The Size of the Software Development Effort
• The Degree of Novelty
• Type of Application
• The Current Development Process
• Organizational Factors
• Technical and Managerial Complexity

These are key distinguishing factors when analyzing how the organization as a whole should adopt a new development process, here we will examine their effect on the choice of project structure. The figure below presents a default project organization, showing how responsibilities are assigned to the team structure.

Figure showing Default Project Organization. Note that there is no significance in terms of seniority or authority in the ordering of the roles.

This figure is a starting point for considering how project-level roles and responsibilities should be mapped to a structure of teams. The figure also serves to emphasize that roles (shown in the yellow boxes) are not individuals, but "hats" an individual (or a team) can wear in the project. It is for this reason that some roles (the Project Manager, for example) appear more than once. This indicates that, at some time, the behavior of the Project Manager, as defined in the RUP, may appear in more than one team. For example, in a large project, the task of preparing a status report based on a Work Breakdown Structure may be delegated to an individual in the Administration Team. However, this is a responsibility that the RUP assigns to the role called Project Manager.

In a small project, it is likely that an individual nominated as Project Manager will perform all the tasks of the role called Project Manager, in which case the Administration Team coalesces with the Software Management Team. The selection of team structure will be influenced by the nature and size of the project but should be tempered by some, largely common-sense, rules:

• small teams are usually more productive; however, in a large project this has to be balanced against the amount of cross-team interaction
• deep hierarchies are to be avoided
• the span of control of any manager or team lead should be limited to seven plus or minus two
• the software development team structure should be driven by the software architecture; a good architecture, with high cohesion and low coupling between subsystems, will allow teams to work more effectively in parallel
• testing, other than unit test, should ideally be performed by a team separate from the development team. Note, however, that this may not make economic sense in a very small project
• the structure must allow all teams and individuals to be given clearly defined authorities and responsibilities. This is particularly important if the hierarchy exceeds three levels. The managers and team leads in the middle of such structures need to understand what is required of them in balancing technical and managerial tasks.
• the structure must support the capabilities, experience and motivations of the staff: for example, if a single team is supposed to perform analysis, design and implementation, without any intermediate hand-off, it will need all the necessary competencies. Skilled analysts are not necessarily good implementers;
• team structures should not be rigid: individuals will migrate between teams over the project's lifetime, and the responsibilities of teams will change as the emphasis of the project shifts from phase to phase.

The rationale for the default organization is discussed at length in [ROY98]. In particular, the assignment of responsibilities for deployment to the software assessment team recognizes that, of all the teams in a development project, the software assessment team has greatest exposure to the software as the user will see it.

During the life of a project, the organization will evolve to support the work breakdown structure captured in the project plan. This is shown in the figure below, which is taken from [ROY98].

This evolution emphasizes a different set of tasks in each phase:

• the Inception team: an organization focused on planning, with enough support from the other teams to ensure that the plans represent a consensus of all perspectives;
• the Elaboration team: an architecture-focused organization in which the driving forces of the project reside in the software architecture team and are supported by the software development and software assessment teams as necessary to achieve a stable architecture baseline;
• the Construction team: a balanced organization in which most of the task resides in the software development and software assessment teams;
• the Transition team: a customer-focused organization in which usage feedback drives the deployment tasks.

Migration between teams during this evolution will ensure that knowledge and capability is retained in the project. For example, when elaboration is complete, some architecture team members could be dispersed into the development teams, perhaps to act as team leads, or carry the architectural 'vision' into development. Later still, towards the end of the construction phase, the focus shifts to the assessment team, and there is a movement of staff from the development team into the assessment team. It is also important at that stage, to avoid the loss of architectural integrity in the heat of construction, that the influence of the architecture team is not allowed to wane as the 'center of gravity' of the project moves. Moving some architecture team members to the assessment team is one way to do this.