Key Roles for Successful Adoption of Iterative Development
This supporting material describes the roles that need to be involved, and their responsibilities, in a successful adoption of iterative development practice.
Main Description

Overview

Iterative development is a team sport. It is that simple. As with any team sport, one player will not "save the day" if the team members, the coach, and the owners do not accept this way of playing the game. The idea of iterative development can start within any of these groups, but then you have to encourage the commitment and participation of everyone else on the team, and this is a process of selling ideas and benefits, in a language that each group understands. Failure to do so will generate tension, frustration, delays, and, ultimately, everyone will lose the championship.

Your stakeholders need to accept this idea about a game plan (an iteration), and how winning each "game" will require different approaches. Stakeholder input is fundamental. Your coach, the project manager, has to be able to guide the team, bring valuable information, communicate with the stakeholders on behalf of the team, and facilitate the interface between each player in a different role.

After each game, as you plan for the next, everyone has to understand and communicate the key factors leading to a victory, defeat, or even a draw, and how these will affect the next game plan.

Involved roles

This topic lists a few common roles that are present in most projects, either as a full-time or a part-time assignment, and that are critical for successful adoption of an iterative development approach.

Stakeholder

Stakeholders need to understand and accept the fact that information will be rough at first, and not accurate. Any attempt at providing detailed specifications in the beginning will lead to false progress, consuming time and budget, and often generating frustration. Requirements, business rules, and technologies will be refined during all iterations, and stakeholder participation early and often is a critical success factor.

Project manager

From the stakeholder's perspective, the designated project manager owns the plan and must be able to work with the team to break the work into iterations, communicate the goals, and lead the team and stakeholders to follow the cycles, so that the project can succeed. As part of the goal-definition effort, metrics must be adopted to understand success, failure, and the reasons for either one.

Software architect

Evolving design and architecture support the adopted iterative model, providing the foundation at the right moment for the team. Architects help by understanding how much of the architecture is required for any given project type, and they also highlight the critical pieces of the architecture that must be tested before you can rely on it to build your software.

Quality manager

Quality managers assemble a team and infrastructure suitable to support iterative testing, which will usually start early in the project lifecycle and be cumulative. This means tests from early iterations tend to be reused all along the project, such as a smoke test suite. Different testing skills, tools, and techniques should be available to be employed according to the goals of any given iteration.

Configuration and build manager

The role of configuration and build manager must ensure that tools and mechanisms are in place to deliver builds as frequently required by the pace of iterations, which typically will demand that builds to be created earlier and more often than in a waterfall lifecycle.