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 ?
michel.coens@teamprosource.eu

© 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 and
improvement 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
Deliveredstorypoints
Fixed scope
Fixed costs
Henrik Kniberg
Estimate the velocity upfront and visualize the level of uncertainty
Estimated Velocity = 10 points/iteration
Backlog = 250 points
25 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 have
first 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 for
o 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 roles
o 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
OptimistWishful
thinking
Q1 ! ! !Q1 ! ! !
!
Q2 ! ! ! ! Q3 ! ! ! ! Q4 ! ! ! ! Q2
Promised release Likely
release
Deliveredstorypoints
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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Agile project management

Similaire à Agile project management (20)

Dernier

Dernier (20)

Agile project management