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 ∙ [email protected] ∙ 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.

© Copyright 2012 Net Objectives, Inc. All Rights Reserved 1

Agile

© copyright 2010. Net Objectives, Inc.

Lean Development Practices for Enterprise Agile


Lean Enterprise

Business

Management

Team

ASSESSMENTS

CONSULTING

TRAINING

COACHING

Lean for Executives

Product Portfolio Management

Business Product Owner

Lean Management

Project Management Lean-Agile

Kanban / Scrum

ATDD / TDD / Design Patterns

technical process


tog evah eW

sdrawkcab ti

-edispu dna

.nwod

We have got

it backwards

and upside-

down.


Agility

Predictability

Business Value

and faster realization of

is where you have


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)


Agility is about

Business Value

Increments not

Development

Cycles


Scaling Agility

using methods that work at team level to get teams to

work together

Agility at Scale Focus on entire value

stream

Shortening cycle time

Avoid excessive WIP at

product level


Ops & Support

Customers

Shared Components

Shared Components

Product Related

Product Related

Product Related

Software Release

Software Product

New Requirements

Development

Customer Product Managers

Business Leaders Regional Coordinators

Trainers & Educators

Product Champion(s)

Capabilities

Business

Consumption

Concept

How Blockages Occur in Value Stream

Not Using MMFs

Too Many Selected

Doesn’t Do Incremental

Development

Not Involved During Build

No Big Picture

Not Involved

Poor Engineering

Practices


Business Priority

BUSINESS DISCOVERY BUSINESS DELIVERY

Business Planning

Business Readiness

Ready to Pull

Incremental Development

c h u n k i n g s l i c i n g

Set acceptance criteria and feature sequence

Build iteratively Scrum / Kanban / Hybrid ATDD and Emergent Design

Identify potential capabilities

Define increments as MMFs

Decision Is there enough business value?

Decision Is it technically feasible?

Decision Is an SME ready?

Incremental Deployment

Support & Feedback

Decision Is it ready to release?

PO

RT

FO

LI

O

THE VALUE STREAM


First Release

Investment

Period

Payback

Period

Profit

Period

Breakeven

from Denne and Cleland-Huang. Software by Numbers

Cas

h flo

w

Time

economics of responsiveness


Staged Releases

First

Release

Invest-

ment

Period

Profit

Period

Pay-

back

Period

Cas

h flo

w

Time

Release 1 Net Return


Staged Releases

Profit

Period

Second

Release

Invest-

ment

Period

Pay-

back

Period


Cas

h flo

w

Time



Profit

Period

Investment

Invest-

ment

Period

Pay-

back

Period

Breakeven

Point

Total Return

Cas

h flo

w

Time

staged releases


Cas

h flo

w

Breakeven Single

Release

First Release

Time

Staged Releases

Increased Profit

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


Incrementally

Realizing Business

Value

Evolving the

System

What risks do these approaches lower?

risk

value

value

risk


focusing on the known, valuable features

gives greater certainty

produces greater value

lowers risk of mis-building and over-building

Deliver in Stages when possible


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


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


Business Backlog for ACH

Loans Checks

Goal: 100% of Loans 25% Reduction in Checks

High Low



Loans Checks


High Low

Outbound Inbound Withdrawals Terminations

1 4 2 3


Business Capabilities for ACH

Outbound - Loans

Manage Bank Info

Redirect from chk to ACH

Bank Notify

Update Reconciliation

Cover Funds

Confirm ?

Analytics & Reporting

Web Call in

IVR Paper

BF - Web MMF – Web & Call in

• What are the business capabilities needed for ACH?

• What are the sources? • How can we group them

for highest value?



Loans Checks


High Low


1 4 2 3 MMF

Web | Call in

BF IVR

BF Paper

Release 1 Release 2 Release 3


Web Call in

MMF – Web & Call in

User Story Manage banking info for a Web-initiated outbound ACH transaction

Outbound - Loans

Manage Bank Info

Redirect from chk to ACH

Bank Notify

Update Reconciliation

Cover Funds

Confirm ?

Analytics & Reporting

Business Features to User Stories



Loans Checks


High Low


1 4 2 3 MMF

Web | Call in

BF IVR

BF Paper

Release 1 Release 2 Release 3

Manage Bank Info

Beware!

Building Manage Bank Info as a standalone component for everything is a system evolution! Might be more efficient from an IT perspective, but it is NOT from a business value perspective!!!


Cost of Risk

ALWAYS DRIVE FROM BUSINESS VALUE

Cost of Delay

valu

e t

o t

he b

usi

ness

low

hig

h

release 1 release 4

time

High ROI


Portfolio

Value Time box

Team

Program

Project

Book of Work Rolling Releases

Level 1,2, & 3

Program Backlog Releases

Multiple Teams

Product Backlog Iterations

Whole Team

Scale / Scope

B U S I N E S S D I S C O V E R Y B U S I N E S S D E L I V E R Y

Bus Pri Bus Plan Bus Rdy RTP It

0

Iter Dev Inc Depl Spt & Fdbk


If you can’t see

it, you can’t

manage it.


1. Identify the actions taken in the value stream

Approve Request Reqts Sign Off

Review Deploy

Analysis

Design Code Test


0.5 hrs 160 hrs 8 hrs 8 hrs

120 hrs 280 hrs 240 hrs

100 hrs

8 hrs 2 hrs

Approve Request Reqts Sign Off

Review Deploy

Analysis

Design Code Test


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


0.5 hrs 160 hrs 8 hrs 8hrs

120 hrs 280 hrs 240 hrs

100 hrs

8 hrs 2 hrs

Approve .1 / 7.9 hrs

Request 0.5 / 0.0 hr

Reqts 60 / 100 hrs

Sign Off 1 / 7 hrs

Review 2 / 0 hrs

Deploy 3 / 5 hrs

Analysis 40 / 60 hrs

Design 40 / 80 hrs

Code 80 / 200 hrs

Test 40 / 200 hrs



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



120 hrs 280 hrs 240 hrs

100 hrs

8 hrs 2 hrs

320 hrs 80 hrs 320 hrs 80 hrs

80 hrs





4. Identify time between actions



Reqts 60 / 100 hrs

Sign Off 1 / 7 hrs

Review 2 / 0 hrs

Deploy 3 / 5 hrs


Design 40 / 80 hrs

Code 80 / 200 hrs

Test 40 / 200 hrs

© Copyright 2012 Net Objectives, Inc. All Rights Reserved 33 22 September 2012


120 hrs 280 hrs 240 hrs

100 hrs

8 hrs 2 hrs







5. Identify any loop backs required

80 hrs

65% defective

Repeat 3X

20% rejected

Repeat 1X



Reqts 60 / 100 hrs

Sign Off 1 / 7 hrs

Review 2 / 0 hrs

Deploy 3 / 5 hrs


Design 40 / 80 hrs

Code 80 / 200 hrs

Test 40 / 200 hrs






5. Identify any loop backs required

6. Calculate Process Cycle Efficiency:


Request 0.5 / 0.0 hrs

Reqts 60 / 100 hrs

Sign Off 1 / 7 hrs

Review 2 / 0 hrs

Deploy 3 / 5 hrs


Design 40 / 80 hrs

Code 80 / 200 hrs

Test 40 / 200 hrs


120 hrs 280 hrs 240 hrs

100 hrs

8 hrs 2 hrs



65% defective

Repeat 3X

20% rejected

Repeat 1X

80 hrs



Reqts 60 / 100 hrs

Sign Off 1 / 7 hrs

Review 2 / 0 hrs

Deploy 3 / 5 hrs


Design 40 / 80 hrs

Code 80 / 200 hrs

Test 40 / 200 hrs

Avg Time Worked

Total Cycle Time

0.5 hrs 160 hrs 8 hrs 8 hrs

120 hrs 280 hrs 240 hrs

100 hrs

8 hrs 2 hrs


160 hrs 80 hrs 80 hrs

65% defective

Repeat 3X

20% rejected

Repeat 1X

80 hrs

80 hrs

PCE = = 14.9% 509 hrs

3433 hrs

509 hrs

3433 hrs

Avg Time Worked Total Cycle Time


how much of what you do is

valuable? rework?


Getting

Requirements

Testing

Programming

Design

Integration

Planning

Collaboration

Re-doing

requirements

Working from old

requirements

“Fixing” bugs

“Integration”

errors

Deployment

Building

unneeded

features

Overbuilding

frameworks

What Work Do You Do?

Training Documentation

Essentially

duplicating

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


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




Reqts 60 / 100 hrs

Sign Off 1 / 7 hrs

Review 2 / 0 hrs

Deploy 3 / 5 hrs


Design 40 / 80 hrs

Code 80 / 200 hrs

Test 40 / 200 hrs


120 hrs 280 hrs 240 hrs

100 hrs

8 hrs 2 hrs



65% defective

Repeat 3X

20% rejected

Repeat 1X

80 hrs


160 hrs 80 hrs 80 hrs

65% defective

Repeat 3X

20% rejected

Repeat 1X

80 hrs

80 hrs

3433 – 509 = 2924

Eliminating delays between

what you do

Getting better at what you do

Which gives a better return?


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

Is more important

than doing the

steps faster


Here’s a spot!

And another!


Ops & Support

Customers

Shared Components

Shared Components

Product Related

Product Related

Product Related

Software Release

Software Product

New Requirements

Development

Customer Product Managers

Business Leaders Regional Coordinators

Trainers & Educators

Product Champion(s)

Capabilities

Business

Consumption

Concept

Product Portfolio Management

Consider the Software Value Stream

Managing

here Reduces

induced

waste here


what structure

to use?


Legacy Organization: Matrix Resources to Projects

Project 1

Project 2

Project 3

Project 4

Project N


Let’s Create a Pilot Project

Project 1

Project 2

%

Project 3

Project 4

Project N

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

Expert

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


Seeing the Parts


Role of Team in Bigger Picture


Lean Enterprise

Business

Management

Team

MAKE

VALUE

FLOW


MAKE INCREMENTAL DELIVERY

CREATIVE PROBLEM SOLVING

QUALITY BUILT IN technical

Team

technical


technical

VALUE PRIORITIZATION

BUSINESS ITERATIONS

RELEASE PLANNING

Business


technical

FLOW Value Stream Visualization

Impediment Impact

Workflow as Process

ACCOUNTABILITY Manage (limit) queues

Visual controls

Manage flow (process)

Management


Common Theme Creating the bigger team - pan team


Background

Case Study 3: Coordinating Teams

• Multiple teams

• Specialized

• Each team completed sprints in two weeks

…but value not delivered for months

…and then with challenges


Business Priority


Business Planning

Business Readiness

Ready to Pull

Support & Feedback




Business Priority


Business Planning

Business Readiness

Ready to Pull

Support & Feedback




Incremental Development Sh

ared

Bac

klo

g

Inte

grat

ion

Tra

in


Overall Team Organization

Product Line B applications

Component team for line B applications

System-Wide Component Team

Component team for line A applications

Product Line A applications


Teams on a Project

System-Wide Component Team

Product Line B applications

Component team for line B applications

Component team for line A applications

Product Line A applications


Focus on time

over the

entire value

stream.


MMF

Split MMF

according to

Teams

Teams split according

to components

Teams work on

their parts Teams work on

their part until done

MMF

Eventually integrating

them together

Feedback times for:

Team

Across teams

Customer

Progress bar

2 weeks

6 weeks

8 weeks


MMF

Split MMF

into sub-features

Development teams split

according to components

Teams work on

their part

After one iteration, teams

integrate their components

MMF

Progress bar

Integration still required

but takes much less time

Feedback times for:

Team

Across teams

Customer

2 weeks

2 weeks

2 weeks


Case study Coordinating Multiple Business Stakeholders with Multiple Team


The Simple Case

A1

A2

A1

1. Define Business capabilities

2. Create MMFs Team Product Backlog

A1d A2 A

3. Prioritize MMFs

4. Create high level stories 5. Assign to team backlog

Product Owners

Architecture / Technical Leads

A1c A1b A1a Team 1

Stakeholders Development teams


A Harder Case

A1

A2

A1


2. Create MMFs

A1d A2 A

3. Prioritize MMFs 4. Create high level stories

5. Assign to team backlogs

Product Owners

A2c


A1c A1b A1a

A2b A2a

Team Product Backlogs

Team 1

Team 2

Team 3

Team 4



Normal Problem – We Call it Tough

A

B

C

D

E



Team 1

Team 2

Team 3

Team 4

Product Owners



Product Owner Role Stretched too Thin Team Product Backlogs

Team 1

Team 2

Team 3

Team 4

A

B

C

D

E

?

? ?

?

? ?

?

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



Product Managers and Product Owners

Product Managers

Product Owners


Team 1

Team 2

Team 3

Team 4

A

B

C

D

E


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

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

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


Agile At Scale

A1

B1

C1 A2

A1

B3

B2

B1

C2

C1


2. Create MMFs

B1c

B2c

Blo

cked

B3c

A1d A2

B2 B3

C2

A

B

C

3. Prioritize MMFs 4. Create high level stories

5. Assign to team backlogs


B1b B1a

A1c A1b A1a

B2b B2a

B3b B3a


Team 1

Team 2

Team 3

Team 4

Product Managers

Product Owners



Holistic Approach

Visibility

Systems Thinking

Flow

Self-organization with bigger view

key points


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.


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


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

J U S T D O E S N ’ T D O I T


Enterprise Agility

Business

Management

Team

technical


Lean-Agile: Evolving Agility

Continually evolving

Sustaining, not improving

Declining Maturation A

gility

Time (years)

Iterative Flow Highest Business Value

Low

∞

Lean Thinking

Business

Mgmt Team


Lean-Agile: Evolving Agility

Continually evolving

Sustaining, not improving

Declining Maturation A

gility

Time (years)

Iterative Flow Highest Business Value

Low

∞ Where are you currently?

Team Business

Management


Company / Organization

Lines of Business / Divisions

Departments / Programs

Projects / Releases

Iterative development

Business & Engineering

Practices

Continuous discovery and

developmentWhole Teams

– all skills needed to define,

build, validate, and deploy

Au

tom

ate

d R

eg

ressio

n T

ests

Co

ntin

uo

us In

teg

ratio

n

AT

DD

– A

cce

pta

nce

Te

st D

rive

n D

eve

lop

me

nt

Co

ntin

uo

us S

tan

da

rds Im

pro

ve

me

nt

Enterprise Agility

Stage 1

Stage 2

Stage 3

Bu

sin

es

s D

rive

n S

oftw

are

De

ve

lop

me

nt

Bu

sin

es

s P

ortfo

lio P

lan

nin

g

Le

an

Scrum

Kanban

XP / Iterative Lean Software

Development

Bu

sin

es

s S

trate

gy

/

Bu

sin

es

s A

rch

itec

ture


Net Objectives’ Talks At Conference

_s

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

http://www.netobjectives.com/register

© Copyright 2012 Net Objectives, Inc. All Rights Reserved 79 copyright © 2010 Net Objectives Inc.

Register at www.netobjectives.com/register

See www.netobjectives.com/resources

Contact me at [email protected]

Twitter tag @alshalloway

Thank You!

http://www.netobjectives.com/register

http://www.netobjectives.com/resources

mailto:[email protected]


Lean Enterprise

Business

Management

Team

ASSESSMENTS

CONSULTING

TRAINING

COACHING

Lean for Executives

Product Portfolio

Management

Business Product

Owner

Lean Management

Project Management Lean-Agile

Kanban / Scrum

ATDD / TDD / Design Patterns

technical process

QUE S T I O N S ?

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

lean development practices for enterprise agile

Technology