Risks for the Adoption of Iterative Development
This supporting material outlines some of the likely risks and consequences for adopting iterative development, both for the project and for the organization.
Main Description

The table later in this topic lists the risks when adopting iterative development, the probability for the risk to become an issue, the potential consequences to projects and organizations, and the potential strategies to mitigate those risks. Most of the risks apply primarily to organizations with a traditional software development culture (which are considered new to iterative development),  but some risks apply to organizations with a modern software development culture, as well.

Risk

Probability of this risk becoming an issue

Potential consequence to the project

Potential consequence to the organization

Mitigation strategy

Conflicting resource assignments; for example, resources assigned to several projects at the same time.

Highly likely for the initial adoption of the iterative development practice.

Rarely occurs in agile environments where team colocation, multi-disciplinary team members, and shorter schedules minimize this risk.

Iteration will not meet its objectives.

In traditional software development cultures, when critical resources have conflicting assignments, the project manager will tend to create detailed plans for the entire duration of the project in an effort to secure resources. 

This approach goes against the fundamental scheduling model of the iterative development practice, where only the coming iteration is planned in detail, while the remaining iterations are planned at a higher level of detail.

This approach will also create the wrong expectation with the leadership team with respect to the progression of projects managed using iterative methodology.



Devise a resource allocation strategy that reduces conflicting project assignments and leverages knowledge of specialized resources.

1. Use specialized resources as mentors, providing guidance to several teams, which can span several projects.

2. Develop a prioritization process that allows team members to receive clear direction on the tasks that have highest priority.

Projects acquire highly specialized resources on a full-time basis to carry out most complex tasks on projects.

Highly likely during the initial adoption of the iterative development practice.

Less likely when team members are generalizing specialists [AMB03] who can take on multiple roles.



Project bears increased labor costs because either highly skilled talent will carry out less complex work after they finish their primary work, or those resources will be under-allocated.

Increased risk of creating a bottleneck around the work outputs of the specialized resources.

Increased scrutiny of the executives' team.

This potential consequence applies to both traditional and agile cultures.

Highly specialized resources dedicated to a single project cause ineffective use of critical organizational capacity.

Unavailability of the specialized resources for other project work affects progress negatively, causing executives to interfere with prioritization and project assignments.

Mitigation plan defined above also applies to this risk.

Develop a training program to encourage and enable resources to learn complementary skills and competencies so that they can take multiple roles on the project.

Project manager has limited experience with iterative development practice.

Highly likely during the initial adoption of iterative practices.

Less likely to be a problem for agile teams that are typically more autonomous and require less direction.

Poor iteration planning.

Slower than required resolution of issues during and across iterations, affecting the desired project velocity.

During the initial adoption of the iterative development practice, executives will expect tangible results to justify the new direction. An inappropriately skilled or inexperienced project manager  will not generate the desired results and might jeopardize the commitments of the executive team to iterative development.

This risk is so high and its impact so far-reaching that an effective mitigation is required.

1. Hire an experienced project manager  (part- or full-time) with the required skills and experience.

2. Develop a coaching or mentoring program for project managers who are new to iterative development.

Team has limited experience with iterative development practice.

 

Highly likely, especially when iterative development practices are introduced.

Less likely among agile teams that tend to adopt iterative development more naturally.

Traditional style: The team becomes uncertain. Waiting or needing to be told what to do reduces team productivity.

Agile style:
The team might not collaborate optimally.

Perception is that iterative development takes more time rather than less time.

Perception is that iterative development is chaotic.

In either situation, provide a coach or mentor for teams that are new to iterative development.

Provide mechanisms that the teams can use to evaluate their adoption of iterative development practice, such as retrospective reviews.

Team wants to "extend" the iteration.

Highly likely in organizations that are used to delivering their executables at the end of a project.

Less likely in organizations where executable code is frequently delivered during the course of a project.

Iterations will not be carried out in a time-box framework, thus reducing the required velocity, generating longer overall schedules, and increasing the cost of the project.

Teams do not reap the benefit of seeing early, continual progress. Members begin to think that iterative development is not different than anything they have done in the past.

Ensure strong project management skills to re-enforce the construct and benefits of time-box iteration planning and execution.

Teams do not deliver executable code at the end of each iteration (except the very first iteration in large projects).

Highly likely in organizations that are used to delivering their executable code at the end of a project.

Less likely in organizations where frequent code delivery is the norm.

Less risk reduction achieved by the iteration.

Reduced ability to obtain fresh input from client so as to incorporate feedback from one iteration to the next.

Iterative development is perceived as not being different from what has been done in the past.

Include demonstrations of executable code to sponsors and clients into the plans for every iteration.

Broadcast, communicate, and celebrate the success of each demonstration.
For larger projects, begin the demonstrations with the second iteration.

Stakeholders not available to give feedback iteration by iteration.

Depends on organizational culture.

Problems with requirements or expectations will not be discovered until the end of the project, when they are more expensive to fix.

Iterative development is perceived as not being different from what has been done in the past.

Involve stakeholders early in planning cycle, secure key stakeholder commitments during project schedule review, and communicate the benefits of early feedback.

Create an internal feedback group to review the results from each iteration.

Iterative development is used as a stand-alone practice rather than in concert with risk-reduction practices.

Moderate.

Although projects will obtain the benefit of early feedback, showstopper issues might emerge far later in the project, when they are more costly to resolve.

Late-in-the-game showstopper issues increase the perception that iterative development is not different from what has been done in the past.

Discuss and demonstrate to the executive team the benefits and insist on the need to use iterative development practice in conjunction with risk-reduction practices.

Table 1 - Risks for the adoption of iterative development