1Agile Project Management

You, yes you,

please write at least one

Question, Concern or Topic of Interest

and place it on the wall chart.

To answer today

Agile Project Management

Andrew RuslingAgile Coach2014@andrewrusling

3Administration

• Fire escape

• Toilets

• Breaks – A couple of very short breaks (no checking work e-mails)

• Lunch

• Slides >>>

4Contents

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

5Competencies 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

6Competencies 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

7

The agile Manifesto

agile Manifesto value statement

Process and toolsIndividuals and

interactionsover

Following a planResponding to

changeover

Comprehensive documentation

Working software over

Contract negotiationCustomer

collaborationover

Full Manifesto: http://agilemanifesto.org/

9Agile manifesto

• How does PM relate to this value statement?

• What is the impact of common sense?

Process and toolsIndividuals and

interactionsover

10Agile manifesto

• How does PM relate to this value statement?

• Why do we put so much effort into Requirements, etc?

Comprehensive documentation

Working software over

11Agile Manifesto

• How does PM relate to this value statement?

• Why is contract negotiation slow?

Contract negotiationCustomer

collaborationover

12Agile Manifesto

• How does PM relate to this value statement?

• What are the basic questions management always ask?

Following a planResponding to

changeover

13Agile 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.

14Agile 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.

15

Declaration of Interdependence

16Completing 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

17Declaration 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.

18Interdependence

Team members are interdependent

19Interdependence

Customers

Team

Stakeholders

Are all interdependent, if we want to succeed

20

Project Manager Role

21Project Management in agile

It is not explicitly mentioned

22Project Management in Scrum

Project Management

Responsibilities

Team

Product Owner

Scrum Master

Project Manager

23Responsibilities 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

Team Servant LeaderProduct Owner Project Manager

24Project 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

25Project Manager working in Agile

Still involves:

• Stakeholder Management

• Reporting, especially upwards

• Budget control

26Focus 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•Align team goals•Inspire & support servant leaders•Stakeholder management•Report project status•Assist resolving cross team issues

27Three agile teams, an example (no PM)

Team Team

Product Owner

Scrum Master

Team

Scrum Master Scrum Master

28Three agile teams, an example (with APM)

Team Team

Product Owner

Team

AgileProject

Manager

29Lots of teams, an example

Head Product Owner

AgileProject

Manager

Team

SM

Team

Team

SM

TeamTeam

SM

Team

Team

SM

TeamTeam

SM

Team

PO PO

30

Achieving the

agile Value Proposition

31Agile value propositionB

usin

ess

Val

ueR

isk

Ada

ptab

ility

Vis

ibili

ty

Time

Time

Time

Time

32Reducing risk early

• Working Software

• Retrospectives

• Short Cycles

• Disciplined Knowledge Acquisition

Ris

k

Time

33Delivering 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)

34Retrospectives

Regular Retrospectives uncover several types of risks early:

• Project

• Team / People

• Technology

• Tools

35Short Cycles / Iterations / Sprints

They enforce

• Fast delivery of Working Software

• Frequent Retrospectives

• Frequent Re-Planning and Adaptation

Hence find and address issues early.

36Disciplined Knowledge Acquisition

Time

Project Spend

Business Value

Knowledge,Risk Reduction

Value

ROI / when to stop

Story

Spike

37‘Holiday Planner’ Backlog Prioritisation - Exercise

https://www.flickr.com/photos/navaneethkn/

https://www.flickr.com/photos/quinet/ https://www.flickr.com/photos/photographerglen

https://www.flickr.com/photos/lendog64/

38Delivering business value early

• Working Software

• Agile Iron Triangle

• Disciplined Knowledge Acquisition

• Effective User Stories

• Daily business involvement

Bus

ines

s V

alue

Time

39Delivering 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

Traditional Iron Triangle

Effort Schedule

Scope

Constraints

Agile Iron Triangle

Value (Releasable Features, Usability)

(aka Extrinsic quality)

Aspects(Reliable, Adaptable Product)

(aka Intrinsic quality)

Constraints(Scope, Effort, Schedule)

42Disciplined Knowledge Acquisition

Time

Project Spend

Business Value

Knowledge,Risk Reduction

Value

ROI / when to stop

Story

Spike

43Effective User Stories

INVEST• Independent• Negotiable• Valuable• Estimatable• Small• Testable

44Maintain high visibility

• Working Software

• Daily business involvement

• Effective communication

Vis

ibili

ty

Time

Delivering Working Software, shows real status

• We do the Hard stuff first

• Can look worse then ‘Traditional’, e.g.

46Expected Team to PM communications

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

47Communication Channels - Exercise

Accuracy & Effectiveness

?

Cost to project

48Maintaining good adaptability

• Technical Practices

• Definition of Done

• Manage Technical Debt

Ada

ptab

ility

Time

49Technical 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

50Definitions of Done

• Prevents the build up on undone work

• Can be multi level, i.e.• User Story DOD

• Feature DOD

• Release DOD

51Managing Technical Debt

• Stop digging!

• Have a publicly stated management plan

• Identify any existing or new debt

• Make conscious decisions

52DOI mapped to Agile Value Proposition

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

53DOI mapped to Agile Value Proposition

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

Dependencies

55Dependencies kill agility

Dependencies

Agility

• Why is this the case?• What can we do about it?

56More teams, potentially more dependencies

3 Teams3 relationships that may have dependencies

5 Teams10 relationships that may have dependencies

57Minimising 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.

58Managing 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

59Scrum 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.

Scrum of Scrums

Daily Scrums

60Release Planning Board

www.journey-to-better.com provided with permission

61

Reporting

on an agile project

62Same 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?

63Completely different direct questions

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?

64Different sources for answers

• Sprint Review

• Team task board

• Sprint burn charts

• Project burn charts

• Feature charts

• User story map

65Reporting - 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

66Reporting - 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

67Reporting - 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.

68Project Burn up – predicting completion date

Story Points

Scope

Done

Time

69Reporting - Feature charts

• Show progress on Feature by Feature basis

• Combined with a Project Burn Up provide a great overview of a project

Feature A Feature B

Feature C Feature D

Feature A Feature B

Feature C Feature D

70Reporting - User Story Map

Can track progress, by marking off User Story completion

71

Summary

72Summary

73Summary

74Summary

75Competencies

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

76Competencies, 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

77Time to share

1 - 3 Key Learning Points

One person at a time

Your answers don’t have to be unique

https://www.flickr.com/photos/kellysue/

78

Reference Material

79Books of interest

80Links

• Declaration of Interdependence

• Servant Leadership

• Disciplined Knowledge Acquisition

• Agile Iron Triangle

• Evolution to an Agile Triangle