Agile2012 rev4.pptx

8/15/12

1

© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 1

Scaling Lean|Agile Development Myths and Ideologies Meet the Scaled Agile Framework

Dean Leffingwell [email protected]

DeanLeffingwell.com ScalingSoftwareAgilityblog.com


Myths and Ideologies

1.  Scaling Value: Not everything is a User Story

2.  Scaling Team and Timebox: No team is an island

3.  Scaling Design: Emergent design meets intentional architecture

4.  Scaling Portfolio Management: Addressing legacy mindsets

5.  Scaling Leadership: Your enterprise can be no leaner than your executives thinking

Agile: •  Myths •  Ideologies •  Misperceptions •  Legacy Mindsets

8/15/12

2


Context for Scaling Lean and Agile

Respect for People

Product Development

Flow

Continuous Improvement


Lean Goal: Speed, Value, Quality

  All we are doing is looking at the timeline, from the moment the customer gives us an order to the point where we collect the cash. And we are reducing the time line by reducing the non-value added wastes. Taiichi Ohno

  We need to figure out a way to deliver software so fast that our customers don’t have time to change their minds.

Poppendieck   Minimize delays, handoffs and non-

value added activities

The Goal of Lean: Sustainably shortest lead time

•  Best quality and value to people and society

•  Most customer delight, lowest cost, high morale, safety

8/15/12

3


Lean Goal: Speed, Value, Quality

  Take an economic view   Actively manage queues   Understand and exploit

variability   Reduce batch sizes   Apply WIP constraints   Control flow under

uncertainty: cadence and synchronization

  Get feedback as fast as possible

  Decentralize control


The Scaled Agile Framework™

The Scaled Agile Framework (“SAFe”) is a proven, publicly-facing framework for applying Lean and Agile practices at enterprise scale

More on SAFe:  Synchronizes the vision,

planning, interdependencies, and delivery of many teams

 Web version available to public since February 2012

 Works well for teams of 50-100

 Has been scaled to hundreds of teams and thousands of people

 Browse the framework at ScaledAgileFramework.com

8/15/12

4



#1 Scaling Value Not Everything is a User Story

8/15/12

5


Agile Teams Know User Stories

  The Team Backlog consists primarily of the user stories that express the needs of the stakeholders

  User stories are negotiable, expressions of intent

  Expressed in user-voice form:

A great invention, User Stories replace traditional requirements expression


User Story Scaling Problems

  If a large program requires –  10 teams that plan two PSIs at a time, about 10 weeks apart –  If each team averages 10 stories per two week iteration, then

1,000 stories must be elaborated –  How can an enterprise reason about 1,000 things? (On just

the one program!)

–  And if we are about half done (500 stories), what do we actually have working, and how would we describe that to our customer?

  And –  Even if I know 500 things that “as a <role> I can <activity> so

that <business value>”, can do What Features does the system offer and what Benefits does each provide? What is the larger purpose here?

Billions and billions of stories

8/15/12

6


Features Fill the Program Backlog

  The term “Feature” is an industry-standard term familiar to Marketing and Product Management.

  Features are identified, prioritized, estimated, and maintained in the Program Backlog.

  Features can be expressed as a short phrase describing the feature, along with its benefits.

A Feature is a service that fulfills a user need


Actively Manage Backlogs (Queues)

  Backlogs are a form of queue (If items are committed, then it is a queue)

  The longer the queue, the slower the delivery (Little’s Law)

  Operating at high levels of utilization increases variability

  For fast, and predictable results:

Reinertsen, Principles of Product Development Flow, 2009.

•  Keep the backlogs short and uncommitted

•  Limit WIP to keep planned utilizations at 80% or below

8/15/12

7


Epics and the Portfolio Backlog

 Business Epics are customer-facing solutions

 Architecture Epics are technology solutions which enable the business needs, improve operational efficiencies, or drive innovation

 Epics are identified, prioritized, estimated, and maintained in the Portfolio Backlog

 Work-in-progress limits are set to minimize the number of unfinished Epics at any given time. They are managed through a Kanban system.

 Epics often cut across teams, releases, programs, and systems

 Epics can be expressed in any form to communicate the intent of the initiative (a business case, prototype, etc.)

Epics describe large-scale development initiatives which are the highest level expression of a business

or technology need


“Cover your eyes”…Enterprise Backlog Technical View

Realized by Realized by

0,1 1..* 0,1 1..*

Is one of

Constrained by

0, 1 1..*

Realized by

Done when passes

1..*

1

1..* 0..*

Compliant when passes

0..* 0..*

Is one of Is one of

1..*

1

0..*

Done when passes

1

Source: 2011, Leffingwell, D. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. © Pearson Education

8/15/12

8


#2−Scaling Team and Timebox No Team is an island


‘Tis far better to have agile teams than non-agile teams, BUT   How do we know what they are doing?

  How do we know how well they are performing?   How do we manage interdependencies?

  How do we know if they are working to a common mission?   How do we know we are getting the benefits for the enterprise? How can we harness all that new found energy and entropy?

The Problem with “Pockets of Agility”

The Agile, Twelve Tribes of Israel Problem:

There is more value created with overall alignment than with local excellence. – Don Reinertsen.

8/15/12

9


Everybody Must Be on the Agile Train

Waterfall Doesn’t Work

delay

Planned release

MRD PRD SRS Dev Drop 1 to QA

Drop 2 to QA

Test drop 1

Release docs

Test drop 2

Ports, certs

Actual release

Agile Works Better

Iterate Iterate Iterate

Release docs

Ports, certs

Iterate Iterate Iterate

Mixing doesn’t work

What do we integrate here?

PSI


But Cadence Alone is Not Enough

Planned system release date

…....time spent thinking you are on track……. Integrate and slip!

System

External Release

External Release

External Release

PSI

PSI

Iterate Iterate Iterate Iterate Iterate Iterate

Iterate Iterate Iterate Iterate

PSI


Release docs

Port and certs

Port and certs

Release docs

Release docs

8/15/12

10


Synchronize to Assure Delivery

First PSI Second System PSI or Release

Sys 1 Sys 2 Sys 3 Sys 4 Sys 5 Sys 6 Sys 7 Sys 8




System Iterations

External Release

External Release

External Release

Release docs

Ports certs

Release Docs

Release Docs

Ports certs

Ports certs

PSI

PSI

PSI

Continuous Integration



System Team

Dev Teams


  Align teams to a common mission   Standardize iteration lengths; normalize estimating units   Use cadence and synchronization to manage R&D variability

  A fractal above the agile team. Same shape; similar behavior; different parameters

Solution: The Agile Release Train

Organize “agile release trains” wherever you have a number of teams provding continuous value delivery

Agile Release Train delivers solutions

NFRs Iterations Iterations

NFRs

NFRs

Agile Teams

Product Owner

Scum/Agile Master

Developers & Testers

Team

Bac

klog

Team

Bac

klog

Iterations Iterations

Stories

Stories

Pla

n

Dem

o &

Ret

ro Stories fit in

iterations Implemented

by Tasks

Spikes are research and

design Stories

Pla

n

Dem

o &

Ret

ro D B

T

Team

Features and components

8/15/12

11


NFRs

NFRs

  Organized around enterprise value streams

  Create self-planning, self-organizing, self-managing agile programs

  Self-manages interdependencies amongst teams   Full, system-level solutions available every 8-10 weeks

The Agile Release Train

H

H

H

H

Agile Teams

Product Owner

Scum/Agile Master


Team

Bac

klog

Team

Bac

klog

Iterations Iterations

Stories

Stories

Pla

n

Dem

o &

Ret

ro Stories fit in

iterations Implemented

by Tasks

Spikes are research and

design Stories

Pla

n

Dem

o &

Ret

ro D B

T

Team

Features and components


Separation of Concerns

Agile Release to Market Process

Asynchronous Collaborative

Agile Development Train Process 7/1/2011 4/1/2011 1/1/2011 10/1/2011 7/1/2011

Key Customer upgrade

Possible New product

PSI 5 PSIPSI 3 PSI1

Customer preview Docs and

certs

General Availability Firewall

Release Release

Docs and certs

Scenario A: Release less frequently than cadence

8/15/12

12


Release Whenever You Like

Scenario B: Release on cadence

Scenario C: Release more frequently than cadence


What Is a Release Train, Really? A Fractal.

Team

Plan

Commit

Execute

One sprint (2 weeks)

Product Owner

Scum/Agile Master

5-10 teams

One PSI (8-10 weeks)

Execute

Team

8/15/12

13


What is a PSI, Really?

Value   Accumulates small

increments into newsworthy value

  Releasable, or released, or not, announced or not

  Value that can be planned, measured and assessed with strategic feedback

Timebox   Makes planning

routine; lowers planning transaction costs

  Limits deviation from plan to a single interval

  Suitable for internal roadmapping and external commitments

A strategic quantum of value and timebox


Scaling Fast Feedback with a System Team

The System Team brings system assets together early and often, allowing fast feedback with objective evaluation

NFRs

NFRs

NFRs NFRs

System Team Feature

Nonfunctional Requirement

Prog

ram

Back

log

Roadmap

Vision

Product Management

Release Management

Shared

Team

Bac

klog

Agile Teams

Product Owner

Scum/Agile Master


Team

Bac

klog

Team

Bac

klog

Iterations

Stories

Stories

Pla

n

Dem

o &

Ret

ro D B

T

Release Planning

Stories

Pla

n

Dem

o &

Ret

ro

  Build/supports development infrastructure

  Full system integration and end to end testing

  Integration with third party components

  Program demos   Interface to deployment

8/15/12

14


Scaling Tracking: Features, Not Just Stories

Understand completeness of each feature compared to plan at any point in time

" Automatically compiled from number of stories completed/stories remaining in agile project management tooling

" Facilitates decisions of what changes might be necessary to successfully deliver the PSI

70

50

45

20

30

60

20

30

26

20

80

30

40

40

40

62

40

33

28

30

0 10 20 30 40 50 60 70 80 90

Feature 1

Feature 2

Feature 3

Feature 4

Feature 5

Feature 6

Feature 7

Feature 8

Feature 9

Feature 10 PLAN

ACTUAL

100

Plan Actual - if within 15% Actual - if >15% behind

Percent Complete


Scaling Improvement: Inspect and Adapt

Rel

ease

Pla

nnin

g

  Establish accountability   Create new stories   Specify measurable results   Set achievable deadlines   Monitor progress

Program-level Root Cause Analysis/ Improvement Story Workshop. Every PSI

PSI |

Rel

ease

I&A

8/15/12

15


#3−Scaling Design: Emergent design meets intentional architecture

Some things that simply emerge, may turn out to be very ugly creatures indeed


Intentional Architecture

For systems of scale, some intentional Architecture is necessary

 Excessive redesign and refactoring of big systems drives bad economics and slows time-to-market –  Drives rework for large numbers of teams –  Potential impact on deployed systems/users

–  Some use cases can and should be anticipated

  Plus: Many drivers for system and enterprise architectures arise outside the purview of individual agile programs –  Mergers and acquisitions –  New, cross-cutting user patterns

–  Common architectural constructs for usability, extensibility, performance and maintenance

8/15/12

16


Change, Challenge and Opportunity Drive Architecture Epics Large technology initiatives, that cut across:

–  Time – affecting multiple releases

–  Scope – affecting multiple products, systems, services, or solutions

–  Organizations – affecting multiple teams, programs, business units

Where do they come from? –  New product or service opportunities. –  Mergers/acquisitions –  Changes in technologies –  Problems within the existing solution set, cost. –  Architectural governance: usability, extensibility,

performance, etc. –  Common infrastructure;

avoid duplication of effort

•  UI framework for porting existing apps to mobile devices

•  Industry security standard to lower data purchasing costs

•  Support 64 bit back office servers


Intentional Architecture

V0.81

8/15/12

17


  Principle # 1 ─ The teams that code the system design the system

  Principle # 2 ─ Build the simplest architecture that can possibly work

  Principle # 3 ─ When in doubt, code it (or model it) out   Principle # 4 ─ They build it, they test it   Principle # 5 ─ The bigger the system, the longer the

runway   Principle # 6 ─ System architecture is a role

collaboration   Principle # 7 ─ There is no monopoly on innovation   Principle # 8 ─ Implement architectural flow

Principles of Agile Architecture


# 8−Implement Architectural Flow

  Provide an agile framework for system architects. They must be agile, too.

  Drive incrementalism in architectural refactoring

  Make architectural work in process visible   Establish WIP limits to control queue sizes,

avoid overload and assure product development flow

  Drive an effective collaboration with the development teams

8/15/12

18


4. Implementa,on   Ownership transi8ons   Teams begin implemen8ng at

release planning boundaries   Teams break epics into

features   Architect support on “pull”

basis

Problem/Solu8on Needs Iden8fica8on

Evalua8on Architecture Team Ownership

Implementa8on Development Team Ownership

Agile Release Trains

WIP Limit

Release planning boundary

Innova,on feedback

Ac8vi8es:   Effort size es8mate   Value size es8mate   Investment theme

alignment

Authority approves epic   Meets

threshold criteria

Architect Team Pulls Epic   Lead architect

assigned

Product/ Technology Council Approval

1. Funnel   Technology roadmap   Disrup8ve technology   Solu8on problem: compa8bility

speed, size, security, usability,   Common infrastructure/duplicate

investment

2. Backlog   Refine

understanding   Est. cost of delay   Refine effort est.   Rela8ve ranking

3.Analysis   Design alterna8ves  Modeling   Development

collabora8on   Solu8on/product management

collabora8on   Business case

WIP Limit

PSI 1 PSI 2 PSI 3 PSI 4

WIP Limit


WIP Limit

System Architect Design

Spike

Tech lead/

architect

Architectural Epic Kanban System


#4−Scaling Portfolio Management Addressing legacy mindsets

Portfolio Vision

8/15/12

19


“widget engineering” “order taker mentality”

Epic based portfolio planning

Intense development collaboration

“Maximize utilization” “Get it done”

Time boxing WIP Limits

Fix resources short term only

“Control through milestones/data”

“plan out a full year of projects”

Control through empirical release

increments Rolling wave release

planning

From:

To:

Baker and Thomas, Establishing an Agile Portfolio to Align IT Investments with Business Needs. DTE Energy Case Study, Agile, 2009

Changing Legacy Mindsets:

The Problem with Legacy Mindsets


Eight Transformational Patterns

Legacy Mindset Lean-Agile Pattern #1 Too Many Projects Limiting WIP with Kanban #2 Detailed Project Plans Lightweight Business Cases #3 Annual Funding Incremental Funding #4 Centralized Annual

Planning Decentralized Rolling-Wave Planning

#5 Work Breakdown Structure

Agile Estimating and Planning

#6 Projects Agile Release Trains #7 PMBOK Agile Project Management #8 Waterfall Milestones Fact-Based Governance

We need a transformation “roadmap”, one that builds an Agile PPMO on Lean-Agile Principles

Legacy PPMO Agile PPMO

8/15/12

20


A Portfolio Kanban System

4. Implementation   Ownership transitions   Teams begin implementing at

release planning boundaries   Teams break epics into features   Analyst support on “pull” basis

Agile Release Trains

WIP Limit

Release planning boundary

Innovation feedback

Activities:   Effort size estimate   Value size estimate   Investment theme

alignment

Authority approves epic   Meets

threshold criteria

Business analyst pulls Epic   Lead analyst

assigned

Portfolio Management

Team/ Product Council

Approval

1. Funnel   Product roadmap   New business opportunity   Cost savings   Solution problem

2. Backlog   Refine

understanding   Est. cost of delay   Refine effort est.   Relative ranking

3.Analysis   Solution alternatives   Collaboration

-  Solution management -  Architects -  Market/sales/business -  Development

  Weighted rank   Business case

WIP Limit


WIP Limit


WIP Limit


The Agile PPMO

The Agile PPMO enables and fosters lean and agile practices for business results

•  Limiting Work in Process

•  Lightweight business cases

•  Incremental funding •  Decentralized rolling

wave planning

•  Agile estimating and planning

•  Agile Release Trains •  Agile Project

Management

•  Fact-based assessment

•  Agile milestones

8/15/12

21


Investment Themes

  Can be at the enterprise or business unit level   Done as part of the budgeting process with a

lifespan of 6-12 months   Governed by a Portfolio Management Team

  Not managed as a backlog in priority order. Rather, investment themes are managed as a percentage of available resources.

  Not “testable” – ROI is not measured at this level

Investment Themes represent the budget allocations within a portfolio to systems, products, applications, and

services


Program Level

Por\olio Level

Program

Agile Release Trains (con8nuous flow programs)

Waterfall programs

Architectural Runway

Portfolio Vision

Portf

olio B

acklo

g

Implementa,on Verifica,on

Design Requirements

Implementa,on Verifica,on

Design Requirements

Program

Por\olio Level

Investment Themes

Budgets

Managing Budgets and Investment Themes

8/15/12

22


#5−Scaling Leadership Your enterprise can be no leaner than your executives thinking


The Problem: Let’s Get Real   Managers, directors, and executives are not

“chickens” in the enterprise.   They are “pigs”. (And really big ones at that.)   To be successful, our expectation must not

be that they: a) simply don’t interfere, or b) simply understand, or c) are even simply supportive

  Instead, they must LEAD. After all, that’s what leaders do

  Our job Inform, Educate, and Inspire them to their new Lean|Agile leadership mission

8/15/12

23


Lean Thinking Foundation

Product Development Flow

1.  Take an economic view

2.  Actively manage queues

3.  Understand/exploit variability

4.  Reduce batch size 5.  Apply WIP Constraints 6.  Flow with uncertainty

Cadence and Synchronization

7.  Apply fast feedback 8.  Decentralize control

Derived from: Toyota Production System (2004) Larman and Vodde (2009)

Reinertsen (2009)


Lean-thinking Manager-teachers

  Management is trained in lean thinking - bases decisions on this long term philosophy

  Management understands and teaches lean and agile behaviors

  Management is trained in the practices and tools of continuous improvement

Source: Larman and Vodde, 2009

8/15/12

24


  Inform –  Make sure the agile working group executes an

effective communication plan   Educate Management

–  Suggested Readings •  Principles of Product Development Flow. Reinertsen •  Agile Software Requirements: Lean Requirements Practices for

Teams, Programs and the Enterprise. Leffingwell. •  Lean Software Development: An Agile Toolkit. Poppendieck.

–  Have them attend a lean leadership workshop you hold   Inspire

–  Expect and challenge them to lead, not follow

Your Job: Inform, Educate, Inspire


  Book: Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison Wesley. 2011

  SAFe Certification: Chicago. October 23-27, 2012. (see ScaledAgileAcademy.com)

  Blog: ScalingSoftwareAgilityBlog.com   Framework: ScaledAgileFramework.com   Website: see DeanLeffingwell.com

Questions?

Documents

Agile2012 rev4.pptx