AgilePM Process

From AgilePM wiki
Jump to: navigation, search


The AgilePM approach to development and delivery is both iterative and incremental, with the most important business needs typically being addressed early in the project while less important features are delivered later. The iterative nature of DSDM enables business representatives to see the solution as it evolves, receive deliverables during the project, to provide feedback on it and to request changes throughout the development of the solution.

AgilePM integrates project management and product development into a single process. For many organisations, the AgilePM approach is all that is needed, although some gain value from integrating AgilePM with other methods e.g. project management methods, such as PRINCE2 and PMI, or software engineering practices, from eXtremeProgramming (XP).

The AgilePM process

The AgilePM process model shows the AgilePM phases and how they relate to one another. This process model is then used by each project to derive their lifecycle.


The project process, as shown in the figure above, has four main phases:

  1. Feasibility,
  2. Foundations,
  3. Evolutionary Development
  4. Deployment.

These are preceded by the Pre-Project phase and followed by the Post-Project phase, giving six phases in total. All phases are formally defined later in this chapter in terms of their purpose and what needs to be in place before they can be successful.

Pre-Project Phase

The Pre-Project phase ensures that only the right projects are started, and that they are set up correctly, based on a clearly defined objective.

So what make it a good project to start for the organization? - Provide a possible good return on investment (this will be investigated later) - Aligned with the strategy of the company - Compares well with all other project ideas

Feasibility Phase

The Feasibility phase is to investigate the project idea from a technical and business point of view. Frist to establish whether the proposed project is likely to be feasible from a technical perspective and whether it appears cost-effective from a business perspective so it provides a good return on investment. The effort associated with Feasibility should be just enough to decide whether further investigation is justified, or whether the project should be stopped now, as it is unlikely to be viable. Stopping a project should not be seen a bad but should be seen as positive as you have:

  1. Saved the company from wasting an investing in a poor project
  2. Allowed another more important project to start sooner

Foundations Phase

The Foundations phase continue the investigation that was started in the Feasibility phase. It is intended to establish a better (but not fully detailed) understanding of the business reasons for the project, the potential solution that will be created by the project, and how development and delivery of the solution will be managed. The Foundations phase avoids low levels of detail so it should take no longer than a few weeks and this is also true for large and complex projects. The detail work associated with requirements, and how they should be met as part of the solution, is intentionally left until the Evolutionary Development phase of the project and even the focus is only on what will be development in the next phase.

Sometimes it may be necessary to revisit Foundations after a Deployment phase. The decision to revisit Foundations may be planned in from the start of the project; for example, on a project where the business environment is sufficiently dynamic that the Foundations are expected to encounter significant change during the life of the project. Alternatively, the decision to revisit Foundations may be taken after a Deployment has produced an unexpected outcome.

Tailoring AgilepM: For smaller, simpler projects, the Feasibility and Foundations phases can often be merged into a single phase.

The aim of Foundations is to get a better idea of the scope of work, how it will be carried out, by whom, when and where so a number of business and technical roles will be involved in the Foundations phase. The Foundations phase also determines the project lifecycle by agreeing how the AgilePM process will be applied to the specific needs of this project.

Evolutionary Development Phase

The purpose of the Evolutionary Development phase is to evolve the solution and build on the work that has already been done in the Foundations.

The Evolutionary Development phase requires the Solution Development Team(s) to apply practices such as Iterative Development, timeboxing, and MoSCoW prioritisation, together with Modelling and Facilitated Workshops, to converge over time on an accurate solution that meets the business need and is also built in the right way from a technical viewpoint.

Working within Timeboxes, the Solution Development Team create Solution Increments, iteratively exploring the low-level detail of the requirements and testing continuously as they move forward.

Deployment Phase

The objective of the Deployment phase is to bring a baseline of the Evolving Solution into operational use. The release that is deployed may be the final solution, or a subset of the final solution.

Some examples of what can be deployed are:

  • Business change - introducing a new way of working into a factory (deploying a business change as a single release)
  • The early deployment of a corporate intranet, providing a limited number of features, with more features to be provided later (deploying the first release of many)

A complex product - e.g. the launch of a new mobile phone, bringing together par ts of the solution from multiple projects run in different locations (deploying a new product as a singlerelease) The Deployment phase comprises three main activities: Assemble, Review and Deploy. In addition, after the last release, the project is formally closed.


Before a physical deployment, there are usually activities that take place to ensure that what is being delivered is coherent.This may also include bringing together any relevant supporting information. Assemble encompasses the work to “bring together” what is to be released.

On a small simple project, the work involved during Assemble may be minimal. On larger more complex projects or programmes where multiple projects are feeding into a single release, the amount of work to assemble a number of Solution Increments into a single release could be significant e.g. combining a new business process, a schedule of training, user guides and a new IT solution.


Once all the elements of a release have been assembled, in most circumstances there will be some form of “approval to deploy”.This will be based on a final review of the solutionbefore it goes into operational use - to ensure the proposed release meets the appropriate standards and is complete enough to be viable. In a simple environment, this can be very informal – a basic checklist - but in a more complex environment, it may be as formal as a go/no-go checkpoint workshop.

At this point, the team also carries out a retrospective for the Project Increment, focusing on ways of working and potential areas for improvement.

Information from both the retrospective and the formal review of the product help shape plans for future increments and can be used to facilitate learning across projects within a portfolio.


Once approval has been given, Deploy is the physical act of putting what has been assembled (the release) into operational use. It includes any technical work, such as transfer of thesolution into the live (production) environment, but also the enactment of any plans for business change.

Closing the project

After the final Deployment, the project is formally closed. At this point, the whole team hold a retrospective to review the overall project performance, both from the technical and/or process perspective and from the business perspective.

Deployment and complexity

A release may encompass one or more Solution Increments and can also span one or more projects.This means that the Deployment phase may be a simple or a complex activity. How deployment is done varies from organisation to organisation, and from project to project. For many organisations, decisions about how deployment is handled are imposed by the organisation itself, and are not negotiable by an individual project.

There are two common scenarios for deployment:

  • Deployment phase is under the control of the project; or
  • The project has control of Assemble and Review but not the final Deploy activity

Post-Project Phase

After the final Deployment for a project, the Post-Project phase checks how well the expected business benefits have been met. Although it may be possible to highlight immediate benefits, most benefits will accrue over a pre-defined period of live use of the solution.

The Post-Project phase produces one or more Benefits Assessments for these realised benefits in relation to the business case. Benefits may be assessed for individual releases (in which case the assessment of benefit should start before the Post-Project phase is reached), for the whole project or may be omitted completely, depending on the needs of the organisation.

The Lifecycle in Practice

Whilst there is a clear progression of phases from Pre-Project to Post-Project in the process diagram above, there are also arrows indicating a return path within the process, specifically the arrows from Deployment to Foundations and from Deployment to Evolutionary Development. The process shows the framework and the options available, and then each project derives their lifecycle from this process. The lifecycle for a project is determined by factors such as the number of intended Project Increments and other external influences, such as the stability of the business environment and endurance of Foundations decisions. The lifecycle for the project is defined and agreed as part of the Foundations phase.

Configuring AgilePM for Scalability and Formality

AgilePM recognises the real value of Agility in terms of project productivity and solution quality while acknowledging and accepting the necessary constraints that often exist when working in a corporate environment. Such constraints may include financial governance, architecture and/or infrastructure strategies, regulatory governance, vendor agreements and third party support considerations.

The AgilePM process can be configured and calibrated to cater for a range of projects: small projects with light governance, larger projects which need stronger governance. Typically this is achieved by configuring a lifecycle appropriate for a specific project and determining an appropriate level of formality with which the AgilePM products are defined, created and approved.

With regards to scaling, the project organisation can easily be refined to support multiple teams, with key roles acting as directors and coordinators across the teams. To support a more complex project structure, products such as the Solution Architecture Definition, Development Approach Definition, Management Approach Definition and the Delivery Plan and Timebox Review Records can be made more elaborate and more formal than would be appropriate for smaller projects.


AgilePM provides an iterative and incremental process, with a total of six lifecycle phases. Each phase has a specific purpose, together with a number of defined products intended to support the evolution of the solution and the smooth running of the project. The AgilePM approach is designed to work effectively with projects of varying size and complexity. Through the tailoring of its various products, AgilePM ensures control is demonstrated to a level of formality appropriate to the organisation, thereby running a project so that all the benefits of Agile are achieved without compromising effective project governance.