Agile2012 rev4.pptx

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

Dean Leffingwell
deanleffingwell@gmail.com
DeanLeffingwell.com
ScalingSoftwareAgilityblog.com

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

Myths and Ideologies

1.  Scaling Value: Not everything is a
Agile:
User Story •  Myths
2.  Scaling Team and Timebox: No team •  Ideologies
•  Misperceptions
is an island •  Legacy Mindsets
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


Context for Scaling Lean and Agile

Respect for Product Continuous
People Development Improvement
Flow


Lean Goal: Speed, Value, Quality

The Goal of Lean:
Sustainably shortest
lead time
•  Best quality and value
  All we are doing is looking at the
timeline, from the moment the customer
gives us an order to the point where we
to people and society
collect the cash. And we are reducing
the time line by reducing the non-value
added wastes.
•  Most customer delight,
 

̶

Taiichi
Ohno

We need to figure out a way to deliver
lowest cost, high
software so fast that our customers
don’t have time to change their minds.
morale, safety
̶ Poppendieck
  Minimize delays, handoffs and non-
value added activities


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



#1 Scaling Value
Not Everything is a User Story


Agile Teams Know User Stories

A great invention, User Stories replace
traditional requirements expression

  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:


User Story Scaling Problems
Billions and
billions of stories
  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?

Features Fill the Program Backlog

A Feature is a service that fulfills a user need

  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.


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:

•  Keep the backlogs short and
uncommitted
•  Limit WIP to keep planned utilizations at
80% or below

Reinertsen, Principles of Product Development Flow, 2009.


Epics and the Portfolio Backlog

Epics describe large-scale
development initiatives which are the
highest level expression of a business
or technology need
 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.)


“Cover your eyes”…Enterprise Backlog
Technical View
Constrained by

0..* 0..*
1..*
Compliant
when passes 0..*
Is one of

Realized by Realized by Realized by
0, 1 1..* 0,1 1..* 0,1 1..*
1
Is one of Is one of
Done
when
passes

1..*

1 1
Done when
passes

1..* 0..*

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


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


The Problem with “Pockets of Agility”

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

The Agile, Twelve Tribes of Israel Problem:
‘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?


Everybody Must Be on the Agile Train

What do we
integrate here? Planned release

Waterfall Doesn’t Work
Release docs
Drop 1 Drop 2 delay
MRD PRD SRS Dev to QA to QA
Test Test
drop 1 drop 2
Ports, certs
Mixing doesn’t work

PSI Actual release
Agile Works Better
Release docs

Iterate Iterate Iterate Iterate Iterate Iterate

Ports, certs


But Cadence Alone is Not Enough

Planned system
release date

…....time spent thinking you are on track…….
System Integrate
PSI External Release and slip!
Release docs


Port and certs
PSI External Release
Release docs


Port and certs
PSI External Release
Release docs

Iterate Iterate Iterate Iterate


Synchronize to Assure Delivery

Second System
First PSI PSI or Release

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

External Release
Continuous PSI
System Integration
Team
Release docs

PSI Ports certs
Continuous External Release
Dev
Teams Integration
Release Docs


Ports certs

Continuous PSI
Integration External Release
Release Docs


Ports certs


Solution: The Agile Release Train
Agile Release Train delivers solutions

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

  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

Features and components
Product Owner
Team Backlog

Stories
Stories fit in
Demo & Retro

Scum/Agile iterations
Master
Plan

Implemented
by Tasks
Team

NFRs
Agile Teams
Stories Spikes are
Team Backlog

D B research and
Demo & Retro

T design Stories
Plan

NFRs Iterations Iterations
Developers & Testers


The Agile Release Train
  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

Features and components
Product Owner
Team Backlog

Stories
Stories fit in

Demo & Retro
Scum/Agile iterations
Master
H H
Plan

Implemented
by Tasks

Team
NFRs
Agile Teams
Stories Spikes are
Team Backlog

D B research and
Demo & Retro

design Stories
T
H H
Plan



Separation of Concerns
Scenario A: Release less frequently than cadence

Agile Release to Market Process

Asynchronous Collaborative

Release Release General Availability
Key Customer
upgrade Firewall

Docs and Docs and
Customer preview certs certs Possible
New product
PSI1 PSI 3 PSI PSI 5

7/1/2011 10/1/2011 1/1/2011 4/1/2011 7/1/2011

Agile Development Train Process


Release Whenever You Like
Scenario B: Release on cadence

Scenario C: Release more frequently than cadence


What Is a Release Train, Really? A Fractal.

One sprint (2 weeks)

Product Plan
Owner
Execute
Scum/Agile
Master
Commit
Team

One PSI (8-10 weeks)

Execute
Team
5-10 teams


What is a PSI, Really?

A strategic quantum of value and timebox

Value Timebox
  Accumulates small   Makes planning
increments into routine; lowers
newsworthy value planning transaction
  Releasable, or costs
released, or not,   Limits deviation from
announced or not plan to a single
  Value that can be interval
planned, measured   Suitable for internal
and assessed with roadmapping and
strategic feedback external
commitments

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

Shared
Roadmap   Build/supports
development
Program Backlog

Vision Release Planning
System
Feature
infrastructure
Team Backlog

Product Team
Management

Release   Full system integration
Nonfunctional
Management NFRs Requirement NFRs
and end to end testing
Product Owner   Integration with third party
Team Backlog

Stories

components
Stories
Demo & Retro
Plan

Scum/Agile
Master

NFRs
  Program demos
Agile Teams
Stories   Interface to deployment
Team Backlog

D B
Demo & Retro

T
Plan

NFRs Iterations


Scaling Tracking: Features, Not Just Stories
Understand completeness of each feature compared to plan at any
point in time

30 Plan
Feature 10 20 PLAN
Actual - if within 15% " Automatically
ACTUAL
Feature 9 26
28 Actual - if >15% behind compiled from
33
number of stories
Feature 8 30 completed/stories
Feature 7 20
40 remaining in agile
62
project
Feature 6 60
management
40
Feature 5 30 tooling
Feature 4 20
40
" Facilitates
Feature 3 40 decisions of what
45
changes might be
30
Feature 2 50 necessary to
Feature 1 70
80 successfully
0 10 20 30 40 50 60 70 80 90 100
deliver the PSI
Percent Complete


Scaling Improvement: Inspect and Adapt
Program-level Root Cause Analysis/ Improvement Story
Workshop. Every PSI

I&A
Release Planning

PSI | Release

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


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

#3−Scaling Design:
Emergent design meets intentional
architecture


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

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. •  UI framework for porting existing
–  Common infrastructure; • 
apps to mobile devices
Industry security standard to lower
avoid duplication of effort data purchasing costs
•  Support 64 bit back office servers


Intentional Architecture

V0.81

Principles of Agile Architecture

  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

# 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


Architectural Epic Kanban System
Problem/Solu8on
Needs
Evalua8on
Implementa8on

Iden8fica8on
Architecture
Team
Ownership
Development
Team
Ownership

1.
Funnel
2.
Backlog
3.Analysis
4.
Implementa,on

  Technology
roadmap
  Refine
  Design
alterna8ves
  Ownership
transi8ons

  Disrup8ve
technology
understanding
  Modeling
System Tech
lead/   Teams
begin
implemen8ng
at

Architect Design architect
  Solu8on
problem:
compa8bility
  Est.
cost
of
delay
  Development

Spike release
planning
boundaries

speed,
size,
security,
usability,
  Refine
effort
est.
collabora8on
  Teams
break
epics
into

  Solu8on/product
management
features

  Common
infrastructure/duplicate
  Rela8ve
ranking
collabora8on

investment
  Architect
support

on
“pull”

  Business
case
basis

Innova,on
feedback

WIP
Release

Limit
planning

boundary

WIP

Limit

PSI
1
PSI
2
PSI
3
PSI
4

WIP

Limit

Agile
Release
Trains

Ac8vi8es:

Authority
Architect
Team
Pulls
Product/

  Effort
size
es8mate
approves
epic
Epic
Technology

PSI
1
PSI
2
PSI
3
PSI
4

  Value
size

es8mate
  Meets
  Lead
architect

Council

  Investment
theme
threshold
assigned

criteria

Approval

alignment

WIP

Limit


Portfolio
Vision

#4−Scaling Portfolio
Management
Addressing legacy mindsets


The Problem with Legacy Mindsets

Changing Legacy Mindsets:

“Control through
“widget engineering” “Maximize utilization” milestones/data”
From: “order taker mentality” “Get it done” “plan out a full year of
projects”

Time boxing Control through
Epic based portfolio
empirical release
To: planning WIP Limits increments
Intense development Fix resources short Rolling wave release
collaboration term only planning

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


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

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 Decentralized Rolling-Wave
Planning Planning
#5 Work Breakdown Agile Estimating and Planning
Structure
#6 Projects Agile Release Trains
#7 PMBOK Agile Project Management
#8 Waterfall Milestones Fact-Based Governance
Legacy PPMO Agile PPMO


A Portfolio Kanban System

1. Funnel 2. Backlog 3.Analysis 4. Implementation
  Product roadmap   Refine   Solution alternatives   Ownership transitions
  New business opportunity understanding   Collaboration   Teams begin implementing at
  Est. cost of delay -  Solution management release planning boundaries
  Cost savings
  Refine effort est. -  Architects   Teams break epics into features
  Solution problem -  Market/sales/business
  Relative ranking   Analyst support on “pull” basis
-  Development
  Weighted rank
  Business case

Innovation
feedback
WIP Release
Limit planning
boundary
WIP
Limit
PSI 1 PSI 2 PSI 3 PSI 4

WIP
Limit

Agile Release Trains
Activities: Authority Business analyst Portfolio
  Effort size estimate approves epic pulls Epic Management PSI 1 PSI 2 PSI 3 PSI 4
  Value size estimate   Meets   Lead analyst Team/
  Investment theme threshold assigned
alignment criteria Product
WIP
Council Limit
Approval


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
•  Fact-based
assessment •  Agile Release Trains
•  Agile milestones •  Agile Project
Management


Investment Themes

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

  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


Managing Budgets and Investment Themes
Program

Porolio
LLevel

Porolio
evel

Portfolio Vision
Portfolio Backlog

Investment

Themes

Architectural Runway
Budgets

Program
Level

Agile
Release
Trains
(con8nuous
flow
programs)

Requirements

Requirements
Design

Program

Design
Implementa,on

Implementa,on
Verifica,on

Verifica,on

Waterfall
programs


#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


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) Reinertsen (2009)
Larman and Vodde (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 © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 46

Your Job: Inform, Educate, Inspire

  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

Questions?

  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


Agile2012 rev4.pptx

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Agile2012 rev4.pptx

Ähnlich wie Agile2012 rev4.pptx (20)

Mehr von drewz lin

Mehr von drewz lin (20)

Agile2012 rev4.pptx