Lean Development Practices for Enterprise Agile

transcript

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.

Lean Development Practices for Enterprise Agile

Lean Enterprise

Business

Management

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

We have got

it backwards

and upside-

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

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?

THE VALUE STREAM

First Release

Investment

Period

Payback

Period

Profit

Period

Breakeven

from Denne and Cleland-Huang. Software by Numbers

economics of responsiveness

Staged Releases

Release

Invest-

Period

Profit

Period

Release 1 Net Return

Staged Releases

Profit

Period

Second

Release

Invest-

Period

Profit

Period

Investment

Invest-

Period

Breakeven

Total Return

staged releases

Breakeven Single

Release

First Release

Staged Releases

Increased Profit

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

Incrementally

Realizing Business

Evolving the

System

What risks do these approaches lower?

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

release 1 release 4

High ROI

Portfolio

Value Time box

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

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

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

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

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

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

MAKE INCREMENTAL DELIVERY

CREATIVE PROBLEM SOLVING

QUALITY BUILT IN 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

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.

Split MMF

according to

Teams split according

to components

Teams work on

their parts Teams work on

their part until done

Eventually integrating

them together

Feedback times for:

Across teams

Customer

Progress bar

2 weeks

6 weeks

8 weeks

Split MMF

into sub-features

Development teams split

according to components

Teams work on

their part

After one iteration, teams

integrate their components

Progress bar

Integration still required

but takes much less time

Feedback times for:

Across teams

Customer

2 weeks

Case study Coordinating Multiple Business Stakeholders with Multiple Team

The Simple Case

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

2. Create MMFs

A1d A2 A

3. Prioritize MMFs 4. Create high level stories

5. Assign to team backlogs

Product Owners

A1c A1b A1a

A2b A2a

Team Product Backlogs

Team 1

Team 2

Team 3

Team 4

Normal Problem – We Call it Tough

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

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

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

2. Create MMFs

A1d A2

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

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

technical

Lean-Agile: Evolving Agility

Continually evolving

Sustaining, not improving

Declining Maturation A

gility

Time (years)

Iterative Flow Highest Business Value

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

∞ 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

ressio

rds Im

Enterprise Agility

Stage 1

Stage 2

Stage 3

Kanban

XP / Iterative Lean Software

Development

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

Register at www.netobjectives.com/register

See www.netobjectives.com/resources

Contact me at alshall@netobjectives.com

Twitter tag @alshalloway

Thank You!

Lean Enterprise

Business

Management

ASSESSMENTS

CONSULTING

TRAINING

COACHING

Lean for Executives

Product Portfolio

Management

Business Product

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