Introduction to Agile Project Planning and Project Management

transcript

Introduction to Agile Planning and Project ManagementBy Mike Cottmeyer, Agile CoachLeadingAgile, LLC

Mike CottmeyerLeadingAgile

mike@leadingagile.com1.404.312.1471

www.leadingagile.comtwitter.com/mcottmeyerfacebook.com/leadingagilelinkedin.com/in/cottmeyer

A Project is a temporary endeavor, having a defined beginning and end, undertaken to meet unique goals and objectiveshttp://en.wikipedia.org/wiki/Project_management

A Project Manager is a professional in the field of project management. Project Managers have the responsibility of planning, execution, and closing of any project. http://en.wikipedia.org/wiki/Project_manager

Project Management is the discipline of planning, organizing, securing and managing resources to bring about the successful completion of specific project goals and objectives. http://en.wikipedia.org/wiki/Project_management

Agile has a Project Manager problem…

Agenda…

Part 1: Single-team Agile projects• Agile Values &

principles• How and why Agile

teams work• Fundamental

mechanics of Agile delivery

• The role of the Agile Project Manager

Part 2: Multi-team Agile projects • Challenges with

Agile in larger, more complex enterprises

• Patterns for Agile Program and Portfolio Management

Agenda…

Part 2: Multi-team Agile projects • Challenges with Agile

in larger, more complex enterprises

Agenda…

Part 2: Multi-team Agile projects • Challenges with Agile

in larger, more complex enterprises

Agile Values & Principles

The Agile Manifesto (2001)

• Individuals and Interactions

• Processes and Tools

• Working software

• Comprehensive documentation

• Customer collaboration

• Contract negotiation

• Responding to change

• Following a plan

Challenging the Project Management Paradigm

The BIG Paradigm Shift

CostTime

ReduceRisk

CostTime

IncreaseValue

Is Your Project a Good Candidate for Agile?

Where to Use Agile?

• Sweet spot in software product development

• Domains where market requirements change often

• Initiatives where requirements are unknown or unknowable

• Complex knowledge work

Process Control

• Predictive – Processes well defined and predictable. Process yields acceptable outcomes

• Empirical – Frequently measure outcomes and adapt the process to accommodate variation

Reducing Delivery Risk

Emergence or Convergence

Fundamentals of Team Based Agile

Developers

DevelopersTesters

Developers

Analyst

Testers

Developers

Analyst

TestersCSM

Product Owner

Analyst

TestersDevelopers

Agile Process Flow…

Product VisionUnderstanding why we are doing what we are doing, who it is for, and the overall market opportunity

Product BacklogThe master list of things that we want to build into the product

Iteration BacklogThe highest priority items that we intend to build in the next 2-4 weeks

Feedback LoopsInspect and adapt on regular cadences to mitigate delivery risk

Working ProductIs the primary measure of progress, at the end of each time-box we have a deliverable

Project (years)

Release (months) Release (months) Release (months)

I1 I2 I3 I4 I5 I6 I7 I8 I9

Cadences

Project (years)

I1 I2 I3 I4 I5 I6 I7 I8 I9

Project (years)

I1 I2 I3 I4 I5 I6 I7 I8 I9

Project (years)

I1 I2 I3 I4 I5 I6 I7 I8 I9

Project (years)

I1 I2 I3 I4 I5 I6 I7 I8 I9

Project (years)

I1 I2 I3 I4 I5 I6 I7 I8 I9

Project (years)

I1 I2 I3 I4 I5 I6 I7 I8 I9

Project (years)

I1 I2 I3 I4 I5 I6 I7 I8 I9

Project (years)

I1 I2 I3 I4 I5 I6 I7 I8 I9

Project (years)

I1 I2 I3 I4 I5 I6 I7 I8 I9

Database

Report

Screen

User Story

Database

Report

Screen

User Story

Agile Non-Negotiables

• Teams• Backlog• Cadence• Done

My Customer Doesn’t Give a Crap About Your User Stories!

EpicEpics collections of features, typically 1-3 months in duration. Epics span releases. Epics can span more than one team. These are the things the market cares about.

Feature

Epics collections of features, typically 1-3 months in duration. Epics span releases. Epics can span more than one team. These are the things the market cares about.

Features are smaller than epics, typically 2-4 weeks in duration. Features are contained within releases. Ideally, features are contained within a team. These are what the Product Manager Cares about.

Feature

User Story

Epics collections of features, typically 1-3 months in duration. Epics span releases. Epics can span more than one team. These are the things the market cares about.

Features are smaller than epics, typically 2-4 weeks in duration. Features are contained within releases. Ideally, features are contained within a team. These are what the Product Manager Cares about.

User Stories are the smallest increment of value, typically less than a week. User Stories are contained within the iteration. These are the things the Product Owner, maybe the Engineering Management Cares about.

Feature

User Story

Feature Feature Feature

User Story

Story Maps visually show the relationship between User Stories and Business Value

INVEST

• Independent• Negotiable• Valuable• Estimateable• Small… Sized Appropriately• Testable

Story Maps start with the identification of larger, more strategic organizational goals

Feature

Epics are decomposed into Features that describe the

value added into the product

Feature Feature

Feature Feature Feature Feature

Feature

User Story

Features are decomposed into User Stories that are thin slices of value added into the system

Feature

User Story

Feature

User Story

Feature

User Story

Relative Estimation

• Start with something small and knowable• Give it an arbitrary value of one• Estimate everything else relative to the

original story

• Planning poker encourages communication and leads to shared understanding

• Over time becomes incredibly accurate

Feature

User Story

User Stories are estimated in relative units of measure

called Story Points

Feature

User Story

User Stories are estimated in relative units of measure

called Story Points

Feature

User Story

11 7 12 8

Story Points can be added up to size Features

Feature

User Story

11 7 12 8

38 Feature Points can be added up to size Epics

Varying Scope Using the Minimally Marketable Feature

Feature

User Story

11 7 12 8

38 Our Goal is to build the smallest system possible to deliver the value in the Epic

Feature

User Story

11 7 12 8

38 We continuously evaluate the Story Map to determine the

Minimally Marketable Feature

User Story

11 7 12 8

We continuously evaluate the Story Map to determine the

Minimally Marketable Feature

User Story

10 4 5 7

When we focus on Minimally Marketable Features, we

deliver Business Value early

All I Need to Know is Backlog Size & Velocity

Burndown Charts

Velocity – The rate at which we complete the estimate

Managing & Controlling Agile the Delivery Process

Story Backlog Task Backlog In Process Task Done Story Complete

Minimally Marketable Features feed the prioritization of our

Sprint Planning

Story Backlog Task Backlog In Process Task Done

Identify the User Story most likely to contribute to the

MMF and build that one first

Story Complete

User Story

Identify the User Story most likely to contribute to the

MMF and build that one first

Story Complete

User Story

Pull User Stories in priority order focusing on delivering

complete MMFs

Story Complete

User Story

Pull User Stories in priority order focusing on delivering

complete MMFs

Story Complete

User Story

It’s okay to work User Stories across MMFs if that is what the Product Owner needs

Story Complete

User Story

It’s okay to work User Stories across MMFs if that is what the Product Owner needs

Story Complete

User Story

Planned Team Velocity = 6 points

The team uses its past velocity to determine how many stories go in the Sprint

Story Complete

User Story

TaskTask

The Team breaks each User Story down into Tasks

Story Complete

User Story

TaskTask

Task Task

TaskTask

Story Complete

User Story

TaskTask

Task Task

Story Complete

User Story

TaskTask

Task Task

And estimates each Task in Real Hours so they can assess

if they can make a solid Commitment to Deliver

Story Complete

User Story

TaskTask

Task Task

Story Complete

User Story

TaskTask

Task Task

Planned Team Velocity = 6 pointsPlanned Estimated Hours = 98 hours

Story Complete

User Story

Task Task

Task 8

Task 16

At the beginning of the Sprint, The Team pulls Tasks from the

top of the Task Backlog

Story Complete

User Story

Task Task

Task 8

Task 16

Tasks move across the Story Board until there is a

completed User Story.

Story Complete

User Story

Task Task

Task 8

Task 16User Story

Story Complete

User Story

Task Task

Task 8

Task 16

Story Complete

User Story

Task Task

TaskTask

Task 8

Task 16

User Story

The Team works from the top of the Story Board, Swarming to get User Stories across the

board as fast as possible .

Story Complete

User Story

Task Task

TaskTask

Task 8

Task 16

Story Complete

User Story

Task Task

Task 8

Task 16

User Story

Story Complete

User Story

Task Task

Task 8

Task 16

Until the entire Sprint has been delivered to the Product

Owner.

Story Complete

Release Burndown

Sprint Burndown

Velocity Trend

From a Metrics perspective, we Burn Down hours to make

sure the sprint is on track

Release Burndown

Sprint Burndown

Velocity Trend

Release Burndown

Sprint Burndown

Velocity Trend

Release Burndown

Sprint Burndown

Velocity Trend

Release Burndown

Sprint Burndown

Velocity Trend

Release Burndown

Sprint Burndown

Velocity Trend

Release Burndown

Sprint Burndown

Velocity Trend

Release Burndown

Sprint Burndown

Velocity Trend

Release Burndown

Sprint Burndown

Velocity Trend

Release Burndown

Sprint Burndown

Velocity Trend

From a Metrics perspective, we Burn Down points to make

sure the Release is on track

Release Burndown

Sprint Burndown

Velocity Trend

From a Metrics perspective, we Burn Down points to make

sure the Release is on track

Release Burndown

Sprint Burndown

Velocity Trend

We track Velocity Trend to make sure the team is

delivering in a Predictable manner

Release Burndown

Sprint Burndown

Velocity Trend

When the Release is ready to deliver, The Team has

completed the highest priority User Stories, against the

highest priority Features ,against the highest

priority Epics.

Release Burndown

Sprint Burndown

Velocity Trend

When the Release is ready to deliver, The Team has

completed the highest priority User Stories, against the

highest priority Features ,against the highest

priority Epics.

Everyone is focused on delivering value early and often!

Predicting the Future… Looking Forward on Agile Projects

Yesterday’s Weather

• Past performance is our best indicator of future performance

• The amount of product we were able to build during the last iteration, is a pretty good indicator of what we’ll be able to deliver this iteration

• The same goes for releases

Project (years)

I1 I2 I3 I4 I5 I6 I7 I8 I9

Velocity at Project, Release, and Iteration

Project (years)

I1 I2 I3 I4 I5 I6 I7 I8 I9

Project (years)

I1 I2 I3 I4 I5 I6 I7 I8 I9

Project (years)

I1 I2 I3 I4 I5 I6 I7 I8 I9

Project (years)

I1 I2 I3 I4 I5 I6 I7 I8 I9

Project (years)

I1 I2 I3 I4 I5 I6 I7 I8 I9

Project (years)

I1 I2 I3 I4 I5 I6 I7 I8 I9

Project (years)

I1 I2 I3 I4 I5 I6 I7 I8 I9

Project (years)

I1 I2 I3 I4 I5 I6 I7 I8 I9

Project (years)

I1 I2 I3 I4 I5 I6 I7 I8 I9

Team Level Release Planning

• Use past velocity to determine roughly how much content can fit into the upcoming release

• Vary scope by focusing on the MMF to fine tune the implementation as you build the emerging product

Agile Project Manager – Team

People

Agile Project Management in Larger, More Complex Enterprises

Agile in the Enterprise

Agile (Project Management) in the (Traditional) Enterprise

Contrasted with… Enterprise Agile

Enterprise Agile... it’s different!

Enterprise Agile

Team A

Team C

Team B

Team D

Team F

Team E

Team A

Team C

Team B

Team D

Team F

Team E

Team A

Team C

Team B

Team D

Team F

Team E

Team D

Team F

Team E

Team A

Team C

Team B

Multi-Team Release Planning

• Use past velocity to determine roughly how much content can fit into the upcoming release

• Vary scope by focusing on the MMF to fine tune the implementation as you build the emerging product

• Sequence backlogs so deliverables are coordinated across agile teams

• IMO… this reduces business agility

Let’s Talk About the Stuff That Breaks Agile

External Dependencies

Many-to-Many Relationships

Agile Project, Program, and Portfolio Management using Lean, Kanban, and TOC

Team 1

Team 2

Team 1

Team 2

Team 3

Team 1

Team 2

Team 3

Team 4

Team 1

Team 2

Team 3

Team 4

Team 5

Establishing the relationship between team level velocity and enterprise level throughput?

EpicTeam predictability is one thing, but organizations need to be able to track value at the Epic level

Feature

Team predictability is one thing, but organizations need to be able to track value at the Epic level

We need a mechanism to make sure features that span multiple Scrum teams are treated with the same sense of awareness as single-product features.

Feature

User Story

Team predictability is one thing, but organizations need to be able to track value at the Epic level

We need a mechanism to make sure features that span multiple Scrum teams are treated with the same sense of awareness as single-product features.

All of our day-to-day activities need to clearly map to enterprise objectives. We need to build product as one organization

Story Backlog Task Backlog In Process Task Done Story Backlog

Tier 1 - Scrum

Analysis Design Build Test Deploy

Tier 1 - Scrum

Tier 2 - Kanban

Inception Elaboration Construction Transition

Tier 1 - Scrum

Tier 2 - Kanban

Tier 3 - Kanban

Tier 1 - Scrum

Tier 2 - Kanban

Tier 3 - Kanban

User Story

Tier 1 - Scrum

Tier 2 - Kanban

Tier 3 - Kanban

Feature

User Story

Tier 1 - Scrum

Tier 2 - Kanban

Tier 3 - KanbanEpic

Feature

User Story

Kanban creates a pull system across the entire portfolio that is limited by your actual capacity

Feature

User StoryUser

Feature

User StoryUser

Feature

User StoryUser

Spike TaskTask

Feature

User StoryUser

Spike TaskTask

Feature

User StoryUser

Spike TaskTask

Feature

User StoryUser

Spike TaskTask

Feature

User StoryUser

Spike TaskTask

Feature

User StoryUser

SpikeTaskTask

Feature

EpicEpic

Feature

User StoryUser

SpikeTaskTask

Feature

EpicEpic

Feature

User StoryUser

TaskTask

FeatureFeature

Feature

User StoryUser

SpikeTaskTask

FeatureFeature

Feature

User Story

TaskTask

FeatureFeature

Feature

8 User Story

Spike User Story

FeatureFeature

Feature

8 User Story

Spike User Story

FeatureFeature

8 User Story

Spike User Story

Feature

FeatureFeature

8 User Story

Spike User Story

Feature

FeatureFeature

8 User Story

Spike User Story

FeatureFeature

Feature Feature

User StoryUser

EpicEpic

Feature Feature

User StoryUser

EpicEpic

FeatureFeature

Feature Feature

User StoryUser

EpicEpic

FeatureFeature

Feature Feature

TaskTask

User StoryUser

EpicEpic

FeatureFeature

Feature Feature

TaskTask

8User Story

User Story

EpicEpic

FeatureFeature

Feature Feature

TaskTask

8User Story

User Story

EpicEpic

FeatureFeature

Feature

TaskTask

8User Story

User Story

FeatureFeatureFeature

User StoryUser

SpikeTask

EpicEpic

Feature

TaskTask

8User Story

User Story

Feature

User StoryUser

FeatureFeature

Feature

Epic Epic

User StoryUser

SpikeTask

Feature

Epic Epic

User StoryUser

SpikeTask

Task 8

Feature

Epic Epic

User Story

SpikeTask

Task 8

Feature

Epic Epic

User Story

Task 8

User Story

Feature

Epic Epic

User Story

Task 8

User Story

Feature

Epic Epic

User Story

Task 8

User Story

Feature

Epic Epic

User Story

Task 8

User Story

Feature

Epic Epic

User Story

Task 8

User Story

Feature

Epic Epic

User Story

Task 8

User Story

Feature

User Story

SpikeTask

8 Task 8

Task 8

Release Burndown

Sprint Burndown

Velocity Trend

At the team level, velocity metrics drive predictability

Release Burndown

Sprint Burndown

Velocity Trend

At the program/product level, lean metrics are more meaningful

Release Burndown

Sprint Burndown

Velocity Trend

At the program/product level, lean metrics are more meaningful

At the enterprise level, lean metrics are also the more interesting metric

Balancing Organizational Constraints

Enterprise Release Planning

• Use Scrum at the team level to drive predictable outcomes

• Balance the backlogs across team to optimize the flow of value at the Feature and Epic level

• Use metrics to plan the number of Features and Epics that can be included in a release

Agile Project Managers

• Manage the System, not the People• Clear the path, enable the teams and the

organization• Drive shared understanding of delivery

risk• Systems thinking, look out for the whole

Agile Project Manager - Enterprise

Mike CottmeyerLeadingAgile

mike@leadingagile.com1.404.312.1471

www.leadingagile.comtwitter.com/mcottmeyerfacebook.com/leadingagilelinkedin.com/in/cottmeyer

www.slideshare.net/mcottmeyer

Introduction to Agile Project Planning and Project Management

Technology