Scaling Software Agility: Agile Portfolio Management · The following slides are abstracted from a case study Establishing an Agile ... To Agile Model 1-2 page business case form

3/19/2009

1

Copyright 2009, Leffingwell, LLC.

Scaling Software Agility:

Agile Portfolio

Management

Presentation to Denver Chapters of the

International Institute of Business Analysis

(IIBA) and Agile Project Leadership Network

(APLN)

By Dean Leffingwell

March 17, 2009

1


Dean Leffingwell‟s Background

2

3/19/2009

2


More from Dean Leffingwell

3

Copyright 2009, Leffingwell, LLC. 4

-- Taiichi Ohno, Toyota Production System. (the father of lean methods)

“Plans change very easily. Worldly affairs do not always go according to a plan and orders have to change rapidly in response to a change in circumstances.

If one sticks to the idea that once set, a plan should not be changed, a business cannot exist for long.”

“Plans change very easily. Worldly affairs do not always go according to a plan and orders have to change rapidly in response to a change in circumstances.

If one sticks to the idea that once set, a plan should not be changed, a business cannot exist for long.”

http://www.scalingsoftwareagility.wordpress.com/

http://www.leffingwell.org/

mailto:[email protected]

3/19/2009

3


Agenda

5

1. Orientation and Overview

Why the waterfall/milestone governance model of software

3. Rethinking

4. Rethinking

5. Rethinking

1. Orientation and Overview

• Why the waterfall/milestone governance model of software

development doesn’t work

•Perspectives on Agile Portfolio Management: DTE Energy

Case Study

3. Rethinking Investment Funding

4. Rethinking Change Management

5. Rethinking Governance and Oversight


WHY THE WATERFALL

MILESTONE/GOVERNANCE

MODEL OF SOFTWARE

DEVELOPMENT DOESN‟T

WORK

6

3/19/2009

4


Waterfall/milestone governance doesn‟t work

because the development model doesn‟t work

RequirementsRequirements

Design

Coding andUnit Test

SystemIntegration

Operation andOperation andMaintenance

7

The Waterfall Model of

Application

Development“Why, When I was your

age, sometimes I’ve

believed in six impossible

things before breakfast”

The Queen to Alice in

Wonderland

“There is probably no job on earth for which an ability to believe six impossible

things before breakfast is more of a requirement than Software Project

Management”

DeMarco and Lister - Waltzing with Bears: Managing Risks in Software

Projects


The Box We Build for Ourselves

8

Fixed time

Fixed scope

(requirements)

rrrr

rr rr rr

rr

rr rr

rr

rrrr

rr

rr

rrrrrr rr

rr

rr

rr

rrrr

rr

rr

2) We have to estimate

every task and resource

we’ll need over the whole

time!

2) We have to estimate

every task and resource

we’ll need over the whole

time!

1) In order to give a professional estimate, we have to analyze

and estimate

1) In order to give a professional estimate, we have to analyze

and estimate even this one before time even begins!

3/19/2009

5


Assumptions Behind the Box

There exists a reasonably well defined set of

requirements, if we only took the time to define them

We can limit change or it will be small and manageable

System integration is a stage in the lifecycle and we can

predict how that will go

Software research and development can be done on a

predictable schedule and budget

9


What Really Happens

Most software projects are 50-100% late (Standish Group)

At deadline time, nothing works completely

What do we do now?Take Action Promote the non-participants

Scope triage

Create a new plan

Reduce testing time

Cut back on quality

Extend delivery date

Repeat failed process

Requirements

Design

Coding andUnit Test

SystemIntegration

Operation andMaintenance

0 126

10

3/19/2009

6


What Happens in the Box?

The teams are not on plan – “bad plan” (blame

planning) or “bad team” (blame development team)?

They are under enormous pressure to deliver the

promised functionality in the box

In order to complete the committed work, the teams

must actively resist any further change

They are about of time and they have only one

variable left under their control

Solution: Sacrifice QUALITY

11


Insert Your Own Waterfall Defect Chart

Here

12

3/19/2009

7


Wait, it gets worse-

The buggy solution we don't quite have is a poor fit

to current requirements

25%

50%

75%

100%

0 3 6 9 12 15 18 21 24

Fidelity Gap

13


Looking Backwards - Conclusion

We failed to deliver the application as intended to the customer in the predicted time frame

Quality is compromised- what we have is buggy

We now understand that the solution that we have in process is off the mark. (requirements decay)

We likely don’t have anything holistic to ship to the hold the customer’s confidence

We haven’t even driven the risk out of the project, because integration is not complete

14

3/19/2009

8


AGILE DEVELOPMENT

OVERVIEW

15


Agile Process Movement

16

Yahoo, Google,

BTI, BMC,

Nokia, DTE

Energy, Cisco,

Citrix, HP, JP

Morgan, AOL

Boeing,

Comcast,

PayPal, EDS,

Emerson,

Fidelity…

http://images.google.com/imgres?imgurl=http://www.flashline.com/images/content/EUP.gif&imgrefurl=http://www.flashline.com/content/Ambler/reuseRUP.jsp&h=310&w=514&sz=9&tbnid=JUCTbCsxtGQJ:&tbnh=77&tbnw=128&hl=en&ei=qQ4iQ9ClCZCUFoLvnY8D&sig2=gySkwlUwO7j5Ts7s_MxEKw&start=4&prev=/images?q=rational+unified+process&svnum=10&hl=en&lr=

http://www.extremeprogramming.org/rules/iterative.html

http://users.evtek.fi/~jaanah/ApplicationD/waterfall.gif

3/19/2009

9


What's Different About

Agile?

17


What Paradigms Are We Breaking?

18

3/19/2009

10


Agile Kills the Box

19


Helps Avoid the Death March

20

Slide by David Wood

3/19/2009

11


Reduces Risk

21Slide by David Wood


Starts Delivering ROI Immediately

22

$ in

$$ in

$$$ in

$$$$ in

$$$$$ in

Waterfall $$$$$

start here if you

are lucky and

on time

3/19/2009

12


Delivers Better Fit for Purpose

Measure of

waterfall customer

dissatisfaction

23Slide by David Wood


What Is Enterprise

Software Agility?

24

3/19/2009

13


Team Agility

A disciplined set of

– enhanced software engineering practices

– empirical software project management practices

– modified social behaviors

That empowers teams to:

– more rapidly deliver quality software

– explicitly driven by intimate and immediate customer feedback

25


Achieving Team Agility

1. The Define/Build/Test Team

2. Mastering the Iteration

3. Smaller, More Frequent Releases

4. Two-level Planning

5. Concurrent Testing

6. Continuous Integration

7. Regular Reflection and Adaptation

26

3/19/2009

14


Enterprise Agility

That harness large numbers of agile teams to build

and release quality enterprise

rapidly than ever before

Explicitly driven by intimate and immediate customer

feedback

That harness large numbers of agile teams to build

and release quality enterprise-class software more

rapidly than ever before

Explicitly driven by intimate and immediate customer

feedback

A set of A set of

– organizational best practices

– beliefs

– core values

27


Achieving Enterprise Agility

1. Intentional Architecture

2. Lean Requirements at Scale

3. Systems of Systems and the Agile Release Train

4. Managing Highly Distributed Development

5. Changing the Organization

6. Impact on Customers and Operations

7. Measuring Business Performance

28

3/19/2009

15

H

HH

H

For discussion, see www.scalingsoftwareagility.wordpress.com

Inspired by collaborationLeffingwell, LLC. & Symbian Software Ltd.

©2009 Leffingwell, LLC.


Agile Enterprise Adoption:

Observed Anti-patterns

Insufficient refactoring of testing organizations, testing

skills (TDD), test automation

Lack of basic team proficiency in agile technical practices

Insufficient depth/competency in the product owner role

Inadequate coordination of vision and delivery strategies

Waterscrumming - Agile development in a non-agile

portfolio/governance model

30

http://www.scalingsoftwareagility.wordpress.com/

3/19/2009

16


PERSPECTIVE ON AGILE

PORTFOLIO MANAGEMENT:

DTE ENERGY CASE STUDY

31

The following slides are abstracted from a case study Establishing an Agile

Portfolio to Align IT Investments with Business Needs -- Thomas and Baker,

DTE Energy presented at Agile 2008, by DTE Energy.

“DTE Energy, a Fortune 300 is a diversified energy company involved in the

development and management of energy related businesses and services

nationwide with $9 billon in annual revenue and 11,000 employees. DTE Energy’s

Information Technology Services (ITS) organization, now consisting of over 900

people, provides leadership, oversight, delivery, and support on all aspects of

information technology (IT) across the enterprise.”

They have been implementing an extending agile practices since 1998.


Legacy Thinking - Investment Funding

Mindset Manifestation Problems

“widget engineering” -Fixed schedule,

functionality planning

-Big Up Front

Design/Analysis (BUFD)

- Long range plans

- Resources committed year

in advance

- Analysis paralysis

“order taker mentality” -Do what you are told

-We are the boss of you

-False agreements. No buy

in.

-Misses innovation

contribution from IT

-Failure to meet

expectations –mistrust

-No empowerment, lower

motivation

32

3/19/2009

17


Legacy Thinking – Change Management


“Maximize utilization” -Resources committed long

range

-100% allocation before

“what if”

- Key resources assigned to

multiple projects

- No time to think or innovate

- Dedicate resources to task

or lose resources

- Thrashing – productivity

lost of most valuable

resources

- Exhaustion, burnout

“Get it done” Belief that best case plans

must succeed

- Deferred recognition of

plan vs. actual

- Late discovery and re-

negotiation

- Loss of credibility, mistrust

33


Legacy Thinking – Governance and

Oversight


“Control through data”

“we can plan out a full

year of projects”

- Fine grain reporting and

overhead

- Detailed wbs, earned value

metrics ,fully loaded Gantt

charts

- Reporting overhead

- Annoying the team

- Metrics don’t reflect actual

progress

-Could not assess new agile

projects with old metrics

- Plans are obsolete, but not

treated that way

34

3/19/2009

18


AGILE PORTFOLIO

MANAGEMENT:

RETHINKING INVESTMENT

FUNDING35


From: “too many projects” to Continuous

Content Delivery

To Agile Portfolio

Dedicated teams stop multiplexing – no

one works on more than one team

Project overhead is replaced by standard

iteration and release cadence

New initiatives appear as new content and

are prioritized at each iteration/release

boundary

Work in an iteration/release is fixed

Team resources are adjusted only at

periodic release boundaries

36

Getting anything done (new feature or

epic) requires creation of a new project

Projects have significant overhead,

planning, resourcing, execution, closure

Once started, projects take on a life of their

own. They develop antibodies to change

and closure.

Many small projects cause people to

multiplex between projects

– Each project switch takes 20% overhead

– Working on three projects means people only deliver

value 40% of the time

– While switching to agile, one company diagnosed the

failures of the first 5 teams first few iterations.

Conclusion: No one worked on the project long

enough to accomplish anything!

From Traditional

Project, portfolio mix:

Size, risk, reward

Agile Release Train with

content management

3/19/2009

19


To: Agile Velocity and Constraint-based

Planning and Estimating

To Agile Estimating and Planning

Agile teams develop and monitor “velocity”

(capacity) based on story points at iteration

level

Story points can be normalized across

teams

Standardized estimating by analogous

model can also be applied at the level of

Epics and Features

Epic estimating can be used for gross,

portfolio-level planning

Feature estimates can be used for release

(product) level planning

Story points used for iteration planning

37

Traditional project estimates tasks at the

lowest leaf

• Requiring all leafs be identified before

estimate is given

• Forces Big Up Front Analysis and

estimates based on false precision

• Force fits later activities into a flawed WBS

From WBS Estimating and

Planning

Epic

Feature

Story


An Agile Requirements Information

Model

38

Epic

featureFeature:

storystory

storystory

Story:

Marketable experience

•,Used for portfolio estimating

• May also describe large architectural

initiatives

Substantive user benefit

• Used for release planning

• Features sized to fit in release boundaries

• System-level, common and non-functional

requirements often carried here

User value

• Used for iteration planning

• Sized to fit in iteration boundaries

3/19/2009

20


To: Simplified Business Case Proposals

To Agile Model

1-2 page business case form

Not much detail

Business cases that make the cut get

exploratory iterations funding

Easily cancelled if progress not

acceptable

Fast ROI if it is

Updated quarterly – changes only

39

Detailed business case justifications

become project plans

False precision - detailed

requirements over-constrain solution

implementation

May contain redundant schedule,

budget, ROI information

Investment in the business case

causes resistant to changing the case

and plan

Too much overhead for quarterly

update

From Traditional , Document-based

Ipsum lorem


To: Agile Portfolio Planning

Establish sizing model for epics, features and stories

Prioritize epics at portfolio level

Revised business cases quarterly

Just prior to release planning boundaries

– Break epics into features and size features

– Prioritize features

At Release Planning

– Business case drives vision - which drives features

– Resources adjusted to address constraints (velocity bottlenecks)

40

3/19/2009

21


AGILE PORTFOLIO

MANAGEMENT: RETHINKING

CHANGE MANAGEMENT

41


From PMBOK to Agile Project

Management

From Traditional: Performed by

the project manager

To Agile:

Performed by the team

42

Work

Breakdown

Structure

estimating

Gantt Charts

scheduling

Critical Path

analysis

Reporting

High

priority

feature

Iteration

planning

Actual velocity

based

estimating

Release

planning

and

roadmap

Release/iteration

review/retro-

pective

2 pts

4 pts

2 pts

3/19/2009

22


From Gantt to Asynchronous Sprints to Agile

Release Train

43

From: Gantt

To: Independent,

asynchronous,

SprintsTo: Agile Release Train

Issues:

•Irrelevant to agile teams

•Hard to maintain

•Always obsolete

•If a team isn’t on the

plan, is it a “bad” team or

“bad” plan?

•Measure paper, not

softwareIssues:

•Most agile companies start here

•Little coordination amongst teams

•Non-harmonized schedules

•No visibility beyond the next sprint

•Little or no system level visibility

•Coordinates sprints

•Multi- sprint visibility and commitment

•Teams work out interdependencies on

the fly

•Full system visibility

•Requires set-based development


To: Enterprise Release PlanningCollaborative, face-to-face, multi-level, multi-iteration

44

Eng mgrs

State of the business

Objectives for upcoming periods

Objectives for release

Prioritized feature set

Each team presents plans to group

Issues/impediments noted

Issues/impediments assigned

Release commitment vote?

Teams plan stories for iterations

Work out dependencies

Architects and PMs, POs circulate

|1|1

|1|1

|2|2

|2|2

|3|3

|3|3

|4|4

|4|4

architects

Product managers/

Product Owners

PMs

Executives

3/19/2009

23


To: Rolling Wave Plan-of-Intent Roadmap

45

May 15, May 15, „„0808

Road Rage Ported

(part I)

Brickyard port started

(stretch goal to

complete)

Distributed platform

demo

ALL GUIs for both

games demonstrable

New features (see

prioritized list)

Demo of Beemer game

May 22, ‟08 May 22, ‟08

Road Rage Completed

(single user)

Brickyard Ported (single

user)

Road Rage multiuser

demonstrable

First multiuser game

feature for Road Rage

New features (see

prioritized list)

Beemer game in Alpha

July July „„0808

Multiuser Road Rage first

release

Brickyard Ported

multiuser demo

New features for both

games (see prioritized

list)

Beemer game to E3

Tradeshow?

• An updated, themed, and prioritized “plan of intent”

• Updated quarterly

• High confidence next release, lower confidence next+1

• “Owned” by teams. “Maintained” by PMO?

+Plus:

A commitment from the

team to the next release


AGILE PORTFOLIO

MANAGEMENT: RETHINKING

GOVERNANCE AND

OVERSIGHT

46

3/19/2009

24


From Milestone-based to Knowledge-

based Governance.

47

Milestones are iterations and incremental

releases of working code

Status and quality are quantitative, not

subjective

Project office “comes to teams” (enabling

leadership model)

Teams default model is to proceed unless

stopped by business case (no process

driven delays/waste)

No scheduling delays and overhead

Process changes applied and harvested

from team’s retrospectives

Teams report milestones with document -

based reviews

Subjective, milestone reports do not

correlate to actual project status

Teams “report to” project office (leader as

conductor/boss)

Teams cannot proceed until and unless

they pass milestones (start-wait-start-wait

waste cycle)

Scheduling delays and overhead

Process changes dictated by “those who

know best”

From Traditional – Milestone based To Agile – Knowledge based


With Value Stream Mapping

Pick a “feature level” item from a real project and perform value

stream mapping from “concept to cash”

– Identify all steps from customer request to customer delivery

– Focus on steps and time, not costs

– Look for places to eliminate one of the seven “wastes”

How to go about it:

– Gather stakeholders and take 1-2 hrs to draw a map and discuss it

– Take the time to gather and refine missing data

– Meet again, revise the map and discuss implications

– Pick the biggest delays and longest cues and take action

– Repeat

48

Value time

Waiting/waste time

Source: Implementing Lean Software Development: From Concept to Cash. Poppendiecks

Customer

request/market feature

Delivery

3/19/2009

25


To: PMO Drives Release Planning,

Reviews, Retrospectives

Release planning is a routine, major enterprise “event”

Requires: coordination, cooperation, logistics, facilitation, planning,

discipline, metrics

Difficult for teams themselves to coordinate this across teams-of-

teams function.

Resource adjustment (change management) happens at these

boundaries!

– May be inappropriate for them to change their own resources

Question: who has the skills and discipline necessary to

institutionalize this critical agile best practice?

Answer: PMO?

49


From: Waterfall-based Milestones

To: Driving Incremental Delivery

50

Commit to

Maintenance

Program

Approved

1.1 - 1.nPotentially shippable Increments

Quality/GA Firewall

2.1 - 2.nIncremental releases

• If (you must have them)

• Then (they must drive incremental delivery)

• Else (you don’t need them)

3/19/2009

26


Iteration Metrics

Stories achieved….

defects, unit tests,

test automation,

Iteration Metrics

Stories achieved….

defects, unit tests,

test automation,

To: Standardized Iteration and Release

Metrics

51

Release Evaluation

Did we achieve the

release?

Demo and objective

evaluation

Release Evaluation

Did we achieve the

release?

Demo and objective

evaluation

Release Metrics

Features completed

vs. plan

Quality

Release Metrics

Features completed

vs. plan

Total velocity

Quality


Summary - The Agile PMO

New Mission: Enable, Empower, Ensure

1. Leads value chain analysis

2. Educate project managers in lean and agile

3. Adopt agile estimating and portfolio planning

4. Implement Agile Release Train best practices

5. Implement common agile metrics: iteration, release &

process sets

6. Join Agile Project Management Leadership Network

52

PMO enables, fosters, and promotes agile

practices

3/19/2009

27


Sources and Resources

Agile Portfolio Management

-- Jochen Krebs, 2008, Microsoft Press

Agile Project Management Leadership Network, http://apln.org/

Establishing an Agile Portfolio to Align IT Investments with Business

Needs,

-- Thomas and Baker, DTE Energy, Proceedings of Agile 2008

Implementing Lean Software Development: From Concept to Cash

-- Poppendieck, 2007. Addison-Wesley

Scaling Software Agility: Best Practices for Large Enterprises

-- Leffingwell, 2007. Addison-Wesley

The Software Project Manager‟s Bridge to Agility

-- Sliger and Broderick, 2008. Addison Wesley

53

Scaling Software Agility: Agile Portfolio Management · The following slides are abstracted from a case study Establishing an Agile ... To Agile Model 1-2 page business case form

Documents