Thanks for joining me for this continuation of the Agile Project Management (APM) Series. In Part III, we continue our journey into the five phases of APM. Having already covered the first three phases (envision phase, speculate phase, and explore phase), we will now take a look at the concluding phases and ascertain their significance to APM. The final two phases in APM are the adapt and close phases. The adapt phase, though placed as a later stage, is actually of great importance throughout the entire APM process. At every iteration point, the project manager has the opportunity to assess the progress of the project and to adjust technical and product requirements in time for the next iteration. The close phase, however, is rightly placed as the last phase. Many projects simply do not give enough importance to recommended activities when closing, such as showing acknowledgement and appreciation to those who have made the project a reality. It is these two phases and their intricacies that I will be sharing in this part of the series, beginning with a look at the advantages and practices of the adapt phase.

Adapt Phase

Considering that APM is of an exploratory nature, requiring speculation and hypothesis testing, it is only logical that a system is implemented allowing for project managers to respond effectively post-feedback. How a project adapts will depend on a good understanding of the information presented, an assessment of the projects progress, technical risks, and an ongoing competitive market analysis. Projects have a tendency to oscillate without making progress and so a visionary leader who uses continual feedback for adaptive purposes will benefit. Every project team needs to constantly evaluate and make appropriate adaptations in the following areas:

  • * Product functionality (primarily customer team’s perspective)
  • * Product quality (primarily from technical team’s perspective)
  • * Team performance
  • * Project status

Project Manager Institute 2000 informs us that the term “corrective action” is often used as the term for responding to deviations from an initial plan. The term implies that the project has either underperformed or made an error that needs to be rectified. However, since plans are no more than speculations in the first place, APM abandons the term “corrective action” in favor of “adaptive action,” reacting to structured exploratory plans rather than to dysfunctional events. This should address the key technical practices of simple design, continuous integration, ruthless testing, and refactoring to ensure that they are being effectively implemented.

Reacting to events is, generally speaking, more difficult than reacting to a plan, because the team has to answer three critical questions:

  1. Are customers getting value from the project?

    In an agile project, because of the changes brought about by iterations, teams must continually review the product’s value. As you may expect, this is no simple task, but the value consumers place on a product must be ascertained in one way or another. Ascertaining value is a lot more difficult than, say, measuring the cost of a project, which is a lot more objective. One method, for example, could be by using an implicit customer ranking or the projected returns the project could make as a whole. Regardless of the method chosen, the product manager needs to assess whether the value generated during iteration was worth the cost of development.

  2. Is the project progressing at a satisfactory level?

    Project members must be able to answer whether or not sufficient progress was made, given the circumstances surrounding previous iterative processes. Progress can be measured in a variety of ways, such as value analysis, with the value calculated from features completed. This method is a lot more common with larger projects, such as those mandated by government contracts. For smaller projects, a simple graph of features that have been completed by iterations will serve an equally effective purpose. Thus the answer to this question may appear to be straightforward, but it is much harder to answer when the project is strictly conforming to an initial plan. Conforming to a plan is only one component of satisfactory performance, so therefore the project manager and the team must decide what other components will determine satisfactory performance.

  3. Is the project team adapting effectively to changes imposed by management, customers and technology?

    Requirements are likely to evolve as a project develops, changes in staff are likely to take place, component delays may occur, and a multitude of other factors may lead to changes in a project. If project managers want teams that can respond and adapt effectively to unforeseen circumstances, then they will have to start appreciating those that are able to provide this difference, rewarding them when they do. 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.

Adapt Phase Practices

The adapt phase consists of a single practice, which can be broken down into further sub-practices. The sub-practices are based on product, project, team review, and adaptive action. There are two main reasons for conducting review and adaptive action sessions at the end of an iteration. The first is to reflect and learn, as it implies, and the second is to change the pace of exploration through iteration. During the reflection period, various types of reviews are regarded as useful practices. These include customer focus group (CFG) sessions that demonstrate ongoing versions of the final product to the customer team for periodic feedback and technical reviews in order to keep the cost of iteration low to enable the product to adapt to changing customer needs. Team performance evaluations and evaluations of participation and commitment can also be used alongside project status reports aimed at enhancing performance. Thus, adapting should be part of any good project manager’s approach, as it offers various practices with which to do this effectively and provides a responsive strategy for project managers. The diagrams below illustrate the use of team performance evaluations.

Fig. 1: Source (Agile Project Management: – Creating Innovative Products)

The diagram above illustrates a team self-assessment chart, on which the team evaluates itself on two dimensions, delivery performance and behavior, and on a three-point scale, above standard, at standard, and below standard. With regard to delivery performance, team members must genuinely assess the standard of their last iteration. In a well-functioning team, members tend to be honest and open about their performance. The evaluative team discussion, not the chart in itself, should be the most rewarding part of this exercise. The second aspect of the evaluation is team behavior, in which the team again assesses its own behavior. This evaluation involves answering questions such as “How well are we fulfilling our responsibilities?” and “How well is the organization fulfilling its responsibilities?” Team members then assess overall behavior and develop ideas for improvement. The “Xm” represents the milestones reached by the team members, and serves as a method of measuring progress.

Other adaptive practices include the use of a schedule status, which shows the projected end dates (in elapsed weeks) for a proposed project. During the iterative planning stage, the team estimates based on progress and feature changes the projected number of weeks for the entire project. The diagram below shows high, probable, and low schedule estimates. Notice that the range of these estimates is wider at the beginning of the project, illustrating greater uncertainty, and narrower at the end, illustrating greater certainty. A range that isn’t narrowing indicates that uncertainty and risk are not being reduced adequately and the project may be in danger.

Fig. 2: Source (Agile Project Management- Creating Innovative Products)

Close Phase

A project close is both a phase and a practice that is often hurried through at the end of a project. Since available resources are usually scarce, people are moved onto the next project quickly, often without taking time to close up the last project or receiving credit for its completion. This is not only bad for team morale, but it is also a dysfunctional way of organizing a project, as members are unaware of the progress that has been made. There are several activities that should be included in the closing of a project, such as a celebration first and foremost, which serves two primary purposes. It provides a sense of closure to the project and an appreciation for those that have worked hard on the project. Projects that seem to go on and on without any closures are terrible for team morale. Another important activity is to close up open items by finalizing documentation and preparing required end-of-project administrative and financial reports. A final activity is conducting a project retrospective, which has already been done on a more minor scale in the iterative process. The retrospective at the end is primarily for inter-team learning, for one project to pass along to others in the organization the positives and negatives to build upon.

In conclusion, people often confuse products and projects. Products are ongoing, while projects have a finite lifespan. Differentiating between projects and products, ending projects and getting recognition and closure, is an important but often overlooked aspect of good project management, agile or otherwise. The five phases and their practices are integral steps in the agile management process and the “adapt” and “close” phases are the responsive phases in a primarily exploratory process.

Having focused the entirety of this article on the conclusive phases and practices of agile project management, in the next article we will finally take a look at the more technical agile methods and software that are commonly used in project management. I hope you have enjoyed learning about the phases of APM and I look forward to revealing the more technical side of agile project management in the next part of the series.