Lean Development Practices for Enterprise Agile

AW9
Concurrent Session
11/7/2012 3:45 PM

"Lean Development Practices for
Enterprise Agile"

Presented by:
Alan Shalloway
Net Objectives

Brought to you by:

340 Corporate Way, Suite 300, Orange Park, FL 32073
888‐268‐8770 ∙ 904‐278‐0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com

Alan Shalloway
Net Objectives
With more than forty years of experience, the founder and CEO of Net Objectives Alan
Shalloway is an industry thought leader in lean, Kanban, product portfolio management, Scrum,
and agile design. Alan helps companies transition enterprise-wide to lean and agile methods,
and teaches courses in these areas. He is the primary author of Lean-Agile Software
Development: Achieving Enterprise Agility, Design Patterns Explained, Lean-Agile Pocket Guide
for Scrum Teams, and Essential Skills for the Agile Developer. Co-founder and board member
for the Lean Software and Systems Consortium, Alan is a popular speaker at prestigious
conferences worldwide.

Agile
Lean Development Practices for
Enterprise Agile
© copyright 2010. Net Objectives, Inc.1

© Copyright 2012 Net Objectives, Inc. All Rights Reserved


2

Lean for Executives
Product Portfolio Management
Business Product Owner

Business

ASSESSMENTS
CONSULTING
T RAINING
COACHING

Lean
Enterprise
Manage
ment

Team
technical

process

Lean-Agile
Kanban / Scrum
ATDD / TDD / Design Patterns

Lean Management
Project Management


3


4

We have got
tog evah eW
it backwards
sdrawkcab ti

and upside-edispu dna
down.
.nwod

Agility
is where you have

Predictability
and faster realization of

Business Value

5

You need Agility for:
– Speed
Faster realization of Business Value
– Value
Get more (business value) from current
resources (capacity)

– Productivity
Higher productivity of business value delivery
(measurable)

6

Agility
is about

Business Value
Increments not
Development
Cycles

7

Scaling
Agility Agility at Scale
using methods
that work at
team level to
get teams to
work together

Focus on entire value
stream

Shortening cycle time
Avoid excessive WIP at

product level

8

How Blockages Occur in Value Stream
Not Using
MMFs

Concept
Not Involved

Regional Coordinators

Business Leaders

Trainers & Educators

Product Managers

Business

Customers

Consumption

No Big
Customer
Picture

Product Champion(s)

Too Many
Capabilities
Selected

New
Requirements

Software
Product
Product Related

Doesn’t Do
Product
IncrementalRelated
Product Related
Development

Not Involved
Ops & Support

Software
Release

During Build

Poor
Shared Components
Engineering
Shared Components
Practices

Development


9

PORTFOLIO

THE VALUE STREAM
c h u n k i n g

s l i c i n g

BUSINESS DISCOVERY BUSINESS DELIVERY
Business
Priority
Decision
Is there enough
business value?

Identify potential
capabilities

Business
Planning

Business
Readiness

Decision
Is it technically
feasible?

Define
increments as
MMFs

Ready
to Pull

Incremental
Development

Incremental
Deployment

Decision
Is an SME
ready?

Set acceptance
criteria and
feature sequence

Support &
Feedback

Decision
Is it ready
to release?

Build iteratively
Scrum / Kanban / Hybrid
ATDD and Emergent Design


10

economics of responsiveness
Payback
Period

Profit
Period

Cash flow

Investment
Period

Time
Breakeven
First Release

from Denne and Cleland-Huang. Software by Numbers

11

Staged Releases
Payback
Period

Cash flow

Investment
Period

Profit
Period

Release 1 Net Return

Time
First
Release


12

Staged Releases
Profit
Period

Payback
Period

Cash flow

Investment
Period


Time
Second
Release


13

staged releases
Profit
Period

Investment
Period

Payback
Period

Cash flow

Total Return

Time
Breakeven
Point
Investment


14

Increased Profit

Cash flow

Staged Releases

Breakeven

Single
Release
Time

First Release

Requires a focus on sustainability of
realizing value by attending to
architectural roadmap of product line

15

Incrementally
Realizing Business
Value

value

risk

What risks do these approaches lower?
risk

Evolving the
System

value


16

Deliver
in Stages when possible
focusing on the known, valuable features
gives greater certainty
produces greater value
lowers risk of mis-building and over-building


17

Agile Advantage
 Work on highest value features first
 Allows for discovery and clarity of customer



requirements
Quicker time to market
Ability to not build features of lower value

Goal is to deliver business value
incrementally and frequently!!

18

ACH
(automated clearinghouse)

ACH is our electronic network to
clear credit and debit transactions
with other institutions
Primary Objective: By Year’s
end, process 100% of all loans
Primary Objective: Reduce the
number of checks required by 25%
Key Feature: 0.0001% error
rate


19

Business Backlog for ACH
Goal: 100% of Loans

Loans

25% Reduction in Checks

Checks

High

Low


20

Goal: 100% of Loans


Loans

Checks

Outbound

Inbound

1

4

Withdrawals

Terminations

2

High

3

Low


21

Business Capabilities for ACH
BF - Web

MMF – Web & Call in

Outbound - Loans
Manage Bank Info
Redirect from chk to ACH
Bank Notify
Update Reconciliation
Cover Funds
Confirm ?
Analytics & Reporting
Web

•
•

What are the business
capabilities needed for
ACH?
What are the sources?
How can we group them
for highest value?

Call in

IVR

•

Paper

22

Goal: 100% of Loans


Loans

Checks

Outbound

Inbound

MMF
Web |1
Call in

Withdrawals

4

Terminations

2

3
BF
IVR

High
Release 1

BF
Paper

Low
Release 2

Release 3
23

Business Features to User Stories
MMF – Web & Call in

Outbound - Loans
Manage Bank Info
Redirect from chk to ACH
Bank Notify
Update Reconciliation
Cover Funds
Confirm ?
Analytics & Reporting
Web

User Story
Manage banking
info for a Webinitiated
outbound ACH
transaction

Call in


24

Goal: 100% of Loans

Loans

Outbound
MMF
Web |1
Call in

Beware!


Checks
Building Manage Bank Info as a
standalone component for everything is
a system evolution!
Inbound
Withdrawals
Terminations
Might be more efficient from an IT
perspective, but it is NOT from a
4
2
business value perspective!!! 3
BF
IVR

Manage
Bank Info

High
Release 1

BF
Paper

Low
Release 2

Release 3
25

high

ALWAYS DRIVE FROM BUSINESS VALUE
High ROI

value to the business

Cost of Delay

low

Cost of Risk

release 1

release 4

time


26

Bus Pri

Bus Plan

Bus Rdy

BUSINESS DELIVERY

RTP

It
0

BUSINESS DISCOVERY

Iter Dev

Inc Depl

Spt & Fdbk

Value
Time box
Team

Scale / Scope

Portfolio

Book of Work
Rolling Releases
Level 1,2, & 3

Program

Program Backlog
Releases
Multiple Teams

Project

Product Backlog
Iterations
Whole Team

27

If you can’t see
it, you can’t

manage it.


28

Request

Design

Approve

Review

Reqts

Sign Off

Code

Test

Analysis

Deploy

1. Identify the actions taken in the value stream


29

Request

Approve

Reqts

Sign Off

Analysis

0.5 hrs

8 hrs

160 hrs

8 hrs

100 hrs

Design

Review

Code

Test

Deploy

120 hrs

2 hrs

280 hrs

240 hrs

8 hrs

2. What was the real time from start to finish of the action?


30

Request

Approve

Reqts

Sign Off

Analysis

0.5 / 0.0 hr

.1 / 7.9 hrs

60 / 100 hrs

1 / 7 hrs

40 / 60 hrs

0.5 hrs

8 hrs

160 hrs

8hrs

100 hrs

Design

Review

Code

Test

Deploy

40 / 80 hrs

2 / 0 hrs

80 / 200 hrs

40 / 200 hrs

3 / 5 hrs

120 hrs

2 hrs

280 hrs

240 hrs

8 hrs

3. What was the average time working on this vs working on other things?


31

Request
0.5 / 0.0 hr

Approve
320 hrs

.1 / 7.9 hrs

Reqts
80 hrs

60 / 100 hrs

320 hrs

1 / 7 hrs

160 hrs

8 hrs

0.5 hrs

Sign Off

Analysis
80 hrs

8hrs

40 / 60 hrs
100 hrs

80 hrs

Review

Design
40 / 80 hrs
120 hrs

160 hrs

2 / 0 hrs
2 hrs

Code
80 hrs

80 / 200 hrs
280 hrs

Test
80 hrs

40 / 200 hrs
240 hrs

Deploy
80 hrs

3 / 5 hrs
8 hrs

4. Identify time between actions


32

Request
0.5 / 0.0 hr

Approve
320 hrs

.1 / 7.9 hrs

Reqts
80 hrs

60 / 100 hrs

320 hrs

1 / 7 hrs

160 hrs

8 hrs

0.5 hrs

Sign Off

Analysis
80 hrs

8hrs

40 / 60 hrs
100 hrs

80 hrs

Review

Design
40 / 80 hrs

160 hrs

2 / 0 hrs
2 hrs

120 hrs

20% rejected
Repeat 1X

Code
80 hrs

Test

80 / 200 hrs

80 hrs

40 / 200 hrs
240 hrs

280 hrs

Deploy
80 hrs

3 / 5 hrs
8 hrs

65% defective
Repeat 3X

5. Identify any loop backs required

33

22 September 2012

Request
Request
0.5 // 0.0 hrs
0.5 0.0 hrs

Reqts
Reqts

Approve
320 hrs

.1 / 7.9 hrs

80 hrs

hrs
60 / 100 hrs

320 hrs

1 / 7 hrs

160 hrs

8 hrs

0.5 hrs

Sign Off
Off

Analysis
Analysis
80 hrs

40 / 60 hrs

8 hrs
8hrs

100 hrs

80 hrs

Review
Review

Design
Design
40 / 80 hrs

160 hrs

2 / 0 hrs
2 hrs

120 hrs

20% rejected
Repeat 1X

Code
80 hrs

80 / 200 hrs

Test
Test
80 hrs

Deploy
Deploy

40 / 200 hrs

80 hrs

240 hrs

280 hrs

3 / 5 hrs
8 hrs

65% defective
65% defective
Repeat 3X
Repeat 3X

PCE =

509 hrs
hrs

= 14.9%

3433 hrs
hrs
5. Identify any loop backs required
Avg Time Worked
Time Worked
6. Calculate Process Cycle Efficiency:
Total Cycle Time
Total Cycle Time

34

how much of what you do is

valuable?
rework?


35

What Work Do You Do?
Getting
Requirements

Design

Re-doing
requirements

Planning
Collaboration

Working from old
requirements

Programming
Testing

Integration

“Fixing” bugs

Deployment
Documentation

Training

What percentage of your time do you
spend on the left?
Write it down.

Building
unneeded
features

“Integration”
errors


Overbuilding
frameworks
Essentially
duplicating
components

36


37


38

What Causes Delays?







Working on too many things
Waiting for people
Not appreciating the cost of delay
Large batches of work that have different stages
Complexity


39

Request
0.5 / 0.0 hrs

Approve
320 hrs

.1 / 7.9 hrs

Reqts
80 hrs

60 / 100 hrs

320 hrs

1 / 7 hrs

160 hrs

8 hrs

0.5 hrs

Sign Off

Analysis
80 hrs

8hrs

40 / 60 hrs
100 hrs

80 hrs

Review

Design
40 / 80 hrs

160 hrs

2 / 0 hrs
2 hrs

120 hrs

20% rejected
Repeat 1X

Code
80 hrs

Test

80 / 200 hrs

80 hrs

Deploy

40 / 200 hrs
240 hrs

280 hrs

65% defective
65% defective
Repeat 3X
Repeat 3X

80 hrs

3 / 5 hrs
8 hrs

3433 – 509 = 2924

Which gives a better return?
Getting better
at what you do

Eliminating
delays between
what you do

40

Getting the
right people
to work on
the right
thing at the
right time

Is more important

than doing the


steps faster

41

Here’s
a spot!

And
another!


42

Consider the Software Value Stream
Concept
Regional Coordinators

Business Leaders

Trainers & Educators

Product Managers

Business

Customers

Consumption

Customer
Product Champion(s)

Capabilities

Managing
here

New
Requirements

Software
Product

Ops & Support

Software
Release

Product Related
Shared Components
Product Related
Product Related

Shared Components

Development

Reduces
induced
waste here

Product Portfolio Management

43

what structure
to use?


44

Legacy Organization:
Matrix Resources to Projects

Project 1
Project 2
Project 3
Project 4
Project N


45

Let’s Create a Pilot Project
Project 1

Project 2
Project 3
Project 4

%

Project N

Experience has shown that if you
create a cross-functional colocated team you will improve 3x
without changing your process.
46

Business Analyst, Architect, Usability Expert,
Developer, Developer, Tester, Project Manager
Expert

Seeing the Parts


47

Role of Team in Bigger Picture


48

VALUE
Business

Lean
Enterprise
Team

Manage
ment

FLOW

MAKE

49

MAKE
Team
technical

INCREMENTAL DELIVERY
CREATIVE PROBLEM SOLVING
QUALITY BUILT IN

50

VALUE
PRIORITIZATION
BUSINESS ITERATIONS
RELEASE PLANNING

Business

technical


51

FLOW
Value Stream Visualization
Impediment Impact
Workflow as Process

ACCOUNTABILITY

technical
Manage (limit) queues
Visual controls
Manage flow (process)

Manage
ment


52

Common Theme
Creating the
bigger team
- pan team


53

Case Study 3: Coordinating
Teams
Background

• Multiple teams
• Specialized
• Each team completed sprints in two weeks
…but value not delivered for months
…and then with challenges


54

Business
Priority

Business Business
Planning Readiness

Ready
to Pull

Incremental
Development


Incremental Support &
Deployment Feedback

55

Business Business
Planning Readiness

Ready
to Pull

Incremental
Development
Incremental
Development
Incremental
Development


Integration Train

Business
Priority

Shared Backlog

Incremental Support &
Deployment Feedback

56

Overall Team Organization

Product Line A
applications

Product Line B
applications

Component
team for line B
applications

Component
team for line A
applications

System-Wide
Component Team

57

Teams on a Project

Product Line A
applications

Product Line B
applications

Component
team for line B
applications

Component
team for line A
applications

System-Wide
Component Team

58

Focus on time
over the

entire value
stream.


59

MMF

MMF
Split MMF
Teams work on
according to
their parts
Teams

Eventually integrating
Teams work on
them until done
their parttogether
Teams split according
to components

Feedback times for:

Progress bar

Team
2 weeks
Across teams 6 weeks
Customer
8 weeks


60

MMF

MMF
Split MMF
into sub-features

Integration still required
After one iteration, teams
but takes much less time
integrate their components
Development teams split
Teams work on
according to part
their components

Feedback times for:

Progress bar

Team
2 weeks
Across teams 2 weeks
Customer
2 weeks


61

Case study
Coordinating
Multiple
Business
Stakeholders
with Multiple
Team

62

Case study
Coordinating
Multiple
Business
Stakeholders
with Multiple
Team

63

The Simple Case

1. Define
Business
capabilities

5. Assign to team backlog
4. Create high level stories
2. Create MMFs
Team Product Backlog
3. Prioritize MMFs

A

A1

A2

A1

A1aA1b A1c
A1d

Team 1

A2

Stakeholders

Architecture / Technical Leads
Product Owners
Development teams

64

A Harder CasePrioritize MMFs
3.

1. Define
Business
capabilities

2. Create
MMFs

4. Create high
level stories

A2

A1

Team Product Backlogs

A1aA1bA1c
A1d

A2

A

A1

5. Assign to team
backlogs

A2a A2c
A2b

Team 1

Team 2

Team 3

Team 4

Stakeholders

Product Owners
Development teams

65

Normal Problem – We Call it Tough
A


Team 1

B
Team 2

C

Team 3

D

Team 4

E

Stakeholders

Product Owners
Development teams

66

Product Owner Role Stretched too Thin

A
B
C
D
E

Stakeholders

??
?? ?
?

Team 1

Team 2

Team 3

?
Team 4

 Product Owners do project management
 Stakeholders can’t go to one source to see what to do
 Teams have to coordinate with themselves
Product Owners
Development teams

67

Product Managers and Product Owners

A

Team 1

B
Team 2

C

Team 3

D
E

Product Manager:
• represents the stakeholders
• prioritizes MMFs
• breaks MMFs into components

Stakeholders

Product Owner:
• acts as SME to team
• represents team to product managers Team 4
• breaks MMFs into components with Prod Mgrs
• breaks components into stories

Architects Architecture / Leads Leads
/ Technical Technical
Product Managers
• responsible for technical dependencies across teams
Product Owners
• provide high level costs to Product Managers
Development teams


68

Agile At Scale
1. Define
Business
capabilities

A

5. Assign to team backlogs

3. Prioritize MMFs

2. Create
MMFs

A1

B1
A1

A2

B2

B

B1

B2

B3
C1

C

C1

C2


B1a
B1b
B1c

Team 1

A1a A1c
A1b A1d
Team 2

B2a B2c
B2b
B3aB3b
B3c

Blocked

B3

4. Create high
level stories

A2

Team 3

Team 4

C2

Stakeholders

Product Managers
Product Owners
Development teams

69

Holistic Approach
Visibility
Systems Thinking
Flow
Self-organization with bigger view

key points


70

Lean in a nutshell
Achieve
higher quality
lower cost
faster delivery

by attending to time
Self-organization & leadership are

important. An holistic view is essential.

71

Transitions Require
Why and How
Understanding the why may get you
started
Understanding the how will help
overcome the fear
The perceived value must be greater
than the fear

72

T E L L I N G P E O P L E “J U S T D O I T ”
JU S T D O E S N ’T D O I T


73

Business

Enterprise
Agility
Team
technical

Manage
ment


74

Lean-Agile: Evolving Agility
∞
Agility

Continually evolving
Sustaining, not improving

Maturation

Declining
Business

Lean
Thinking

Low

Team

Mgmt

Time (years)

Iterative  Flow  Highest Business Value

75

Lean-Agile: Evolving Agility
Where are you currently?

∞
Agility

Business
Management

Team

Continually evolving
Sustaining, not improving

Maturation

Declining

Low
Time (years)

Iterative  Flow  Highest Business Value

76

Company / Organization

Lines of Business / Divisions

Departments / Programs

Projects / Releases

Lean

Business & Engineering
Practices

Business Strategy /
Business Architecture

– all skills needed to define,
build, validate, and deploy

Continuous discovery and
development

Business Portfolio Planning

Whole Teams

Business Driven Software
Development

Automated Regression Tests
Continuous Integration
ATDD – Acceptance Test Driven Development
Continuous Standards Improvement

Iterative development

Scrum
Lean Software
Development

XP / Iterative
Kanban

Stage 1
Stage 2
Stage 3

Enterprise Agility

77

Net Objectives’ Talks At Conference
Monday

 8:30-12:00pm Eight Steps to Kanban. Ken Pugh

Tuesday

 8:30-12:00pm Scaling Agile with the Lessons of Lean Product Development
Flow. Alan Shalloway
 1:00-4:30pm Design Patterns Explained: From Analysis Through
Implementation. Alan Shalloway

Wednesday

 3:45-5:00 Lean Development Practices for Enterprise Agile. Alan Shalloway
Thursday
 Keynote 1245-2:00pm Form Follows Function: The Architecture of a
Congruent Organization. Ken Pugh

Register at www.netobjectives.com/register for slides & more

_s

78

Thank You!





Register at www.netobjectives.com/register
See www.netobjectives.com/resources
Contact me at alshall@netobjectives.com
Twitter tag @alshalloway


copyright © 2010 Net Objectives 79
Inc.

Q
U
E
S
T
I
O
N
S
?

Lean for Executives
Product Portfolio
Management
Business Product
Owner

Business

ASSESSMENTS
CONSULTING
T RAINING
COACHING

Lean
Enterprise
Manage
ment

Team
technical

For more info on free resources see:
www.netobjectives.com/resources

process

Lean-Agile
Kanban / Scrum
ATDD / TDD / Design Patterns

Lean Management
Project Management


80

Lean Development Practices for Enterprise Agile

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (15)

Similaire à Lean Development Practices for Enterprise Agile

Similaire à Lean Development Practices for Enterprise Agile (20)

Plus de TechWell

Plus de TechWell (20)

Dernier

Dernier (20)

Lean Development Practices for Enterprise Agile