AgilePM Foundation cheat sheet

AgilePM is built on the DSDM framework, which rests on four pillars: philosophy, principles, people, and process.

The eight DSDM principles are: focus on the business need; deliver on time; collaborate; never compromise quality; build incrementally from firm foundations; develop iteratively; communicate continuously and clearly; demonstrate control.

The AgilePM philosophy states that the best business value emerges when projects are aligned to clear business goals, deliver frequently, and involve the collaboration of motivated and empowered people.

AgilePM is chosen when the business need is urgent, requirements are uncertain or likely to change, and iterative delivery of early value is desired.

Fixed-length timeboxes are used to control risk: scope is flexed, while time and cost (and often quality) are fixed.

The 'triangle' of time, cost and quality is fixed at the project level; requirements (scope) are prioritised using MoSCoW and flexed within timeboxes.

Sufficient upfront design is done to enable later iterative development ('build incrementally from firm foundations'); just enough, not just in case.

AgilePM defines a project as a temporary structure to deliver a defined business benefit, distinct from ongoing business-as-usual operations.

Three project-level roles: Business Sponsor (owns the business case and funds the project), Business Visionary (provides business direction), Technical Coordinator (leads the solution development team).

Project Manager: manages day-to-day project delivery, owns the Project Plan and controls at the project level, and is responsible for the overall project management.

Team Leader: leads the Solution Development Team, ensures the team works to AgilePM practices, and represents the team to the Project Manager.

Business Ambassador: provides business knowledge and supports the team in delivering the business requirements; part of the Business roles.

Solution Tester: responsible for testing the solution against requirements and ensuring it meets the agreed quality criteria.

Workshop Facilitator: plans and facilitates workshops, ensuring effective communication and collaboration among stakeholders.

Business Analyst: supports the Business Visionary in capturing requirements and defining the business need; part of Business roles.

Solution Developer: interprets requirements and builds the solution; part of the Solution Development Team.

The Solution Development Team combines Business, Solution and Management roles and must be empowered and stable to deliver iteratively.

The Business Case is a project-level product owned by the Business Sponsor and demonstrates the business value of the project.

The Project Plan is a project-level product owned by the Project Manager, defining the overall approach, timeboxes and resources.

The Prioritised Requirements List (PRL) is a project-level product capturing requirements using MoSCoW prioritisation, owned by the Business Visionary.

The Solution Architecture Definition is a project-level product that describes the overall solution structure and is owned by the Technical Coordinator.

The Development Approach Definition is a project-level product describing how the solution will be developed, owned by the Technical Coordinator.

Timebox Plans are timebox-level products created by the Solution Development Team to plan the work of each timebox.

The Product Checklist lists the products to be delivered in a timebox and their status; it is a timebox-level product.

Foundations are established through the Feasibility and Foundations phases, producing the Business Case, PRL, and other baseline products before delivery begins.

MoSCoW prioritisation: Must Have, Should Have, Could Have, Won't Have (this time); Must Haves must not exceed 60% of effort, and Could Haves should be around 20%.

Timeboxing: fixed periods of time (typically 2-4 weeks for a timebox in a project) within which work is prioritised and delivered; scope is flexed to protect the timebox.

Iterative development: the solution is developed in increments, each building on the previous, with feedback from stakeholders at each stage.

Modelling: using models (e.g., diagrams, prototypes) to explore and communicate requirements and solutions; models are used to support, not replace, collaboration.

Daily Stand-up: a short, daily team meeting (typically 15 minutes) to share progress, plan the day and identify blockers.

Workshops are used to gather requirements and reach decisions collaboratively; the Workshop Facilitator plans and runs them.

Retrospectives are held at the end of each timebox to reflect on what went well and what to improve.

Configuration management and quality assurance are applied continuously to keep the solution under control and fit for purpose.

The lifecycle has five phases: Feasibility, Foundations, Evolutionary Development, Deployment, and Post-Project.

Feasibility phase: the first phase, assessing whether the project is viable and producing the Business Case outline and Feasibility Assessment.

Foundations phase: establishes the project foundations, producing the PRL, Project Plan, Solution Architecture Definition and Development Approach Definition; ends with the Foundations Summary.

Evolutionary Development phase: iterative development through timeboxes, each producing a potentially shippable increment; includes the Timebox process.

Deployment phase: the solution is deployed into live use, producing the Deployment Plan and the Benefits Plan.

Post-Project phase: after the project ends, assessing whether the expected benefits have been realised.

The Timebox process within Evolutionary Development has stages: Timebox Planning, Timebox Review, and Timebox Retrospective.

The Feasibility phase is optional in some circumstances, but the Foundations phase is mandatory before delivery begins.

Each phase ends with a review and, where appropriate, a decision to proceed, ensuring control points are maintained.