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