Potential Barriers to the Adoption of Iterative Practices

Understanding the potential barriers to change will help you make the right choices of timing, project, and approach. Some of the more important questions to ask include in the following:

  • How supportive is senior management of the change? The measurements and milestones
    they establish can easily derail an iterative approach, as is the case when they ask even seemingly
    innocent questions such as “When will the design be completed?” or “When will requirements be
    signed-off?”
  • What is the scope of your authority to make changes? How much of the development lifecycle
    are you responsible for? For example, the requirements might have already been specified in a
    format and to a level of detail that would make it more difficult to adopt an iterative approach.
  • What are the team’s feelings about the changes? How enthusiastic is the team about iterating?
    To achieve the transition to iterative development, you will need the support of the team,
    especially the other members of the leadership team.
  • What else does the team have to do? How many other projects and initiatives is the team involved
    in? If the team is not focused on and dedicated to the project, the transition to iterative
    practices will probably be slower and take more time and energy to complete.
  • What capability do you need to improve? It is important to understand the capability of the
    team and how well the current capability supports the proposed iterative approach. For example,
    is there any testing capability in the team? Testing will be needed from the first iteration, which is
    often a problem in companies organized around the phases of a waterfall approach.

The ideal characteristics of an iterative project, and an actual project’s characteristics should have:

  • a co-located team,
  • of less than 10 people,
  • who are highly-skilled,
  • and largely self-organizing
  • who operate with low ceremony,
  • and who are minimally dependent on outside teams,
  • with highly-engaged business representatives.

These perfect conditions, in fact, almost never exist, but understanding them will help you choose
projects that are better suited to an iterative approach.

When you start your first iterative project, factor the successful adoption of iterative techniques into
the critical success factors for the project and the career development objectives for the team members.
This is especially important if circumstances require an investment in training and mentoring
the team to enable the transformation to take place.

Conventional wisdom suggests that you should choose low-impact, non-critical projects to be the
focus of early change efforts to reduce the change effort’s risk and the potential for failure. The problem
with this is that although these projects are lower risk, their non-criticality usually means that
they are starved for resources and not considered “mainstream” enough to ever be taken seriously as
success stories. This dooms the overall change initiative. Low-priority projects are not visible enough
to engender the support needed to drive the change forward.

Instead you should:

  • Look for a small number of must-do projects that have organizational focus and strong support
  • Look for projects with a smaller set of stakeholders to keep communication simpler
  • Look for projects with high internal visibility—ones that would make good success stories
  • Choose projects that are shortto medium-term in length
  • Staff the projects with the best people available (respected leaders)
  • Organize projects to generate short-term wins—divide work into iterations
  • Keep the project size small in the first few iterations and then scale up
  • Focus on choosing the right projects and committing resources to them

Choosing critical projects sounds risky, but the reality is that only critical projects will get the attention
and resources necessary to succeed. The key is choosing projects critical enough to get resources
but that can start small and then scale up in a controlled way, not becoming too large before the
architecture and technical risks can be brought under control. Scaling up should be targeted for the
Construction phase but not before.