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

The progressive, adaptive, iterative approach is founded on the following principles:

• Proceed in small steps, continuing steadily by increments.
• The plans must adapt to the project’s changing circumstances.
• The characteristics that distinguish the product or service must be progressively elaborated.
• They should be broadly defined early in the project and made more explicit and detailed as a better understanding of the project emerges.
• Large projects must be broken up into smaller projects.
• Requirements errors can be 100 times more costly to fix after deployment than at requirements time.
• Initial estimates have a large margin of error—most waterfall projects cost two to three times what was initially predicted.
• The first one never works; always develop things at least twice.
• Initial designs will be flawed.
• Requirements must evolve alongside demonstrable versions of the product.
• Teams need to own and be accountable for their achievements and plans.
• You should believe the project results, not the project plan.
• Detailed planning should be limited to the next milestone.
• Projects should adopt an active and aggressive approach to addressing project risk.

Progressive, iterative processes were developed in response to the problems inherent in the waterfall approach. Instead of developing the whole system in one go, an increment is selected and developed, then another increment, and so on. The selection of the contents of the first increment is based on risk, addressing the highest-priority risks first. To address the selected risk(s), select a subset of the requirements to be implemented and tested. Develop the minimal set of functionality that enables objective verification (through a set of executable tests) that the risks have been successfully addressed. Then select the next highest risks to be addressed in the next iteration, and so on.
One of the great ironies of modern software development is that in the paper that led to the popularity of the waterfall approach to software development, Winston Royce argued that projects should always go through at least two development cycles because the first version never works. He was actually arguing that projects should take a more incremental approach, not that they should adopt a prescriptive waterfall development approach. Progressive, iterative approaches take this principle one step further by splitting the lifecycle up into many smaller increments, each explicitly addressing the project’s major risks.

Nowhere is the change in values of iterative development planning and measuring more important than in the management team. If the project is to iterate successfully, it must be managed iteratively.

The project manager must believe that an iterative approach is the best way to manage the project and must be prepared to set aside any inflexible, predictive, waterfall management practices that have been used before. This doesn’t mean that you should throw away all the good management practices and experiences you have built up over the years; good, disciplined project management is essential to the effective application of iterative development techniques. It is just that you must put aside some of the conventional wisdom about planning to give yourself the freedom to fully exploit the flexibility and power of the iterative approach.

The conventional approach to planning is prescriptive, based on the assumptions that the work which needs to be done can be predicted with great precision and that the unusual rarely occurs. This is true for many things—building a bridge over a highway or a standard family dwelling or a prefabricated commercial building, for example. These engineering efforts are technically predictable, and planning this kind of work is based on hundreds of years of experience. This experience has given rise to the generic project lifecycle in which the different types of project activities are aligned to the single phase that bears their name (i.e. Requirements, Analysis, Design, Code, Test and Deploy). Read More

Iterative projects often require fundamental changes to the way team members work on a project. On a traditional project, it is easy to avoid really working together as a team. Everyone tends to have their own specialty and deliverables, and it is easy for a person to work in isolation and only interact with other people by passing documents around.

Successful iteration is very different, and requires a very interactive, collaborative way of working, involving:

• Commitment - The whole team (including business representative participants) needs to be committed to making the project a success. This doesn’t have to mean working long hours or promising more than can be delivered; it means just doing whatever it takes to work as a team and meet the iteration’s objectives.
• Focus - The team needs to keep focused on the iteration’s short-term objectives and not get sidetracked by other issues or activities. This is particularly true of the management team members, who need to stick to the iteration’s set of objectives after they have been set and agreed to with the team. The time to change the project’s direction is between the iterations, not during them. Read More

One of the frequent questions we are asked is "how can I get the time to explore needs when the business says that it is already done - "it's in the business case", even when it is obviously not complete?  This is actually a pretty common occurrence - nobody wants to take time to understand needs because they think it has already been done. Read More

Most project management approaches address risk in a fairly superficial way: risk mitigation is viewed as an important activity, but one that is largely a distraction from the main effort of the project. Risks are identified at the start of the project, they are usually assiged to someone to address the risks, but these risk-mitigation activities are largely viewed as things that take away from the project work. In practice the risks are only identified once and then they are largely forgotten in the large amount of work to be done.

On a traditional project, change is viewed as a bad thing, and great efforts are undertaken to prevent it. Change disrupts the original plan, and it is the plan (and not value delivery) that is sacrosanct on a Traditional project.

Similarly, change must be embraced. Change results from new information, from feedback that something in the original plan will not result in the desired end result. Change is something that will occur as people get new information, but change is a good thing: it means convergence on the right solution. Read More

As technologists, we tend to collect very detailed information and present it in a very technical way.  We talk about things like process maturity levels, and productivity indexes. I have even seen some measurement data about Agile maturity models that attempt to show how agile we are.  The problem with this kind of approach is it doesn’t provide anything that the business and the customers can relate to. 

The business does not really care how agile we are, they want to see results.  They want to be able to set targets, see improvements, and understand the benefits and the quality of the results being generated by IT. Only then can they begin to put the value of Agility into context – the context of the value and improvement generated by the move to agility. Read More

Traditional software development projects are executed in a value-neutral setting in which:

• Every requirement is treated as equally important
• The delivery of technical components is seen as of equal importance to the delivery of usable systems
• "Earned value" systems track project cost and schedule, not stakeholder or business value
• A "separation of concerns" is practiced, in which the responsibility of the development team is confined to turning software requirements into verified code rather than delivering business value
• The actual desired outcomes of the project are ignored in favor of implementing the largest number of requirements possible

No wonder so many projects fail to deliver the desired business results! Unfortunately this includes many iterative software development projects where the developers iteratively implement the requirements rather than delivering business value. Any management system that rewards things that are easily measured (like implementing requirements) without a clear and direct tie to business value delivered is headed down the wrong path. Read More

Iterative development is simple in concept: it is simply breaking a large project down into a series of smaller projects that deliver value in smaller steps. The hard thing about adopting it is that it requires the project team members and stakeholders to adopt a new set of attitudes and behaviors about how they work together to achieve a common goal. This requires subtle but significant changes on the part of all participants, especially if they have been working on conventional projects for many years. In short, these changes include the following:

A new attitude is required regarding the way that projects deliver business value. The project team must start to focus on delivering immediate and realizable value back to the business.

A new attitude is required toward uncertainty and change: teams must recognize that change happens and there are always uncertainties, so in order to be successful they must purposefully work to manage change and reduce uncertainties. Read More

To ensure that the project is making progress, each iteration is forced to produce something tangible: a “release.” This release can be:

• A prototype that is used to demonstrate some specific capability
• An “internal” release that is used to elicit feedback and that serves as the basis for further development and testing
• An “external” release that is shipped to customers in some form

The following is our definition of release:

Release: A stable and executable version of a system.

The production of something executable during each and every iteration is so important to the iterative approach that some people even go as far as to assert that “The goal of an iteration is an iteration release: a stable, integrated and tested, partially complete system.” Read More