An introduction to Agile PM and how to choose.

1. AGILE
… but far from every time

2. WHO AM I?
Johnny H.G. Ryser
Vice President, Partner
MBA, MA Industrial IT, Prod. Eng.
+45 87 38 74 50
+45 27 62 99 06
jry@d-i-s.dk
20 Years proffesional PM Experience
IT
Media
Automotive
Windpower
Engineering
Mission:
To help people release their highest
potential

3. HAVE YOU ANY EXPERIENCE WITH
WEBINARS?

4. INTRODUCTION TO OUR WEBINAR TECHNOLOGY

5. So what is Agile PM?

6. What experience do
You have in agile?

7. Lets get the why and the
priorities right, before we
go further down the
road…

8. THE BASIC STAGES OF A PROJECT
Idea Planning
Imple-
mentation
Operation
Project leadership (doing it right)
Project management (doing the right things)

9. AN AGILE VERSION
Project leadership(do it right)
Project management(do the right things)
Imple-
mentat
ion
Operation
Plan-
ning
Imple-
mentat
ion
Operation
Plan-
ning
Imple-
mentat
ion
Operation
Plan-
ning
Idea

10. EFFECT FOCUS
PURPOSE:
RESSOURCES
WHY?
DELIVERABLES
OUTCOME:
Productivity
Efficiency
WITH WHICH
RESSOURCES?
HOW & WHAT?
Succes Crit. (SMART)
If the deliverables are
the answers, what
was the question?
WHAT HAS
CHANGED AFTER
THE PROJECT?
Succes Crit (SMART)

11. EFFECT FOCUS
PURPOSE:
RESSOURCES
WHY?
DELIVERABLES
OUTCOME:
Productivity
Efficiency
WITH WHICH
RESSOURCES?
HOW & WHAT?
Succes Crit. (SMART)
If the deliverables are
the answers, what
was the question?
WHAT HAS
CHANGED AFTER
THE PROJECT?
Succes Crit (SMART)
Strong or
weak
connection

12. CRITICAL SUCCESS CRITERIA FOR A PROJECT:
1.
2.
3.
4.
5.
6.
Please help me brainstorm
in the chat 

13. CRITICAL SUCCESS CRITERIA FOR A PROJECT:
1. The project manager
2. The project team
3. Strong commitment from project sponsor
4. Early involvement of stakeholders
5. Stakeholder endorsement of project plans
6. Ample communication

14. CRITICAL SUCCESS CRITERIA FOR A TEAM:
1. Communication
2. Coordination of tasks
3. Balance of individual contributions
4. One for all, all for one
5. Effort
6. Cohesion

15. SO THESE CRITICAL SUCCESFACTORS ARE GLOBAL!

16. LETS GO A
LITTLE DEEPER

17. Both paradigms has their
home grounds
THOUGHTS ON AGILE AND PLANDRIVEN
The agile
paradigm
The plandriven
paradigm
Shop floor management
(Kanban, stand ups, close
collaboration with the customer,
usecases ,WBS, Ganntt, critical
path, Change Management etc)

18. THE AGILE MANIFESTO
Project
People
Proces
Product

19. HOW TO CHOOSE?
PEOPLE
DYNAMICS
CULTURE
SIZE
RISKS

20. PEOPLE – COCKBURN MODEL
•Able to revise a method (break its rules) to fit an
unprecedented new situationLevel 3
•Able to tailor a method to fit a precedented new situation
Level 2
•With training, able to perform discretionary method steps
(e.g., sizing stories to fit increments, composing patterns,
compound refactoring, complex COTS integration).Level 1A
•With training, able to perform procedural method steps
(e.g. coding a simple method, simple refactoring, following
coding standards and CM procedures, running tests)Level 1B
•May have technical skills, but unable or unwilling to
collaborate or follow shared methods.Level -1

21. PERSONNEL
Agile
Plandriven
0 10 20 30
40 % Level
1B
35 30 25 20
15
% Level 2 &
3

22. 50 30 10 5 1
DYNAMICS
Agile
Plandriven
% Requirement changes/mdr.

23. CULTURE (EX. HOFSTEDE)
Agile culture
(Self controlling)
”Chaos”
Plandriven culture
(Clear politics &
procedures)
”Order”

24. SIZE
Agile:
1-30 (100) participants
Plandriven:
30+ participants

25. Comfort Risik for Risks for Single life Many
minor values greate values lives
RISKS (COCKBURN MODEL)
Agile
Plandriven
Criticality

26. CHOICE OF METHOD
Source: ”Balancing agility and discipline”

27. RISKS
Environmental risks
•E-Tech:
Technology uncertainties
•E-Coord
Many diverse stakeholders to
coordinate
•E-Cmlpx
Complex system of systems
Agile Risks
• A-Scale
Scalability and criticality
• A-YAGNI
Use of simple design or YAGNI
•A-Churn
Personel turnover
•A-Skill
Not enough people skilled in agile
methods
Plan-driven risks
•P-change
Rapid change
•P-speed
Need for rapid results
•P-emerge
Emergent requirements
•P-Skill
Not enough people skilled in
plan-driven methods

28. TECHNOLOGY RISKS
Tekniske risici
28
Extremely
high risks
Game
changing
technology
Høj High risk –
much energy
needed to
implement
imature
technologies
Middle to high
risk.
Best practices are
available
Known technology
in new products
Middle to low risk
Main stream
technologies
Low risk

29. RISK BASED TAILORING
Step 5.
Execute and Monitor
Step 4.
Tailor Life Cycle
Step 3.
Architecture
Analysis
Step 1.
Risk Analysis
Step 2.
Risk
Comparison
Rate the project’s
environmental, agility-
oriented and plan-driven
risks.
Uncertain
about
ratings?
Buy information via
prototyping, data
collection and analysis
Compare
the agile
and Plan-
driven risks
Go Risk-based
Agile
Agility risks
dominate
Plan-driven risks
dominate
Architect application to
encapsulate agile parts
Go Risk-based
Agile in agile
parts; Go Risk-
based Plan-
driven elsewhere
Yes
No
Go Risk-based
Plan-driven
Tailor life cycle process
around anchor point
commitment milestones
Monitor progress and
risks/opportunities,
readjust balance and
process as appropriate
Neither dominate
Deliver incremental
capabilities according to
strategy
Note: Feedback
loops present,
but omitted for
simplicity

30. RISK BASED TAYLORINGVery
Seriousrisks
Manageable
risiks

31. Some battle field
reflections

32. Timeboxing
Good relationship
customer/supplier
Sitting together
(same time, but evt.
virtual)
MuScCoW prioritation
Very competent
engineers
VERY IMPORTANT PREREQUISITES

33. An Agile Project Plan
TIMEBOX 0
TIMEBOX 1
TIMEBOX 2
TIMEBOX 3
TIMEBOX 4
TIMEBOX 5
Feature1
Explore &
Engineer
Feature 2
Explore &
Engineer
& Deploy
Feature 3
Explore &
Engineer
Feature 4
Explore &
Engineer
Integrate &
Test Features
1,2,3,4
Together
& Deploy Review
Explore
Requirements
further
and Model
Delivery
To Live
Feature 1
Done &
Tested
Features
1 & 2
Done &
Tested
Prototype
Solution
Feas
Delivery
Delivery
To Live
DeliveryDelivery
Increment 2Increment 1
Feasib
-ility
Found
-ations
Foundations
PRL
Feature 1 M
---
---
Feature 2 M
---
Feature 3 M
----
Feature 4 S
---
Review
Deployment 1&2 Deployment 3 &4
Example

34. • No projects will be either/or
• Projects may change during the execution
• There may be workpackages that are developed agile and plandriven in the same
project, either simultaneously or sequentially
• Combination of hardware development and software development may need a
combination of methods
• The critical factors are equally important:
REFLECTIONS