Agile project management

Click to edit Master title style

Click to edit Master subtitle style

www.teamprosource.eu

Agile Project Management

Best of both worlds ?

[email protected]

© 2011 TeamProsource22

A competence improvement platform, including public training, in-company training programmes, and coaching

Flexible staffing of highly skilled resources with quality guarantee

360°diagnostic andimprovement to accelerate

the flow of projects and services

Prosource services


CLICK TO EDIT MASTER TITLE STYLE

Click to edit Master text styles

CAN WE COMBINE

PLAN-DRIVEN PROJECT MANAGEMENT

WITH

AGILE EXECUTION ?


The PMBOK/PRINCE2 view on project planning

Henrik Kniberg

Assumptions:

• The customer knows what he wants

• The developers know how to build it

• Nothing will change along the way

SW projects are like a cannon ball shot

Realistic?


The Agile view on project planning

Henrik Kniberg

Assumptions:

The customer discovers what he wants

The developers discover how to build it

Things change along the way

Product

vision

SW projects are like homing missiles

Realistic?


Content of presentation

• Plan-driven versus agile project management

• How to initiate agile projects?

• How to monitor & control agile projects?

• Roles and responsibilities revisited

• PMBOK knowledge area’s revisited

Can we combine best of both worlds?


Plan-driven versus agile

project management

Plan-driven > predictability Agile > flexibility

Source: David Rico

“plan the work, and work the plan” “empower teams to deliver business value”


Agile manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

8

What are the agile principles?

While there is value in the items on the right,

we value the items on the left more.


Scrum roles


Scrum process

Title Presentation | Version x.x

Timeboxed product delivery


Scrum process



Choosing between plan-driven and agile

Plan-driven Indicators Agile

Solution delivery Type of project Experimental discovery

Multiple interdependencies & interface complexity Few interdependencies

Regulated (pharma) Regulatory context Unregulated

Fixed or quite certain Scope Dynamic & Uncertain

Passive or unavailable Stakeholders Ongoing involvement

All or nothing Value creation incremental ROI

Big bang Delivery incremental (small steps)

Distributed & fluctuating Team Collocated & stable

Command & control or micromanagement Company culture Empowerment & self management


Some criteria to select the most effective approach

Problem

The assessment is

seldom clearcut


Agile project management


Combining project governance with agile development (example)


CLICK TO EDIT MASTER TITLE STYLE

Click to edit Master text styles

AGILE VERSUS PLAN-DRIVEN PROJECT MANAGEMENT

The paradigm shift


Plan-driven versus Agile triple constraint



• Agile focuses on delivering

value increments


Flexible scope


Flexible scope

Agile focuses on delivering value increments

20Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

Always

7%

Often

13%

Sometimes

16%Rarely

19%

Never

45%

Rarely or Never

Used: 64%

Often or Always

Used: 20%

Delivering value is hard…..


Flexible scope

• Agile focuses on delivering

value increments

• Contingency will be

represented by scope rather

than resources/time

• Scope will not be fixed

upfront but contineously re-

prioritised



• Cost and benefits are based on best case and worst case scenario

• Scope contingency (shouid and could have’s) will cover uncertainty risk

Flexible scope

Product scope (solution) will not be fixed but prioritised (MoSCoW)


• When a project is behind, stakeholders

can cut the lowest priority features to

insure that the most important items

are delivered within the cost/schedule

• At the end the stakeholders can decide

if they want to spend extra

cost/schedule for the remaining lower

value features

Flexible scope


Scope will not be fixed upfront but continously re-prioritised


• Delivery stages are timeboxed

• Each timebox combines incremental

with iterative delivery of the

product scope

Fixed time


Focus on meeting deadlines


Incremental delivery

Early delivery of business benefit where possible (= incremental)

Incremental delivery enables early

Return on Investment (ROI)• Continually confirm correct solution is

being built

• Formally re-assess priorities and ongoing

project viability with each delivered

increment


Iterative delivery

Planned rework strategy allows team to converge to an accurate solution

• Iterative delivery builds customer

feedback into each iteration• Acknowledge that things may get

wrong before getting right

• Accept that most details emerge later

rather than sooner

• Embrace change – the right solution

will not evolve without it

• Sometimes difficult to determine

upfront how many improvement

passes will be needed


Agile delivery

Agile combining iterative & incremental

Agile teams combine the Iterative and Incremental approaches. • Each iteration will produce a product Increment adding completely new features (= Incremental).

• But each Increment is also likely to refine already existing functionality (= iterative)


• As the team members go through the

“must have” list of features they can

estimate how many sprints (iterations)

they will need to complete the project

Fixed costs


Fixed cost per iteration


• Initial Rough Order of Magnitude

estimate (ROM)• At the beginning of the project the

accuracy may be +/- 50%.

• The risks of more iterations to be

added later on should be

acknowledged

Fixed costs

Upfront estimation of agile projects


• As the team members go through the

“must have” list of features they can

estimate how many sprints (iterations)

they will need to complete the project

• They can calculate the best and worst

case cost as the number of resources

multiplied by the number of iterations

• A cost buffer is advisable when there is

a risk of more iterations than originally

planned.

Fixed costs


Fixed cost per iteration


50

100

150

200

250

Pessimist

OptimistWishful

thinking

Q1 ! ! !Q1 ! ! !

! Q2 ! ! ! ! Q3 ! ! ! ! Q4 ! ! ! ! Q2

Promised release Likely

release

De

live

red

sto

ry p

oin

ts

Fixed scope

Fixed costs

Henrik Kniberg

Estimate the velocity upfront and visualize the level of uncertainty

Estimated Velocity = 10 points/iteration

Backlog = 250 points25 iterations > 1 year until release!


PROJECT GOVERNANCE

HOW TO INITIATE AGILE

PROJECTS ?


Agile project initiation (inception)


Product vision @ roadmap

1. Product Vision and Product Roadmap to communicate the long

term view and rough timeline for the project

2. Scope mapping tool to understand the big picture and help plan

releases in complete and valuable slices of functionality.


Backlog modeling

Story mapping


A user story map is a useful technique to help understand the product vision and

functionality of the system


Backlog modeling

Story mapping



Backlog modeling

Story mapping

Story map integrating the different persona’s participating in the workflow

User stories to be detailed and prioritised during

release and sprint planning


Agile project initiation (inception)


Release planning stratgy


Release strategy

– Fixed Functionality Release

(scopebox)

• Fix scope and determine how many

sprints are needed (or remaining).

• Fixed Duration Release

(timebox)

• Fix time and determine how much

scope can be completed


Two strategies are possible

© 2011 TeamProsource393939© Jeff Patton, all rights reserved, www.AgileProductDesign.com

Release planning with scope mapping

• Choose coherent groups of features that consider the span of business functionality

and user activities

• Support all necessary (must have) activities with the first release

(The Minimum Viable Product MVP)

Must have

Should havefirst release

second release

third release

Could have

Optional

Epic Epic Epic

Plan releases in complete and valuable slices of functionality.


Release planning



• Scrum teams have to constantly synchronize their iterative sprint plans with

the high-level schedule (release milestones) base-lined in the project plan

Release planning with multiple teams

Release train

Source: Leffingwell LLC and Scaled Agile Inc


PROJECT GOVERNANCE

HOW TO MONITOR & CONTROL

AGILE PROJECTS ?


Relevant metrics for management


Focus on Business Value


• Delivered Business Value– This metric does not measure work performance but Business Value

– The Sum of delivered BV Points (DONE User Stories) over the total BV Points. (= actual progress

of your project in terms of business goals achieved).

• Release burn up chart– “How much we still have to climb” to get the product done.

Relevant metrics for dashboards


Agile metrics focus on delivery


• Risks Burndown chart

– Cumulative risk severities (Impact x

Probability) over time.

• Project ETD (estimated time of

delivery)

– Total number of remaining story points in

the product backlog divided by ‘Average

velocity’

Relevant metrics for dashboards


Agile focus on delivery


Agile dashboard


ROLES &

RESPONSIBILITIES

REVISITED


Scrum roles

© 2011 TeamProsource4949© 2006-2007 Jeff Patton,

Product Owner Responsibilities

Specify objective acceptance

criteria for stories

Participate daily

Be available to answer

questions and clarify details

on user stories

Verify stories are done

based on acceptance

criteria

Evaluate product at end

of Sprint and add or

remove stories from

backlog as necessary

Organize the backlog into

incremental releases


Roles and responsibilities revisited


What about the traditional roles in agile projects?


Role of project manager

• Match expectations of all stakeholders, communicating the big

picture and coordinating the interfaces between them.

• Example of responsibilities

– Communicates with senior management and other stakeholders

– Owner of the high level road mapping and release plans (not the detail)

– Monitors progress against baselined plans

– Manages risks and issues, escalating as required

The servant leader


Role of business analyst



Role of business analyst

• Fully integrated with development team• Should stay one step ahead, ready to answer all questions

• Responsible foro Ensuring clarity and completeness of requirements

o Ensuring business needs properly analysed

o Assisting the product owner in developing the user stories and associated acceptance criteria

• Facilitates communication between business and technical roleso But must not become an intermediary for the business roles

• Helps business think through full implications of their ideas


• Technical design authority for the project– Ensures consistency and coherence across Development Teams

– Ensures adherence to agreed standards

– The “glue” that holds the project together for technology and innovation

• Example of responsibilities – Agrees and controls technical architecture

• Determines technical environments

• Ensures non-functional requirements are achievable

Role of project architect

From Big Design Up Front to Just Enough Design Up Front


• No Big Up-Front Design Necessary– Developers have pre-defined expertise and knowledge of architecture and design solutions.

• Early Architectural Iterations (iteration zero)– The first few iterations may be used to explore technological alternatives (prototyping) and

reduce risks

• Just-Enough Architecture– A rough blueprint of enterprise or system architecture for moving forward.

• Emergent Design– Emergent designs evolve user story to user story and iteration to iteration

– Architectural evolution demonstrated in Sprint Reviews

Role of architect


Different practices for agile architecture and design


PMBOK KNOWLEDGE AREA’S

REVISITED


Project

Initiation

Product

Increment

Sprint

Planning

Sprint

Sprint

Review

Sprint

Retrospective

Hybrid project management framework

Combining PMBOK and Scrum


• Product vision board and Story (scope) mapping help to communicate the

total product scope.

• Scope Flexibility means that the initial business requirements-gathering

stage is kept focused on the core features (walking skeleton) and detailed

requirements are allowed to evolve through the life cycle.

• Requirements and scope change requests need to be continuously

reprioritised by product owner (MoSCoW or Kano technique)

• Work decomposition is done to working deliverables (Features Breakdown

Structure , User Story Map…) for each release and not in work packages

which are not useful until integrated

Agile scope management


Total scope remains flexible (negotiable). Sprint scope is fixed


• Early & frequent code reviews, – Clear definition of done

– Unit testing performed by the team itself (test driven development),

– Integration by testers

• Early demonstration & feedback from the customer, – User acceptance by product owner

• Removal of impediments by ScrumMaster

Agile quality management


Quality assurance and measurements are "baked" into the Scrum practices


• Release planning– Release plan details iterations of first release (the first increment) and planned dates for

deployment of later Increments

– High level estimates are based on

• Historical data (comparable team)

• empirical data (team velocity based on try-out sprint)

• Normalised velocity (based on company norm)

– The risks of more iterations to be added later on should be acknowledged

• Iteration planning– Only the features targeted for the sprints

are elaborated and estimated (just in time planning)

Agile time management

Only a high level release schedule is developed for project control


• Initial cost estimates are based on scope mapping and release plan – Initial estimates based on analogy or expert experience (estimated velocity)

– As the team members go through the “must have” list of features they can estimate the minimal

number of sprints (iterations)

• This initial cost baseline can be revised after a couple of sprints when actual team

velocity is known

• A cost buffer is advisable when there is a risk of more iterations than originally

planned.

Agile cost management

Best and worst case cost as the number of people on the project multiplied by the

number of sprints

50

100

150

200

250

Pessimist

Optimist Wishful

thinking

Q1 ! ! ! Q1 ! ! ! !

Q2 ! ! ! ! Q3 ! ! ! ! Q4 ! ! ! ! Q2

Promised release Likely

release

De

live

red

sto

ry p

oin

ts

Fixed scope


• Reduce risk through just enough architecture – Multiple architectural options may emerge, which then need to be reduced to one. By the

end of the elaboration phase the high-risk elements in the project will have been eradicated.

Agile risk management

The entire team is involved during sprint planning, daily scrums and retrospectives

Risk-adjusted backlogs and risk burndowns tools • A risk-adjusted backlog contains a smart blend of value-

generating features and risk-reduction actions.

Agile project management

Business

Transcript of Agile project management