The document provides an overview of Agile Project Management (APM) according to the DSDM Atern framework. It discusses the fundamentals and philosophy of APM, which focuses on delivering business value iteratively within fixed timeboxes. It also outlines the key principles, roles, products, and techniques used in APM such as prioritization with MoSCoW, timeboxing, requirements management, and facilitated workshops. Measurement focuses on business value, quality, effort and delivery speed.

1. DSDM® Atern - APMG™
Agile Project Management
A brief summary of its foundations according to the
Handbook version 1.1
Pablo Gonzalez Garcia
2013

2. Contents
Agile Project Management
Fundamentals
Philosophy
Principles
Preparation
The Lifecycle
Roles and Responsibilities
Products
Facilitated Workshop
MoSCoW Prioritisation
Timeboxing
Requirements
Measurements
Quality
Planning
Risks
2/22

3. Fundamentals
Agile Project Management
DSDM Atern → Agile Project Delivery Framework = Project Management Lifecycle + Product
Development Lifecycle
Time
Cost
Fixed Variables
Acceptance criteria is agreed and
set before development
commences
Quality
Variable
Features
•
•
•
If Contingency is required:
MoSCoW rules for prioritization
Minimum Usable Subset is guaranteed
Business Benefit drive the prioritization
Contingency is managed within the prioritization of the features rather than by adding extra
cost or time.
3/22

4. Philosophy
Agile Project Management
Principles
Process
People
Products
Practices
Project Lifecycle
Roles &
Responsibilities
Deliverables
Techniques
Atern → Tailored to suit Project Environment
↓
Adequate formality so that waste is eliminated and all activities add value
“Negotiation is around the fine detail”
4/22

5. Principles I
1- Focus on the
Business Need
2- Deliver on
Time
3- Collaborate
Agile Project Management
•
•
•
•
Understand the true business priorities
Establish a sound business case
Seek continuous business sponsorship and commitment
Guarantee the minimum usable subset
• Timebox the work
• Focus on business priorities (MoSCoW)
• Always hit deadlines
• Involve the right stakeholders at the right time
• Ensure that the members of the team are empowered to take
decisions on behalf those they represent
• Actively involve the Business Representatives
• Build a one-team culture
5/22

6. Principles II
Agile Project Management
4- Never
compromise
Quality
•
•
•
•
•
5- Build
incrementally
from firm
Foundations
• Strive for early delivery of business benefit
• Continually confirm the correct solution is being built
• Formally re-assess priorities and on-going project viability
6- Develop
iteratively
•
•
•
•
•
•
Set the level of quality at the outset
Ensure that quality does not become a variable
Design, document and test appropriately
Build in quality by constant review
Test early and continuously
Do Enough Design up Front (EDUF)*
Take an iterative approach to building all products
Build customer feedback into each iteration
Accept that most detail emerges later rather than sooner
Embrace change
Be creative, experiment, learn and evolve
*Enough Design up Front (EDUF) instead of :
Big Design up Front (BDUF): Traditional projects, lack of flexibility or creativity
No Design up Front (NDUF): Other Agile approaches, too risky in complex structures
6/22

7. Principles III
Agile Project Management
• Run daily team stand-up* sessions
• Use facilitated workshops
7- Communicate • Use rich communication techniques such as modelling and
prototyping
continuously and
• Present instances of the evolving solution early and often
clearly
• Keep documentation lean and timely
• Manage stakeholders expectations throughout the project
• Encourage informal face to face communication at all levels
8- Demonstrate
control
• Use an appropriate level of formality for tracking and reporting
• Make plans and progress visible to all
• Measure progress through focus on delivery of products rather than
completed activities
• Manage proactively
• Evaluate continuing project viability based on the business
objectives
*The Daily Stand-up:
Each team member in turn describes:
• What they have been doing since the last Stand-up
• What they will be doing between now and the next Stand-up
• Any problems, risks or issues
Short and fixed duration (15 minutes)
7/22

8. Preparation
Agile Project Management
I.S.F. - Instrumental Success Factors
1. Acceptance of the Atern philosophy before starting work
2. Appropriate empowerment of the solution development team
3. Commitment of Senior Business Management to provide the necessary Business
Ambassador involvement
4. Incremental Delivery
5. Access by the solution development team to business roles
6. Solution development team Stability
7. Solution development team Skills
8. Solution development team Size (7±2)
9. A supportive commercial relationship
P.A.Q. - Project Approach Questionnaire
 identifies and confirm level of achievement of above ISFs and assess potential risk areas to
be addressed
 Completed during feasibility process on the Outline Plan product
 Re-assessed during foundations process on the Management Foundations product
8/22

9. The Lifecycle
Agile Project Management
Pre-Project
Proposal
Feasibility
First opportunity to asses the feasibility from a Business and Technical
perspective
Foundations
Establish firm foundations on the Business, Solution and Management
areas
Exploration and
Engineering
Evolve the solution with functional requirements (Exploration) and
non-functional requirements (Engineering)
Deployment
Put the solution in live use
Post-Project
Assess whether the benefits have actually been achieved
9/22

10. Roles and Responsibilities
Agile Project Management
•
Business
Visionary
Business
Ambassador
Business
Analyst
Team
Leader
Technical
Coordinator
Business
Advisor
Solution
Developer
Solution
Tester
DSDM
Coach
Other
Workshop
Facilitator
Solution Development Team
Technical
Advisor
Project
Manager
Project Level
Business
Sponsor
•
•
•
•
Business Sponsor: owns the
Business Case, takes
financial decisions.
Business Visionary:
Customer vision, interprets
needs.
Technical Coordinator:
Supplier vision.
SDT: can be one or more
Size 7 ± 2
One DSDM role does not
necessarily mean one
person.
Business
Manage
ment
Solution
10/22

11. Products I
Pre-Project
Feasibility
Agile Project Management
Terms of Reference: Business Driver and Scope for the project overall.
Justification for the Feasibility phase
Feasibility Assessment: Outline Business Case, Risk Assessment, Outline
Solution, Feasibility Prototype (opt.)
Outline Plan: Outline Plan, Project Approach Questionnaire (P.A.Q.)
Business Foundations: Business Vision, Business Case
Prioritised Requirement List: High Level Requirements, MoSCoW priorities
Requirements are baseline, agreed and signed-off
Solutions Foundations: Business Area Definition (BAD), System Architecture
Definition (SAD), Deployment Approach Definition (DAD): Solution review and
testing strategy
Foundations
Solution Prototype (opt.)
Management Foundations: Project Organisation, Project Governance,
Management Approach (P.A.Q. re-assessed)
Delivery Plan: Schedule of Timeboxes, Deployment Plan (outline)
Delivery Control Pack: Risk Log, Periodic Reports, Change Control Records (only
changes on the scope)
11/22

12. Products II
Agile Project Management
Evolving Solution: Business Models (from BAD), Design Models (from SAD),
Business User Documentation, Prototypes, Deployable Solution, Support
Documentation
Exploration and
Engineering
Solution Assurance Pack: Business Testing Pack, System Testing Pack, Solution
Review Records (input for Timebox Review Record)
Deployment Plan: Business Deployment Plan, System Deployment Plan, Benefits
Realisation Plan
Timebox Plan: for each development Timebox
Timebox Review Record: for each development Timebox
Deployed Solution: An in increment of the solution in live use
Deployment
Post-Project
Project Review Report: Increment Review, Benefits Enablement Summary, End
of Project Assessment
Benefits Assessment: For each increment (outcome) and/or for the project as a
whole
12/22

13. Facilitated Workshop
Objective
Owner
Participants
Facilitator
Agile Project Management
Product
Solution
Needs the outcome of the workshop
Is the driver for it to happen
Set of people who are chosen and empowered to produce the product
or solution
Neutral and independent person
Benefits
 Rapid, high quality decision making
 Greater buy-in from all stakeholders
 Building team spirit
 Building consensus
 Clarification of issues
Success Factors
 Effective, trained, independent Workshop
Facilitator
 Flexibility in the format, but clearly defined
objectives
 Thorough preparation before the workshop
 Results of previous workshops are built in
 Decisions and agreements are not forced
 Workshop report within 48 hours
13/22

14. MoSCoW Prioritisation
Must Have
Should Have
Could Have
Won’t Have
(this time)
Agile Project Management
Maximum 60% of total effort
Worst Case, Minimum Usable Subset (based on anticipated benefit)
Cannot deliver without this
No point delivering on target date without this
What happens if this requirement is not met? ‘Cancel the project’
Maximum 20% of total effort
Expected Case
Important but not vital
May be painful to leave out, but the solution is still viable
May need some kind of workaround
Maximum 20% of total effort
Best Case
Wanted / desirable but less important
Less impact if left out (compare with a should have)
Agreed these requirements will not be delivered
Recorded in PRL
80% of the solution can be produced in 20% of the time that it would take to produce the
total solution
14/22

15. Timeboxing I
Iterative Development Cycle
Agile Project Management
Timebox Control
Kick Off
Investigation
• Review objectives
• Provide a firm
foundation to develop
• Ensure feasibility
the work
• Agree acceptance criteria
• Confirm availability of resources
• Review dependencies
• Assess risks
Refinement
• Develop the work
• Testing
• Ends with a review with Business
Ambassador to decide if the
acceptance criteria will be met
• Define actions to achieve
acceptance
Consolidation
• Perform actions agreed at
refinement
• Quality control
Control
• Timebox Review Records
• Solution Review Records
• Daily Stand-up meeting
Close Out
• Formal sign off
• Assess work not
completed
• Lessons learned
15/22

16. Timeboxing II - Planning and Scheduling Timeboxes
Agile Project Management
Feasibility and Foundations
P
r
o
j
e
c
t
I
n
c
r
e
m
e
n
t
1
Timebox 1
Fixed end date / Output
Exploration and
Engineering
Timebox 2
Fixed end date / Output
Timebox 3
Fixed end date / Output
Deployment
Fixed end date / Outcome
I
n
c
r
Application of the Timeboxing technique in conjunction with MoSCoW
prioritisation will ensure on-time completion of each Timebox and the
delivery of a fit-for-purpose product in that timeframe
2
16/22

17. Requirements
Feasibility
Agile Project Management
Outline
Plan
Typically <10 requirements by end Feasibility
Rough estimates
‘Broad picture’
Project Go / No-Go
Foundations
Delivery
Plan
Typically <100 requirements by end Foundations
Accurate ± 50%
‘What’ to do
Project Go / No-Go
Exploration
and
Engineering
Requirement
• Service
• Feature
• Function
Timebox
Plan
Typically >100 requirements by end Exploration
and Engineering
‘How’ to do it
Non-functional Requirement
• Performance
• Supportability
• Capacity
• Maintainability
• Security
17/22

18. Measurements
Business Value
(or outcome)
Agile Project Management
Earned Value Analysis (EVA). Measure the value that has been ‘earned’ to date in
the project (on the product/result/service).
Output
Used to define the objectives for the Timeboxes (deliverables).
Quality
Number of defects.
Effort and delivery The effort of a timebox is fixed and it is expected to deliver a number of
prioritised features.
speed (velocity)
Cost
The Business Case is based on the balance between cost and business value.
18/22

19. Quality
Agile Project Management
Not 100% but still a quality solution
The quality is judged on whether the solution contains at least the
Minimum Usable Subset (60% solution) and whether all delivered
requirements meet the agreed standard.
Maintainability
Level 1
Maintainability is a required attribute of the initial delivered solution
Level 2
Deliver first, re-engineer later
Level 3
Short term, tactical solution
19/22

20. Planning
Agile Project Management
•
•
•
•
Plan in detail Foundations
Approximation of the size and duration of the overall project
Outline the first increment
List the planned dates for deployment of later increments
•
•
•
•
Schedule the work
Outline the number and likely length of the Timeboxes
Include an outline of the Increments
Describe the overall structure and approach
Deployment Plan
•
Exploration and
Engineering
•
Include Business Deployment Plans, System Deployment Plans and Benefits
Realisation Plans
Focus on specific tasks to be performed by specific individuals
Timebox Plan
•
•
Details the deliverables (outputs), activities and resources of a Timebox
Focus on outputs
Outline Plan
Feasibility
Delivery Plan
Foundations
20/22

21. Risks I
Agile Project Management
Risks to successful Atern
Low or patchy
availability of
Business roles
Having a fully
detailed specification
In the early lifecycle phases, define and agree the level of commitment needed.
Try to introduce the concept of Iterative Development and Enough Design Up
Front (EDUF) before time and effort is spent producing this detailed
specification.
Expecting the 100%
solution
Atern’s approach is based around the idea that Time, Cost and Quality are fixed
and contingency is built around the prioritisation of Features. The best case is to
deliver the 100% solution.
Swapping resources
in and out of the
team
Try to ring-fence the team for the duration of the project. Atern’s small teams
and the use of rich communication means that a lot of the team information is
known and shared informally, rather than being formally written down.
21/22

22. Risks II
Agile Project Management
How Atern reduces risks
The business don’t
know exactly what
they want
This is seen as normal as the detail emerges through ‘Iterative Development’.
The business change
their minds
Change is seen as a fact of life and is encompassed within the Timebox and
MoSCoW prioritisation process.
Not having all the
detail agreed at the
start
Atern’s principle of ‘Build from Firm Foundations’ ensures Enough Design Up
Front (EDUF) is done to move the project safely forward.
Unwillingness to
commit to final signoff
Using Atern’s Timeboxes the business accepts the evolving solution
incrementally.
Late delivery
The whole Atern approach is designed to deliver the right solution on time.
22/22