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