Agile Project Management explained and examined from several angles. Agile Software Development delivers better results when it is managed in an agile way.

1. Agile Project Management
You, yes you,
please write at least one
Question, Concern or Topic of Interest
and place it on the wall chart.
1
To answer today

2. Agile Project Management
Andrew Rusling
Agile Coach
2014
@andrewrusling

3. Administration
• Fire escape
• Toilets
• Breaks – A couple of very short breaks (no checking work e-mails)
• Lunch
• Slides >>>
3

4. Contents
1. The agile Manifesto
2. Declaration of Interdependence
3. Project Manager Role
4. Achieving the agile value proposition
5. Dependencies
6. Reporting on an agile project
4

5. Competencies to be gained
By the end of this session, I am hopeful that you will be able to:
1. Describe how the agile manifesto relates to project management
2. Summarise the agile value proposition
3. List several elements in agile that help to deliver the agile value
proposition
4. Describe the Declaration of Interdependence (DOI)
5. Summarise how the DOI helps to deliver the agile value proposition
6. Contrast the difference between the PM role in traditional vs agile
methodologies
7. Describe who is responsible for Project Management in Scrum
8. Summarise how the PM role changes in agile as Scale is introduced
9. Summarise the Disciplined Knowledge Acquisition approach
10. Prioritise a backlog by both value and risk
5

6. Competencies to be gained, continued
By the end of this session, I am hopeful that you will be able to:
11. Contrast the Traditional and Agile Iron Triangles
12. List several communication channels used in agile projects
13. Summarise the relationship between agility and dependencies
14. List several agile approaches for managing dependencies
15. Summarise queuing theory
16. List several approaches in queuing theory that benefit agile projects
17. Summarise the relationship between utilisation and throughput
18. List several traditional sources that are not useful for agile projects
19. List several sources that are useful and effective for agile reporting
6

7. 7
The agile Manifesto

8. agile Manifesto value statement
Process and tools
Individuals and
interactions
over
Following a plan
Responding to
change
over
Comprehensive
documentation
Working software over
Contract negotiation
Customer
collaboration
over
Full Manifesto: http://agilemanifesto.org/

9. Agile manifesto
• How does PM relate to this value statement?
• What is the impact of common sense?
9
Process and tools
Individuals and
interactions
over

10. Agile manifesto
• How does PM relate to this value statement?
• Why do we put so much effort into Requirements, etc?
10
Comprehensive
documentation
Working software over

11. Agile Manifesto
• How does PM relate to this value statement?
• Why is contract negotiation slow?
11
Contract negotiation
Customer
collaboration
over

12. Agile Manifesto
• How does PM relate to this value statement?
• What are the basic questions management always ask?
12
Following a plan
Responding to
change
over

13. Agile manifesto – principles 1 to 6
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive
advantage.
3. Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily
throughout the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done.
6. The most efficient and effective method of conveying information to
and within a development team is face-to-face conversation.
13

14. Agile manifesto – principles 7 to 12
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence and good design
enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is
essential.
11. The best architectures, requirements, and designs emerge from self-organizing
teams.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behaviour accordingly.
14

15. 15
Declaration of
Interdependence

16. Completing the Declaration of Interdependence
1. Tear off the actions from the bottom of the page
2. Match the actions up to the outcomes
3. We will discuss the results
16

17. Declaration of Interdependence
Agile and adaptive approaches for linking people, projects and value
We are a community of project leaders that are highly successful at delivering results.
To achieve these results:
• We increase return on investment by making continuous flow of value our focus.
• We deliver reliable results by engaging customers in frequent interactions and
shared ownership.
• We expect uncertainty and manage for it through iterations, anticipation, and
adaptation.
• We unleash creativity and innovation by recognizing that individuals are the
ultimate source of value, and creating an environment where they can make a
difference.
• We boost performance through group accountability for results and shared
responsibility for team effectiveness.
• We improve effectiveness and reliability through situationally specific strategies,
processes and practices.
17

18. Interdependence 18
Team members are interdependent

19. Interdependence 19
Customers
Team
Stakeholders
Are all interdependent, if we want to succeed

20. 20
Project Manager Role

21. Project Management in agile
It is not explicitly mentioned
21

22. Project Management in Scrum 22
Project
Management
Responsibilities
Team
Product
Owner
Scrum Master
Project
Manager

23. Responsibilities in agile - exercise
Aim: allocate responsibilities to roles in an agile environment
Step 1: Shuffle responsibilities cards and distribute amongst yourselves
Step 2: In silence, place your cards under the role that is primarily
responsible.
Step 3: In silence, move your teams cards if you disagree.
Step 4: Discuss all placements as a group
23
Product Owner Team Servant Leader Project Manager

24. Project Manager working in Agile
Shift of focus, Command & Control to Servant Leadership:
• Push responsibility down
• Establish clear expectations and boundaries
• Ask, don’t tell
• Inspire and support
• Set clear elevating goals
• Early involvement in key decisions
• Resolve impediments as a priority
• Visual progress
• Long & medium term goals
• In very public places
• Very transparent
24

25. Project Manager working in Agile
Still involves:
• Stakeholder Management
• Reporting, especially upwards
• Budget control
25

26. Focus changes with Scale
1-3 Teams
• Servant Leader for
team(s)
• Inspire & support
team(s)
• Stakeholder
management
• Report team & project
status
• Resolve cross team
issues
4+ Teams
26
• Align team goals
• Inspire & support servant
leaders
• Stakeholder
management
• Report project status
• Assist resolving cross
team issues

27. Three agile teams, an example (no PM) 27
Scrum Master Scrum Master
Team Team
Product
Owner
Scrum Master
Team

28. Three agile teams, an example (with APM) 28
Team Team
Product
Owner
Team
Agile
Project
Manager

29. Lots of teams, an example 29
Head Product
Owner
Agile
Project
Manager
Team
SM
Team
Team
PO PO
SM
Team
Team
SM
Team
Team
SM
SM
Team Team
Team

30. 30
Achieving the
agile Value Proposition

31. Agile value proposition 31
Risk Business Value
Adaptability Visibility
Time
Time
Time
Time

32. Reducing risk early
32
• Working Software
• Retrospectives
• Short Cycles
• Disciplined Knowledge Acquisition
Risk
Time

33. Delivering Working Software reduces risk
Find issues early via:
• Testing, especially these types of tests
• Integration & System
• User & Acceptance
• Performance
• Scalability
• Business review of working software
• Deployment (aka the last mile)
33

34. Retrospectives
Regular Retrospectives uncover several types of risks early:
• Project
• Team / People
• Technology
• Tools
34

35. Short Cycles / Iterations / Sprints
They enforce
• Fast delivery of Working Software
• Frequent Retrospectives
• Frequent Re-Planning and Adaptation
Hence find and address issues early.
35

36. Disciplined Knowledge Acquisition 36
Project
Spend
Time
Business Value
Knowledge,
Risk Reduction
Value
ROI / when to stop
Story
Spike

37. ‘Holiday Planner’ Backlog Prioritisation - Exercise37
https://www.flickr.com/photos/navaneethkn/
https://www.flickr.com/photos/lendog64/
https://www.flickr.com/photos/quinet/ https://www.flickr.com/photos/photographerglen

38. Delivering business value early
38
• Working Software
• Agile Iron Triangle
• Disciplined Knowledge Acquisition
• Effective User Stories
• Daily business involvement
Business Value
Time

39. Delivering Working Software
• Requirements documents are not value
• Design documents and model are not value
• Architecture is not value
• Code is not value
• Tested code is not value
• Working Software is value
39

40. Traditional Iron Triangle
Scope
Effort Schedule
Constraints

41. Agile Iron Triangle
Value
(Releasable Features, Usability)
(aka Extrinsic quality)
Aspects
(Reliable, Adaptable Product)
(aka Intrinsic quality)
Constraints
(Scope, Effort, Schedule)

42. Disciplined Knowledge Acquisition 42
Project
Spend
Time
Business Value
Knowledge,
Risk Reduction
Value
ROI / when to stop
Story
Spike

43. Effective User Stories 43
INVEST
• Independent
• Negotiable
• Valuable
• Estimatable
• Small
• Testable

44. Maintain high visibility
• Working Software
• Daily business involvement
• Effective communication
44
Visibility
Time

45. Delivering Working Software, shows real status
• We do the Hard stuff first
• Can look worse then ‘Traditional’, e.g.

46. Expected Team to PM communications 46
Agile Project
Manager
Team(s)
• Expected & Actual Velocity
• Team Risks & Issues
• Cross team Dependencies
• Cross team Risks & Issues
• Resources to acquire
• Medium & Long term goals
• Expectations of teams/project
• Project Status
• Project Risks & Issues
• Resourcing status

47. Communication Channels - Exercise 47
Accuracy &
Effectiveness
?
Cost to project

48. Maintaining good adaptability
• Technical Practices
• Definition of Done
• Manage Technical Debt
48
Adaptability
Time

49. Technical Practices
• Version Control
• Coding Standards
• Peer Reviews of code, tests, documents, etc.
• Pair Programming
• Simple Design, Just in-time Design
• Evolutionary Architecture
• Continuous Design/UX
• Test Driven Development
• Automated Acceptance Testing
• Continuous Integration, Continuous Deployment
• Continuous Delivery
49

50. Definitions of Done
• Prevents the build up on undone work
• Can be multi level, i.e.
• User Story DOD
• Feature DOD
• Release DOD
50

51. Managing Technical Debt
• Stop digging!
• Have a publicly stated management plan
• Identify any existing or new debt
• Make conscious decisions
51

52. DOI mapped to Agile Value Proposition 52
DOI Statement Helps to deliver
We increase return on investment by
making continuous flow of value our
focus
We deliver reliable results by
engaging customers in frequent
interactions and shared ownership
We expect uncertainty and manage
for it through iterations, anticipation,
and adaptation

53. DOI mapped to Agile Value Proposition 53
DOI Statement Helps to deliver
We unleash creativity and innovation
by recognizing that individuals are the
ultimate source of value, and creating
an environment where they can make a
difference
We boost performance through group
accountability for results and shared
responsibility for team effectiveness
We improve effectiveness and
reliability through situationally specific
strategies, processes and practices.

54. 54
Dependencies

55. Dependencies kill agility 55
Dependencies
Agility
• Why is this the case?
• What can we do about it?

56. More teams, potentially more dependencies 56
3 Teams
3 relationships that may
have dependencies
5 Teams
10 relationships that
may have dependencies

57. Minimising inter team dependencies
• Should be a focus of “Management”, including APM.
• Should be a focus on Product Owner(s)
• Avoid Component Teams
• i.e. GUI team, Middleware team, etc.
• Structure Teams by decoupled business areas
• i.e. Customer Acquisition, Payments, Single Player, Tournaments, etc.
57

58. Managing Dependencies
• It is minimisation, not avoidance, some will occur.
• Set expectations that teams should manage their own dependencies.
• Approaches that can help:
• Decouple software and work to interfaces
• Scrum of Scrums
• Release / multi team planning boards
58

59. Scrum of Scrums
1 or 2 relevant* team members from each team, attend the S.O.S.
The relevance of any attendee changes, with the work of the team and
their dependencies on other teams.
59
Scrum of Scrums
Daily Scrums

60. Release Planning Board 60
www.journey-to-better.com provided with permission

61. 61
Reporting
on an agile project

62. Same high level questions
1. When will the project be complete?
2. What will the project deliver?
3. Is the budget on track?
4. Do we have enough of the right resources?
5. What can we do to help the project succeed?
• i.e. What risks & issues exist, will resolving them help us?
62

63. Completely different direct questions 63
When will the project be complete?
• When will Bob finish the code for the Widget?
• Mr Architect is the XYZ task dependent on the ABC task?
• Can we cancel Sally’s holidays to get her to finish the Design?
What will the project deliver?
• Has the requirements specification been reviewed and signed off?
• Will the Forgot your password, make you answer all of your secret
questions or just a couple of them?

64. Different sources for answers
• Sprint Review
• Team task board
• Sprint burn charts
• Project burn charts
• Feature charts
• User story map
64

65. Reporting - Team task board
Team task boards provide lots of information:
• Sprint progress
• Impediments (issues holding up the team)
• Bottlenecks
• Over/under utilisation of people
• Risks
• Dependencies
65

66. Reporting - Sprint burn charts
• Burn down in hours
• Aim: track progress of combined sprint backlog
• Burn up to limit in hours
• Aim: help to balance delivery of value to progressing background tasks
• Burn down in story points
• Aim: track progress of delivering value (User Stories to done)
• Can highlight process issues
66

67. Reporting - Project burn charts
• Burn down in story points
• Aim: Track predicted end date
• Shows difference between To Do and Done as a single line
• Burn up in story points, with scope line
• Aim: Track predicted end date
• Shows Done and To Do as separate lines
• Hence showing the impact of Velocity (Done) changes and To Do changes separately.
67

68. Project Burn up – predicting completion date 68
Story Points
Scope
Done
Time

69. Reporting - Feature charts
69
Feature A Feature B
Feature C Feature D
Feature A Feature B
Feature C Feature D
• Show progress on Feature by Feature basis
• Combined with a Project Burn Up provide a great overview of a project

70. Reporting - User Story Map
Can track progress, by marking off User Story completion
70

71. 71
Summary

72. Summary 72

73. Summary 73

74. Summary 74

75. Competencies
I am hopeful that you now can:
1. Describe how the agile manifesto relates to project management
2. Summarise the agile value proposition
3. List several elements in agile that help to deliver the agile value
proposition
4. Describe the Declaration of Interdependence (DOI)
5. Summarise how the DOI helps to deliver the agile value proposition
6. Contrast the difference between the PM role in traditional vs agile
methodologies
7. Describe who is responsible for Project Management in Scrum
8. Summarise how the PM role changes in agile as Scale is introduced
9. Summarise the Disciplined Knowledge Acquisition approach
10. Prioritise a backlog by both value and risk
75

76. Competencies, continued
I am hopeful that you now can:
11. Contrast the Traditional and Agile Iron Triangles
12. List several communication channels used in agile projects
13. Summarise the relationship between agility and dependencies
14. List several agile approaches for managing dependencies
15. Summarise queuing theory
16. List several approaches in queuing theory that benefit agile projects
17. Summarise the relationship between utilisation and throughput
18. List several traditional sources that are not useful for agile projects
19. List several sources that are useful and effective for agile reporting
76

77. Time to share
1 - 3
Key Learning Points
One person at a time
Your answers don’t have to
be unique
77
https://www.flickr.com/photos/kellysue/

78. 78
Reference Material

79. Books of interest 79

80. Links
• Declaration of Interdependence
• Servant Leadership
• Disciplined Knowledge Acquisition
• Agile Iron Triangle
• Evolution to an Agile Triangle
80