In June of 2014, Agile PM² was released by DiGIT within the European Commission and then the basic model made available through the Open PM² Guide v1 in 2016.
The Agile PM² Extension was developed to help Functional and Matrix Organisations establish a management framework for the effective integration of Agile practices and teams into their PM² projects and overall organization.
Agile PM² offers a well-balanced model that enables teams to apply agile practices while ensuring alignment with PM² best practices and mindsets.
About Agile
In our current project environment, the complex and uncertain nature of many types of projects is increasingly recognised as something that is generally difficult to be managed. This is particularly true when our management efforts are based solely on traditional management methods.
For these types of projects, agile approaches have shown to yield impressive results. Agile addresses the management challenges of those projects by establishing project organisations and working methods that are highly adaptive and use short feedback loops to quickly respond to change and to improve its processes.
Agile is a collective term used to refer to project methods, in which problem formulation and solutions definition evolve through collaboration between self-organising, cross-functional teams.
Agile promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change.
Challenges in applying Agile
Although Agile is often presented as a panacea, organisations and teams usually face significant difficulties in applying it effectively. Agile needs to be implemented for the right reasons, in the right context, and by the right teams.
More specifically, and unlike practicing Agile in small organisations and start-ups, there are a significant challenges running Agile in most organisations. These are related to compliance with IT governance and audit requirements, enterprise architecture, and interoperability, which are significant constraints that cannot be ignored or circumvented.
The challenges usually grow with the size of the organisations in which they are applied and are more apparent in organisations with functional structures and traditional management culture.
In summary, the challenges in applying Agile in traditional organisations are related to:
- working in an Agile way while complying with organisational processes, structures and rules, including organisational wide governance, budgeting and contracting rules, architecture and interoperability constraints.
- using Agile in large or non-collocated teams
- using Agile when only some teams or team members are onboard the Agile approach but others are not.
Agile practices should be enterprise-aware, taking into consideration organisational governance requirements, enterprise architecture, and interoperability.
Therefore, there is a need to enable the collaboration between Agile and other traditional management approaches while complying with the expectations while complying to organisational policies. And although the right conditions and mindsets sometimes already exist in parts of organisations, it takes a holistic approach and coordinated effort to ensure their organisation-wide success and sustainability.
The Agile PM² Extension
The PM² Methodology supports the use of Agile practices in PM² projects through Agile PM² which is an extension to the core methodology that provides the necessary collaboration framework. It helps those who are already applying Agile be enterprise compliant and those who are willing to incorporate agile practices into their projects to do so in an effective way.
Agile teams should be able to collaborate effectively with teams and stakeholders following alternative approaches.
By incorporating Agile into the overall PM² framework and project management culture creates the foundations for overall organisational agility and continuous learning and improvement.
Learn more about the PM² Project Management Methodology here.
The Agile PM² Extension has been developed to provide a structure that helps Agile teams to achieve the desired agility while still accommodating organisational procurement and audit requirements, working with contractors, collaboration with other projects, coordination with programme and portfolio levels, and other organisational units or even external organisations.
Fig: The positioning of Agile PM² within the Organisation and The Agile PM² flower
Agile PM² offers a well-balanced model that enables teams to work autonomously while ensuring conformity with enterprise structures and operations. It is worth mentioning that PM² has built-in flexibility that makes it easier to adopt Agile practices. At the same time, the need for the Agile teams to take into account the higher-level governance constraints can be fully satisfied by its alignment with PM².
The Agile PM² extension provides:
- Agile roles & responsibilities (as an extension to the PM² governance).
- integration with the overall PM² project lifecycle.
- a set of suggested Agile artefacts (as an extension to the PM² artefacts).
- A set of Agile PM² Mindsets.
Agile PM² Governance
PM² provides the appropriate governance framework, which reflects the project governance needs of an organisation as a whole, but also enables the Project Core Teams (PCT) to define Agile specific Roles and harness the benefits agile practices and of self-organisation.
Fig: The PM² Governance structure with the Agile PM² specific Roles
For this purpose, Agile PM² sets out a way to organise those Project Core Team (PCT) members that work in an Agile way. A set of additional roles & responsibilities are set out for Agile teams. The figure below shows how Agile project teams fit into the overall PM² project organisation.
Agile Performing Layer is a (sub) Layer of the PM² Perming Layer and it is where the Agile Project Core Team (A-PCT) and the Agile Roles are found.
The Agile Project Core Team (A-PCT)
The performance of Agile teams is based on self-organisation and a highly collaborative, mission-focused, and cross-functional composition. One of the main characteristics of Agile teams is that its members have a strong commitment towards achieving whole team performance, not just their own performance.
This is achieved through a strong shared mindset, a sense of belonging, of being in it together that honours agreed process and quality standards, respect individual and team commitments, promote a collaborative and cooperative working environment, share information and knowledge and help other team members. There should be no outsiders, no them and us, but all should work as one and towards a clear and shared goal.
Fig: The Agile PM² A-PCT Roles
The Agile Project Core Team (A-PCT) is part of the overall Project Core Team (PCT). In Agile PM², the additional agile specific roles comprising the Agile Project Core Team (A-PCT) are:
- Team Coordinator (TeCo) – equivalent to the well-known Scrum Master role.
- Product Owner (PrOw).
- Architecture Owner (ArOw).
- Agile Team Member (ATeM) – equivalent to the Scrum Development Team role.
Agile PM² Lifecycle
Let’s remember that PM² projects pass through four distinct phases. While the characteristics of some of these phases (e.g. planning) may not be as tangible at the level of Agile teams as they are at the overall project level, they still exist and it is important for project team members and stakeholders to have a common understanding of them. In Agile, typical project activities do not have a sequential character, but are executed within every iteration: planning, analysing, implementing, testing, and reviewing are done in every iteration with some Agile practices having a special time slot for planning and reviewing.
Fig: The Agile PM² significant overlapping of phase-related activities
The combination of the high-level phases and lower level iteration cycles results in an effort/time curve with greater overlap between activities over time, spanning multiple phases of the project.
The Agile PM² has iteration cycles at three levels – daily cycles, iterations, and releases. Regardless of their duration, these cycles follow what is termed in Agile PM² the CIR rhythm (Coordinate, Implement, Review).
Fig. The Agile PM² CIR rhythm
At the beginning of the project, the key concern is to understand what to build by determining an overall vision and identifying the stakeholders and their success criteria. In the middle of the project, the focus of the domain-specific activities shift towards incrementally building the solution as a progressively better understanding is achieved of what needs to be done and how. As the project nears completion, the focus shifts to ensuring that the solution is well-integrated into the overall project deliverables and that it contributes to the realisation of the benefits desired by the requestor organisation.
The Coordinate, Implement, Review (CIR) rhythm characterises all of the three cycles of Releases, Iteration, and Daily cycles.
Releases, Iterations and Daily Cycles
An Iteration is the repetition of a process. During an Agile PM² iteration, the Agile Project Core Team (A-PCT) produces a stable and demonstrable version of part of the solution, together with any necessary supporting documentation. The results of an iteration are potentially useable but are not necessarily made available for actual use by external stakeholders.
During each iteration, the team produces an increment or the solution which brings it closer to the final deliverable. Instead of building the solution one part after another, the whole solution is incrementally built and evolved (as needed) through each cycle.
Fig: Connecting PM² Project Phases to the various Agile Cycles
Iterations are (most often) timeboxed (i.e. fixed iteration duration strictly adhered to). The objectives of iterations are well-defined and should implement the highest-priority Work Items and address the most critical risks. The evaluation criteria are established, and the tasks and responsibilities of participants are made clear. Additionally, progress transparency is assured through the agreed metrics and methods for measuring.
In Agile PM², projects may have multiple releases of the solution produced to expose the results of the incremental progress achieved in one or more iterations. Unlike regular iterations, the result of release is also made available to outside stakeholders and users. Releases and Release Planning enable the Agile Project Core Team to define and manage the effort and dependencies associated with each increment. The stable, demonstrable output of the releases enables teams to demonstrate tangible progress to stakeholders and get feedback at an early stage so that they can improve their understanding of what needs to be done and how to do it.
The Agile PM² Daily Cycles represent the smallest level iteration which again follows the CIR rhythm. Multiple daily cycles constitute an Iteration, and an iteration of special-purpose aiming to release the results of multiple previous iterations constitute an Agile PM² Release.
The Agile PM² Artefacts
Documenting the work planned and performed by the Agile teams is critical in increasing transparency and coordination between the different layers of the PM² project organisation (i.e. between the directing, managing and performing layers).
Note that there is a common misunderstanding that Agile means no documentation. This is not true, and in fact, according to the lean concepts, no documentation can be an equal waste to too much documentation. The correct implementation of the Agile philosophy calls for enough documentation – enough being defined by both the needs of the project, the team and stakeholders and by the corporate requirements for transparency, traceability, and control.
Agile PM² defines a set of Artefacts that support the work of Agile teams. The table below groups the various Activities and Artefacts of Agile PM² into the four PM Phases. Note that in this table, each of the Agile PM² Artefacts is shown as belonging to one of the PM² Phases, however, this is only accurate to the extent that it shows the phase in which the specific artefact is first instantiated. The truth is that following the spirit of Agile, these artefacts are developed in an iterative and incremental manner, therefore frequently updated to contain up to date information and at the appropriate level of detail.
Fig: An overview of the AgilePM² actives and artefacts in each phase
The Agile PM² artefacts capture and document information regarding the management approach, regarding specific (implementation) activities, milestones, issues and progress reporting.
These artefacts are grouped in three categories: Agile-specific artefacts, coordination & reporting artefacts, and project governance artefacts.
Fig: Agile PM² Artefacts Landscape
Project Governance Artefacts provide the information requested by Organisational and Project Governance. It includes artefacts such as the Business Case, the Project Charter, and for IT systems Architecture Overview and the Security Plan.
Agile Specific Artefacts capture information regarding the planning of specific (implementation) processes, activities, releases, iterations, and other milestones. It includes artefacts such as the Development Handbook (part of the overall Project Handbook), the Development Work Plan (part of the overall Project Work Plan), the Deployment Plan (part of the overall Transition Plan) and the Testing Plan (part of the overall Deliverables Acceptance Plan).
Coordination & Reporting Artefacts capture the information needed to coordinate the overall project activities with those undertaken by the Agile team and to ensure that the Project Manager (PM) has visibility of the Agile-specific activities, issues, milestones, and progress. It includes artefacts such as the Agile Logs (Testing Log, Retrospectives Log) and the Development Status Report.
This article is based on publicly available information from:
- The PM² Guide – Open Edition, November 2016 (Appendix, pages A-101 to A-107)
- The PM² Guide, v3.0, October 2019
- PM² Conference – Introduction to PM²
