Progress

Phase Adapt

If plans are speculations or hypotheses about the future, then frequent and effective feedback is necessary to test those hypotheses. Agile projects are exploration projects, and as such, success depends upon reality-based feedback. Adaptation depends upon understanding a wide range of information, including an assessment of the project's progress, technical risks, the requirements evolution, and ongoing competitive market analysis. APM has the potential to save money through the early termination of projects, but only if the project team and executives are willing to face reality early. Iterative projects are also prone to oscillationgoing back and forth without making progress. Two things counteract this potential risk: a good vision and continual feedback. Every project team needs to constantly evaluate and make appropriate adaptations in the following four areas:

• Product functionality, primarily from the customer team's perspective
• Product quality, primarily from the technical team's perspective
• Team performance
• Project status

Adaptations can take many forms. A team that rushes to deliver features but creates defectshurrying rather than being quickneeds to adapt its behavior. A creeping design degeneration gives rise to additional "refactoring" activity in the next iteration. Cost overruns are highlighted by the project status review, and appropriate action is taken.

The common project management term for responding to deviations from plan is "corrective action," a phrase that implies that the project team has made an error or underperformed. The "conformance to plan" mentality runs deep in project managers' psyches. The Project Management Body of Knowledge defines corrective action as "anything done to bring expected future performance in line with the project plan" (Project Management Institute 2000). The term corrective action is based on the assumption that the plan is correct and the actual performance lacking. Since plans are speculations in the first place, APM abandons the term corrective action in favor of "adaptive action"reacting to events rather than to a predictive plan. Reacting to events is more difficult than reacting to a plan, because the team has to answer three critical questions:

• Are customers getting value from the project?
• Is the project progressing satisfactorily?
• Is the project team adapting effectively to changes imposed by management, customers, or technology?

"Are customers getting value from the project?" In an agile project, because of changes over the course of an iteration, teams need to continually review the product's value. The customers and product manager make frequent adjustments in the feature priorities based on their interpretation of feature value. Measuring value can be difficult, more difficult than measuring cost or schedule against plan, but without a constant attention to determining valueif only an implicit customer ranking rather than an explicit numerical calculationguiding an agile project will prove difficult. The product manager needs to assess whether the value generated during an iteration was worth the cost of development.

"Is the project progressing satisfactorily?" This question is also more difficult to answer than whether the project is conforming to plan. Conformance to plan is one aspect of satisfactory progression, but only one. Members of the project team must ask themselves the question, "Given the circumstances during the last iteration, did we make sufficient progress, and what additional information did we learn?" Progress can be measured in a variety of ways depending upon the project. For large projects, especially those involving government contracts, a form of earned value analysis (with value calculated from features completed) may be appropriate. For smaller projects, a simple graph of features completed by iteration should suffice.

"Is the project team adapting effectively to changes imposed by management, customers, or technology?" As requirements evolve , staff changes take place, component delays occur, and a multitude of other things impact a project, the team members need to assess how they are adapting to those changes. Also, if managers and executives want project teams that can be flexible and adapt to change, then they must give teams appropriate credit for that flexibility. When a team deviates from the original plan but effectively responds to a surprise product release from a competitor, that team should be evaluated on the situation and their response, not the outdated plan.

The Adapt phase contains a single practice, which includes several subpractices :

• Product, project, and team review and adaptive action

Some of the practices within this Adapt phase should be scheduled at the end of each iteration (e.g., product evaluations), while others, such as the team performance review, could be scheduled at a milestone. However, if the team is using two-week iterations and two-month milestones, the team review should probably occur every second iterationwaiting two months would be too long. Furthermore, part of the team review should include evaluating the time periods between these various reviews. In APM, nothing should happen by default; the team should always be evaluating the relevance and contribution of every practice.