AgilePM® - Agile Project Management - Foundation

TheAPMG-InternationalAgileProjectManagementandSwirlDevicelogoisatrademarkofTheAPMGroupLimited.
DSDM,Atern,AgilePM,AgilePgM,AgilePFareRegisteredTradeMarksofDynamicSystemsDevelopmentMethodLimited.

Start and finish Course style
LunchCoffee and breaks
M00 - Course introduction 2/11 | 2/270

 The underpinning philosophy, principles, terminology
of AgilePM
 The lifecycle of an AgilePM project
 The products/artefacts produced by AgilePM project
 AgilePM roles and responsibilities
 AgilePM recommended techniques, their benefits
and limitations
 The mechanisms for control and how to test,
estimate and measure progress in an Agile project
Main goal
 Attempt Foundation exam with confidence
 Communicate freely within AgilePM project,
understanding its principles and philosophy
Secondary goal
 Benefits and value of Agile and AgilePM

 Please share with the class:
 Your name and surname
 Your organization
 Your profession
 Title, function, job responsibilities
 Your familiarity with the
agile project management
 Your familiarity with the business
analysis
 Your experience with DSDM/AgilePM/
Scrum and BABOK
 Your personal session expectations

 Foundation Exam
 Paper based and closed book exam
 Only pencil and eraser are allowed
 Simple multiple (ABCD) choice exam
 Only one answer is correct
 60 questions, pass mark is 30 (50%)
 1 hour exam
 No negative points, no “Tricky Questions”
 No pre-requisite for Foundation exam
 Sample, two (official) mock exams are
provided to you
Candidates completing an examination in a language that
is not their mother tongue, will receive additional time

 Practitioner Exam
 Paper based and open book exam
 Reference to AgilePM Handbook ONLY
 Handbook is provided for students
 2 hour exam
 Complex multiple choice - Objective Test
 4 questions worth 15 marks each (60
marks), pass mark is 30 (50%)
 Pre-requisite for AgilePM Practitioner
 AgilePM Foundation or
 DSDM Atern Foundation certificate or
 DSDM Advanced Practitioner certificate
Candidates completing an examination in a language that
is not their mother tongue, will receive additional time

Handbook Page
AgilePM syllabus section code and title
LP Lifecycle and Products
PR People and Roles
TE Techniques
CO Control
Module slide number / total module slides
Slide number /
total slides
Module number
and name
AgilePM
handbook page
AgilePM syllabus
section code
AgilePM is defined in the Agile
Project Management Handbook
• v1.2, 2013
• ISBN 0-9544832-4-3
SyllabusM00 - Course introduction 7/11 | 7/270

See Appendix #2 for more mind maps from DSDM Consortium products

quizlet.com/42743032/

Freeware, scalable
AgilePM PDF
reference card
Project Phases vs Products vs
Roles vs Responsibilities in one
big reference card
Free to download, use
and share

twitter.com/mirodabrowski
linkedin.com/in/miroslawdabrowski
google.com/+miroslawdabrowski
miroslaw_dabrowski
www.miroslawdabrowski.com
Mirosław Dąbrowski
Agile Coach, Trainer, Consultant
(former JEE/PHP developer, UX/UI designer, BA/SA)
Creator Writer / Translator Trainer / Coach
• Creator of 50+ mind maps from PPM and related
topics (2mln views): miroslawdabrowski.com
• Lead author of more than 50+ accredited materials
from PRINCE2, PRINCE2 Agile, MSP, MoP, P3O, ITIL,
M_o_R, MoV, PMP, Scrum, AgilePM, DSDM, CISSP,
CISA, CISM, CRISC, CGEIT, TOGAF, COBIT5 etc.
• Creator of 50+ interactive mind maps from PPM
topics: mindmeister.com/users/channel/2757050
• Product Owner of biggest Polish project
management portal: 4PM: 4pm.pl (15.000+ views
each month)
• Editorial Board Member of Official PMI Poland
Chapter magazine: “Strefa PMI”: strefapmi.pl
• Official PRINCE2 Agile, AgilePM, ASL2, BiSL methods
translator for Polish language
• English speaking, international, independent
trainer and coach from multiple domains.
• Master Lead Trainer
• 11+ years in training and coaching / 15.000+ hours
• 100+ certifications
• 5000+ people trained and coached
• 25+ trainers trained and coached
linkedin.com/in/miroslawdabrowski
Agile Coach / Scrum Master PM / IT architect Notable clients
• 8+ years of experience with Agile projects as a
Scrum Master, Product Owner and Agile Coach
• Coached 25+ teams from Agile and Scrum
• Agile Coach coaching C-level executives
• Scrum Master facilitating multiple teams
experienced with UX/UI + Dev teams
• Experience multiple Agile methods
• Author of AgilePM/DSDM Project Health Check
Questionnaire (PHCQ) audit tool
• Dozens of mobile and ecommerce projects
• IT architect experienced in IT projects with budget
above 10mln PLN and timeline of 3+ years
• Experienced with (“traditional”) projects under high
security, audit and compliance requirements based
on ISO/EIC 27001
• 25+ web portal design and development and
mobile application projects with iterative,
incremental and adaptive approach
ABB, AGH, Aiton Caldwell, Asseco, Capgemini, Deutsche Bank,
Descom, Ericsson, Ericpol, Euler Hermes, General Electric,
Glencore, HP Global Business Center, Ideo, Infovide-Matrix,
Interia, Kemira, Lufthansa Systems, Media-Satrun Group,
Ministry of Defense (Poland), Ministry of Justice (Poland),
Nokia Siemens Networks, Oracle, Orange, Polish Air Force,
Proama, Roche, Sabre Holdings, Samsung Electronics, Sescom,
Scania, Sopra Steria, Sun Microsystems, Tauron Polish Energy,
Tieto, University of Wroclaw, UBS Service Centre, Volvo IT…
miroslawdabrowski.com/about-me/clients-and-references/
Accreditations/certifications (selected): CISA, CISM, CRISC, CASP, Security+, Project+, Network+, Server+, Approved Trainer:
(MoP, MSP, PRINCE2, PRINCE2 Agile, M_o_R, MoV, P3O, ITIL Expert, RESILIA), ASL2, BiSL, Change Management,
Facilitation, Managing Benefits, COBIT5, TOGAF 8/9L2, OBASHI, CAPM, PSM I, SDC, SMC, ESMC, SPOC, AEC, DSDM Atern,
DSDM Agile Professional, DSDM Agile Trainer-Coach, AgilePM, OCUP Advanced, SCWCD, SCBCD, SCDJWS, SCMAD, ZCE 5.0,
ZCE 5.3, MCT, MCP, MCITP, MCSE-S, MCSA-S, MCS, MCSA, ISTQB, IQBBA, REQB, CIW Web Design / Web Development /
Web Security Professional, Playing Lean Facilitator, DISC D3 Consultant, SDI Facilitator, Certified Trainer Apollo 13 ITSM
Simulation …

AgilePM® - Agile Project Management - Foundation

1. Defining agile and AgilePM
2. AgilePM philosophy and principles
3. AgilePM roles and responsibilities
4. Preparing for AgilePM project
5. AgilePM project lifecycle, phases and products
6. Communication
7. Delivering on time - prioritization and timeboxing
8. Requirements, estimating and measurement
9. Project planning
10. Never compromising quality
11. Project control and risk management
M01 - Defining agile and AgilePM 2/27 | 13/270

 A philosophy and a mindset
 Flexibility, agility, adaptability, incremental delivery,
iterative cycle, fast and constant feedback, engagement
 Working closely and constantly with customer throughout
 Ensuring final solution actually meets business needs
 Focusing on business value/outcome NOT strictly project plan/output
 Focusing on value delivery NOT on fixed product definition
 Deferring decisions about details as late as possible
 No “big design up front” (BDUF), rather Enough Design Up Front (EDUF)
“If a process is too unpredictable or too complicated for the planned, (predictive)
approach, then the empirical approach (measure and adapt) is the method of choice“
Ken Schwaber
14M01 - Defining agile and AgilePM 3/27 | 14/270

Agile Mindset 4 Agile Values 12 Agile Principles

Agile PracticesAgile Mindset 4 Agile Values
Unlimited
number of
practices
12 Agile Principles

Scrum
XP
AgilePM
SAFe
Agile PracticesAgile Mindset 4 Agile Values 12 Agile Principles

Scrum
XP
AgilePM
SAFe
Agile PracticesAgile Mindset 4 Agile Values 12 Agile Principles
Being Agile Doing Agile

Dynamic Systems Development Method (DSDM)
Agile Project Management (AgilePM)
Agile Unified Process (AUP)
Open Unified Process (OpenUP)
Scaled Agile Framework (SAFe)
Disciplined Agile Delivery (DAD)
Scrum-of-Scrums
Scrum at Scale
…
Scrum
Lean software development
Kanban (process + method)
Extreme Programming (XP)
Continuous Integration (CI)
Feature Driven Development (FDD)
Test Driven Development (TDD)
Crystal Clear
…
Fuller ApproachesLightweight Approaches

“We are uncovering better ways of developing software by
doing it and helping others do it”
Through this work we have come to value
Traditional Agile
Processes and Tools over People and Interactions
Comprehensive Documentation over Working Software
Contract Negotiation over Customer Collaboration
Following a Plan over Responding to Change
While there is value in the items on the right; we value the items on the left more.
(but Agile is not just about delivering software, it applies to all types of project)
www.agilemanifesto.org

 Approaches typically call for a significant
amount of formality and detail
 Big Design Up Front (BDUF)
 Requirements are captured in a formal set
of documents which follow standardized
templates
 This may be preceded by a number of
detailed requirements related documents,
built with increasing levels of detail,
including a high level vision and low level
functional requirements documents
 Relevant stakeholders must generally
formally approve each of these documents
before work begins
Sequential /
cascade / waterfall

 Different style of management (compared
to traditional (a.k.a. waterfall))
 Enabling constant change during elaboration of
the detail
 Continuously correcting course
 Maintaining aim on target -> value (delivering a
usable solution on a fixed date)
 Monitoring progress in a different way
 Measured by delivery of products (not by activity)
 Sustaining the high rate of progress throughout
 Targeting and motivating empowered
teams (Not directing them)
 Servant Leadership
 Collaboration requires a no-blame culture
 Building culture of team success/failure
Incremental, iterative
and adaptive

Plan Design Code Test Release Review
Decision Demo
Value to business after
big bang deployment
Working solution

Ability to Change
Business Value Risk
(of delivering wrong solution)
Waterfall
time
time time
time
?
Business Engagement
(visibility)

Project adaptation for
changed/new business
requirements
requirements
requirements
Plan Design Code Test Release Review
Working solutionAgilePM is not just smaller waterfall!
big bang deployment
Plan
Review
Plan
Review
Plan
Review
Plan
Review
Test
Analyse
Test
Analyse
Test
Analyse
Test
Analyse
deployment #1
deployment #2
deployment #3
final deployment #4
Decision Demo Decision Demo Decision Demo Decision Demo

Waterfall Agile
Business Value
time
time time
time
Ability to Change
Risk
(of delivering wrong solution)
Business Engagement
(visibility)

 Simple (straightforward)
 Everything is known
 Complicated
 More is known than unknown
 Complex
 More is unknown than known
 Chaotic (unpredictable)
 Very little is known
TECHNOLOGY
REQUIREMENTS
Far from
Agreement
Close to
Agreement
Close to
Certainty
Far from
Certainty
Source: Strategic Management and Organizational Dynamics by Ralph
Stacey in Agile Software Development with Scrum by Ken Schwaber and
Mike Beedle.
Agile thrives
here

 Agile Project Management is based on
another method called DSDM Atern
 DSDM - The oldest established Agile
approach
 Originally launched in 1994
 DSDM is owned by The DSDM
Consortium
 A not-for-profit collegiate organization
 www.dsdm.org
 Certification of individuals from
AgilePM is maintained globally by
APMG International

 Agile project delivery framework that
delivers the right solution at the right time
 Project team and significant stakeholders being
focused on the business outcome
 Delivery is on time ensuring an early ROI
 All people involved work collaboratively to
deliver the optimum solution
 Work is prioritised according to business need
and the ability of users to accommodate
changed in the agreed timescale
 Atern does not compromise on quality i.e. the
solution is not over or under engineered
 Atern Agility
 Atern Flexibility
 Hybrid method combining project
management with product delivery
Lead author:
Keith
Richards

 An Agile full Project Delivery Framework that delivers the
right solution at the right time
 Any kind of project
 Focused on business value
 On time and in budget
 Quality and control
 Incremental
 Iterative
 Adaptive
 Collaborative
 Right solution at the right time
 Established and proven integration
with PRINCE2

02.1995
•DSDM V1
12.1995
•DSDM V2
09.1997
•DSDM V3
2002
•DSDM
V4
2003
•DSDM
V4.1
2006
•DSDM
V4.2
2008
•DSDM V5
(Atern)
07.2010
•AgilePM
V1
Published
online
Published
online
also
published
online

 What is the Requirement or Context?
 Simple or Complex Environment?
 Simple Product Development?
 On-going backlog of features/improvements to be built
 Delivering Projects and Programmes?
 Full project lifecycle
 Cross project dependencies
 Minimal formality or within a structured
corporate culture?
 Constant contact with client/business?

 Lightweight agile approaches adequate
for simpler environments
 Complex environments need a fuller Agile
approach
 Concept of “Project” management and delivery
 Project Manager role
 Full lifecycle
 Compliance and regulations requirements
 Recognizing the constraints of corporate culture
 Integrated project gateway systems with compliance
and audits checks

 Does your organization promote Agile?
 Are there any formal projects managed in
Agile style in your organization?
 Which Principles are used in you
organization?
 Are there any formal approaches defining
which principle?
 Polices, documents, management practices …
 Are there any centre of excellences
providing knowledge of Agile?
 Are you using Agile for entire project,
or just for specific project phases/areas?

1. Defining agile and AgilePM
2. AgilePM philosophy and principles
3. AgilePM roles and responsibilities
4. Preparing for AgilePM project
5. AgilePM project lifecycle, phases and products
6. Communication
7. Delivering on time - prioritization and timeboxing
8. Requirements, estimating and measurement
9. Project planning
10. Never compromising quality
11. Project control and risk management
M02 - AgilePM philosophy and principles 2/39 | 40/270

 Projects must be aligned to clearly defined strategic goals
 Focus on early delivery of real benefits to the business
 To be successful requires
 Key stakeholder understanding of business objectives
 Empowerment to the appropriate level
 Constant and ongoing collaboration with the client and end users
to deliver the right solution at the right time according to business
priorities
 Stakeholders willing to deliver a fit-for-purpose solution (not full
scope solution)
 Acceptance that change is inevitable and it is integral part of our
lives and as well part of our projects
18M02 - AgilePM philosophy and principles 4/39 | 42/270

 Every project is different, principles have to be adapted
 „adopt and adapt” approach
 AgilePM need to determine the correct level of rigour
 Too much formality can slow progress down, even cause paralysis
 Too little formality can lead to a seat-of-the-pants approach
 Risk assessment is undertaken early on in the project
lifecycle and is part of project lifecycle
 e.g. using Project Approach Questionnaire (PAQ)
 Ensure AgilePM projects are not „out of Governance”
 Maintain people empowerment and degree of freedom

 Principles support the philosophy
 AgilePM has 8 principles
 Highlight attitude and mindset needed by team
 Compromising any principle undermines philosophy
 And introduces risk (threats)
 Applying all principles ensures maximum benefit
 Collectively principles enable organizations (not just
projects) to collaboratively deliver best value solutions

1. Focus on the business need
2. Deliver on time
3. Collaborate
4. Never compromise quality
5. Build Incrementally from firm foundations
6. Develop Iteratively
7. Communicate continuously and clearly
8. Demonstrate control

“There is nothing so
useless as doing
efficiently that which
should not be done
at all.”
Peter F. Drucker

 Decisions are always based around project goal
 To deliver WHAT business NEEDS (not just wants) it to deliver,
WHEN it needs to be delivered
 Needs can be different that requirements
 Requires to
 Explore and understand true business priorities
 Establish sound and agreed business case
 Deliver Minimum Useable Subset of requirements
 Principle supported by
 Roles: Business Sponsor, Business Visionary
 Products: Business products agreed at Foundations
 Techniques: MoSCoW, Timeboxing

“My favorite things in life
don't cost any money. It's
really clear that the most
precious resource we all
have is time.”
Steve Jobs

 Requires to
 Timebox the work (aka. Sprint in Scrum) the work
 Have clear focus on business priorities and needs (not just
requirements)
 Always hit deadlines - predictable deliverables
 Build confidence through predictable delivery and maintain reputation
 DO NOT EVER EXTEND TIMEBOX!
 Instead deliver smaller scope
 Roles: Project Manager, Team Leader
 Techniques: MoSCoW, Timeboxing
21
Hurts Agile culture; Breaks
habits; Lowers teams
reputation as a trusted
business partner

“Good design begins
with honesty, asks
tough questions, comes
from collaboration and
from trusting your
intuition.”
Freeman Thomas

 Requires to
 Involve the right stakeholders at the right time, throughout project
 Ensure team members are empowered to make decisions
on behalf of those they represent
 Encourage pro-active involvement from the business
representatives
 Build a one team culture (also between supplier and customer)
 Work in a spirit of active cooperation and commitment
 Roles: Business Sponsor, Business Visionary, Business Ambassador
 Techniques: Facilitated Workshops, Daily Stand-ups

“Quality is not an act,
it is a habit.”
Aristotle

 Requires team to
 Set level of quality at the outset
 A solution has to be “good enough”
 Right-engineering (no under-engineering or over-engineering)
 Ensure quality does not become a variable
 Design, document and test appropriately and continuously
 Test early and continuously - ”fail fast, learn fast”
 Build in quality by constant review with the right people
 Roles: Solution Tester
 Products: Testing products
 Techniques: MoSCoW, Timeboxing, Daily Stand-ups
 Early and integrated testing
21 - 22M02 - AgilePM philosophy and principles 15/39 | 53/270

“The increment must
be completed,
meaning the
increment must be a
complete piece of
usable software.”
K. Schwaber,
J. Sutherland

 Requires teams to
 Build complete, small chunks (increments) from firm foundations
 Strive for early delivery of business benefit where possible
 Incremental delivery (of value to production/live environment)
 Continually confirm correct solution is being built
 Incremental delivery encourages stakeholder confidence,
offering a source of feedback for use in subsequent Timeboxes
 Formally re-assess priorities and ongoing project viability
 The DSDM Lifecycle phases
 Solid base of knowledge during Feasibility and Foundations
 Incremental development through Evolutionary Development
 Incremental deployment through Deploy

Functional
Usable
Secure
Fast
Minimum Viable Product
(a.k.a. potential shippable product)
Not MVP
MVP
Functional
Usable
Secure
Fast

“People don’t know
what they want until
you show it to them.”
Steve Jobs

 Nothing built perfectly 1st time
 Requires team to
 Do enough design up front (EDUF) to create strong foundations
 Build products using an iterative approach
 Build customer feedback into each iteration
 Accept that most detail emerges later rather than sooner
 Embrace change - the right solution will not evolve without it
 Change is inevitable, allow for it and harness its benefits
 Be creative, experiment, learn, evolve
 Iteration and constant review (client and user)
 Ensures the evolving solution aligns with what business really needs

“Electric communication
will never be a substitute
for the face of someone
who with their soul
encourages another
person to be brave and
true.”
Charles Dickens

 Requires to
 Use “rich visual communication” like modelling, prototyping
 e.g. (less formal) UI prototyping, mockups, mind maps, …
 e.g. (more formal) UML / SysML, BPMN, OBASHI, Archimate, …
 Present iterations of evolving solution early and often
 Keep documentation lean and timely
 Encourage informal, face-to-face communication at all levels
 Techniques: Facilitated workshops, Daily Stand-ups
 Clearly defined roles
 Constant user involvement and empowerment
 Models and prototypes

“The company owner
doesn't need to win.
The best idea does.”
John C. Maxwell

 In many environments it is not enough simply to be in
control, it needs to be able to prove it
 Requires to
 Use appropriate level of formality for tracking and reporting
 Make plans and progress visible to all stakeholders
 Measured progress through delivery of products
 Manage proactively (management by exception)
 Continuously evaluate project viability based on business
objectives
 Roles: Project Manager, Team Leader
 Techniques: Timeboxing
 Products: Management Foundations, Timebox Plans

 It is vital that stakeholders buy in to the Philosophy. They will get a
working solution on the agreed date, but they should not expect a
100% solution. As stakeholders, they are able to drive what is
important, so they will get what the business needs
 Be open and clear about the Philosophy and the way Atern delivers
right from the start. Be prepared for stakeholders initial concerns
„So at the start you can't tell me exactly what I'll get at the end?”.
 In Atern projects, the majority of the negotiation is around the fine detail, not
the major headlines
 Treat non-adherence to the principles as a risk
 Breaking any of the principles will be a significant risk to the success of the agile
process and the success of the project
 Discuss the Principles openly with the project team at the
start of the project and ensure everyone buys into them
18, 24M02 - AgilePM philosophy and principles 25/39 | 63/270

Agile to be successful requires _____?
a) on time delivery, according to business priorities
b) collaboration to deliver the right solution
c) acceptance that change is inevitable
d) key stakeholder understanding of business objectives

Which are characteristics of Self Directed Teams (Agile)?
a) Comply with processes, regardless of outcome
b) Compete
c) Continuously look for better ways of working
d) Focus on low-level objectives

Which is an AgilePM principle?
a) Focus on Benefits
b) Test Continuously
c) Clarify and Refine
d) Never Compromise Quality

How Agile is managing Change Management?
a) Baseline prototype, at least at the end of Development
Timebox
b) Manage change in every element in project
c) Change is not recommended
d) Few, or even no baselines

What Agile state as 4 project parameters?
a) Time, cost, quality and benefits
b) Time, facilities, results, benefits
c) Cost, quality, time, features
d) Quantity, time, cost, future

Self Directed Teams (Agile) _____.
a) take initiative
b) co-operate
c) continuously look for better ways of working
d) comply with processes, regardless of outcome

Which of these is an AgilePM principle?
a) Communicate often
b) Communicate Verbally
c) Communicate Formally
d) Communicate Continuously and Clearly

On of characteristics of Agile Project Management is_____.
a) similar style of management like traditional
b) strictly adhering to project plan
c) measured by delivery of products (not by activity)
d) measured by project plan progress

Self Directed Teams (Agile) _____.
a) take initiative
b) co-operate
c) continuously look for better ways of working
d) comply with processes, regardless of outcome

Agile Project Management _____.
a) keeps teams on track
b) sets team objectives, then lets them get on with it
c) sustains team culture and morale
d) manages business involvement with team

I hope you enjoyed
this presentation. If so,
please like, share and
leave a comment
below.
Endorsements on
LinkedIn are also
highly appreciated! 
(your feedback = more free stuff)

MIROSLAWDABROWSKI.COM/downloads

AgilePM® - Agile Project Management - Foundation

Related slideshows

More Related Content

AgilePM® - Agile Project Management - Foundation