Agile Porfolio Management Denver Apln Mar 2009

8/3/2019 Agile Porfolio Management Denver Apln Mar 2009

1/27

3/19/200

Copyright 2009, Leffingwell, LLC.

Scaling Software Agility:

Agile PortfolioManagement

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 Leffingwells Background

2


2/27

3/19/200


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.
mailto:[email protected]://www.leffingwell.org/http://www.scalingsoftwareagility.wordpress.com/


3/27

3/19/200


Agenda

5

1. Orientation and Overview Why the waterfall/milestone governance model of software

development doesnt workPerspectives on Agile Portfolio Management: DTE Energy

Case Study3. Rethinking Investment Funding4. Rethinking Change Management5. Rethinking Governance and Oversight


WHY THE WATERFALLMILESTONE/GOVERNANCE

MODEL OF SOFTWAREDEVELOPMENT DOESNT

WORK

6


4/27

3/19/200


Waterfall/milestone governance doesnt work

because the development modeldoesnt work

Requirements

Design

Coding andUnit Test

SystemIntegration

Operation andMaintenance

7

The Waterfall Model of

Application

DevelopmentWhy, When I was yourage, sometimes Ive

believed in six impossiblethings before breakfast

The Queen to Alice inWonderland

There is probably no job on earth for which an ability to believe six impossiblethings before breakfast is more of a requirement than Software Project

Management

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


The Box We Build for Ourselves

8

Fixed time

Fixed scope(requirements)

rr

r r r

r

r r

r

rr

r

r

rr

r r

r

r

r

rr

r

r

2) We have to estimate

every task and resource

well need over the whole

time!

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

and estimate even this one before time even begins!


5/27

3/19/200


Assumptions Behind the Box

There exists a reasonably well defined set ofrequirements, 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 canpredict how that will go

Software research anddevelopmentcan be done on apredictable schedule and budget

9


What Really HappensMost software projects are 50-100% late (Standish Group)At deadline time, nothing works completelyWhat 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


6/27

3/19/200


What Happens in the Box?

The teams are not on plan bad plan (blameplanning) or bad team (blame development team)?

They are under enormous pressure to deliver thepromised functionality in the box

In order to complete the committed work, the teamsmust actively resistany 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


7/27

3/19/200


Wait, it gets worse-

The buggy solution we don't quite have is a poor fitto 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 tothe customer in the predicted time frame

Quality is compromised- what we have is buggy

We now understand that the solution that wehave in process is off the mark. (requirementsdecay)

We likely dont have anything holistic to ship to

the hold the customers confidence We havent even driven the risk out of the project,

because integration is not complete

14


8/27

3/19/200


AGILE DEVELOPMENT

OVERVIEW

15


Agile Process Movement

16

Yahoo, Google,BTI, BMC,Nokia, DTEEnergy, Cisco,Citrix, HP, JPMorgan, AOLBoeing,Comcast,PayPal, EDS,Emerson,Fidelity
http://users.evtek.fi/~jaanah/ApplicationD/waterfall.gifhttp://www.extremeprogramming.org/rules/iterative.htmlhttp://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=


9/27

3/19/200


What's Different About

Agile?

17


What Paradigms Are We Breaking?

18


10/27

3/19/200


Agile Kills the Box

19


Helps Avoid the Death March

20Slide by David Wood


11/27

3/19/200


Reduces Risk



Starts Delivering ROI Immediately

22

$ in

$$ in

$$$ in

$$$$ in

$$$$$ in

Waterfall $$$$$start here if youare lucky andon time


12/27

3/19/200


Delivers Better Fit for Purpose

Measure ofwaterfall customer

dissatisfaction



What Is EnterpriseSoftware Agility?

24


13/27

3/19/200


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


14/27

3/19/200


Enterprise Agility

That harness large numbers of agile teams to buildand release quality enterprise-class software more

rapidly than ever beforeExplicitly driven by intimate and immediate customerfeedback

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


15/27

3/19/200

H

HH

H

For discussion, see www.scalingsoftwareagility.wordpress.com

Inspired by collaboration

Leffingwell, LLC. & Symbian Software Ltd.

2009 Leffingwell, LLC.


Agile Enterprise Adoption:Observed Anti-patterns

Insufficient refactoring of testing organizations, testingskills (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-agileportfolio/governance model

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


16/27

3/19/200


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 thedevelopment and management of energy related businesses and servicesnationwide with $9 billon in annual revenue and 11,000 employees. DTE EnergysInformation Technology Services (ITS) organization, now consisting of over 900people, provides leadership, oversight, delivery, and support on all aspects ofinformation 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 FrontDesign/Analysis (BUFD)

- Long range plans- Resources committed yearin advance- Analysis paralysis

order taker mentality -Do what you are told-We are the boss of you

-False agreements. No buyin.

-Misses innovationcontribution from IT-Failure to meetexpectationsmistrust-No empowerment, lowermotivation

32


17/27

3/19/200


Legacy Thinking Change Management


Maximize utilization -Resources committed longrange-100% allocation beforewhat if- Key resources assigned tomultiple projects

- No time to think or innovate- Dedicate resources to taskor lose resources- Thrashing productivitylost of most valuableresources- Exhaustion, burnout

Get it done Belief that best case plansmust succeed

- Deferred recognition ofplan vs. actual- Late discovery and re-

negotiation- Loss of credibility, mistrust

33


Legacy Thinking Governance andOversight


Control through data

we can plan out a full

year of projects

- Fine grain reporting andoverhead- Detailed wbs, earned valuemetrics ,fully loaded Ganttcharts

- Reporting overhead- Annoying the team- Metrics dont reflect actualprogress-Could not assess new agileprojects with old metrics- Plans are obsolete, but nottreated that way

34


18/27

3/19/200


AGILE PORTFOLIO

MANAGEMENT:RETHINKING INVESTMENTFUNDING

35


From: too many projects to ContinuousContent Delivery

To Agile Portfolio

Dedicated teams stop multiplexing noone works on more than one team

Project overhead is replaced by standarditeration and release cadence

New initiatives appear as new content andare prioritized at each iteration/releaseboundary

Work in an iteration/release is fixed

Team resources are adjusted only atperiodic release boundaries

36

Getting anything done (new feature orepic) requires creation of a new project

Projects have significant overhead,planning, resourcing, execution, closure

Once started, projects take on a life of theirown. They develop antibodies to changeand closure.

Many small projects cause people tomultiplex 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 withcontent management


19/27

3/19/200


To: Agile Velocity and Constraint-basedPlanning and Estimating

To Agile Estimating and Planning

Agile teams develop and monitor velocity(capacity) based on story points at iterationlevel

Story points can be normalized acrossteams

Standardized estimating by analogousmodel can also be applied at the level ofEpics 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 thelowest leaf

Requiring all leafs be identified beforeestimate is given

Forces Big Up Front Analysis andestimates based on false precision

Force fits later activities into a flawed WBS

From WBS Estimating andPlanning

Epic

FeatureStory


An Agile Requirements InformationModel

38

Epic

featureFeature:

storystory

storystory

Story:

Marketable experience,Used forportfolio estimating May also describe large architecturalinitiatives

Substantive user benefit Used forrelease planning Features sized to fit in release boundaries System-level, common and non-functional

requirements often carried here

User value Used foriteration planning Sized to fit in iteration boundaries


20/27

3/19/200


To: Simplified Business Case Proposals

To Agile Model

1-2 page business case form

Not much detail

Business cases that make the cut getexploratory iterations funding

Easily cancelled if progress notacceptable

Fast ROI if it is

Updated quarterly changes only

39

Detailed business case justificationsbecome project plans

False precision - detailedrequirements over-constrain solutionimplementation

May contain redundant schedule,budget, ROI information

Investment in the business casecauses resistant to changing the caseand plan

Too much overhead for quarterlyupdate

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


21/27

3/19/200


AGILE PORTFOLIO

MANAGEMENT: RETHINKINGCHANGE MANAGEMENT

41


From PMBOK to Agile ProjectManagement

From Traditional: Performed bytheproject manager

To Agile:Performed by the team

42

WorkBreakdownStructureestimating

Gantt Charts

scheduling

Critical Pathanalysis

Reporting

Highpriorityfeature

Iterationplanning

Actual velocitybasedestimating

Releaseplanningandroadmap

Release/iterationreview/retro-pective

2 pts

4 pts

2 pts


22/27

3/19/200


From Gantt to Asynchronous Sprints to AgileRelease Train

43

From: GanttTo: Independent,asynchronous,Sprints

To: Agile Release Train

Issues:Irrelevant to agile teamsHard to maintainAlways obsoleteIf a team isnt on theplan, is it a bad team orbad plan?

Measurepaper, notsoftware

Issues:Most agile companies start hereLittle coordination amongst teamsNon-harmonized schedulesNo visibility beyond the next sprintLittle or no system level visibility

Coordinates sprintsMulti- sprint visibility and commitmentTeams work out interdependencies onthe flyFull system visibilityRequires 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


23/27

3/19/200


To: Rolling Wave Plan-of-Intent Roadmap

45

May 15,May 15, 0808

Road Rage Ported(part I)

Brickyard port started(stretch goal tocomplete)

Distributed platformdemo

ALL GUIs for bothgames demonstrable

New features (see

prioritized list) Demo of Beemer game

May 22, 08May 22, 08

Road Rage Completed

(single user)

Brickyard Ported (singleuser)

Road Rage multiuserdemonstrable

First multiuser gamefeature for Road Rage

New features (seeprioritized list)

Beemer game in Alpha

JulyJuly 0808

Multiuser Road Rage firstrelease

Brickyard Portedmultiuser demo

New features for bothgames (see prioritizedlist)

Beemer game to E3Tradeshow?

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 theteam to the next release


AGILE PORTFOLIOMANAGEMENT: RETHINKINGGOVERNANCE ANDOVERSIGHT

46


24/27

3/19/200


From Milestone-based to Knowledge-based Governance.

47

Milestones are iterations and incrementalreleases of working code

Status and quality are quantitative, notsubjective

Project office comes to teams (enablingleadership model)

Teams default model is to proceedunlessstopped by business case (no processdriven delays/waste)

No scheduling delays and overhead

Process changes applied and harvested

from teams retrospectives

Teams report milestones with document -based reviews

Subjective, milestone reports do notcorrelate to actual project status

Teams report to project office (leader asconductor/boss)

Teams cannot proceeduntil and unlessthey pass milestones (start-wait-start-waitwaste 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 timeWaiting/waste time

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

Customer

request/market feature

Delivery


25/27

3/19/200


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 theseboundaries!

May be inappropriate for them to change their own resources

Question: who has the skills and discipline necessary toinstitutionalize this critical agile best practice?

Answer: PMO?

49


From: Waterfall-based MilestonesTo: Driving Incremental Delivery

50

Commit toMaintenance

ProgramApproved

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 dont need them)


26/27

3/19/200


Iteration Metrics

Stories achieved.

defects, unit tests,test automation,

To: Standardized Iteration and ReleaseMetrics

51

Release Evaluation

Did we achieve therelease?

Demo and objectiveevaluation

Release Metrics

Features completedvs. plan

Total velocity

Quality


Summary - The Agile PMONew 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 practices5. Implement common agile metrics: iteration, release &

process sets

6. Join Agile Project Management Leadership Network

52

PMO enables, fosters, and promotes agilepractices


27/27

3/19/200


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 BusinessNeeds,-- 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 Managers Bridge to Agility-- Sliger and Broderick, 2008. Addison Wesley

53

Agile Porfolio Management Denver Apln Mar 2009

Documents

Transcript of Agile Porfolio Management Denver Apln Mar 2009