Lean Software Development Is for Everyone

2 June 2015 Copyright © 2007 Net Objec:ves. All Rights Reserved.

1

LEAN-agile© copyright 2010. Net Objec:ves, Inc.

B E C O M I N G

Lean Software For EveryoneKen Pugh Fellow Consultant

KP Aug 2014

•  Introduction and Background

•  Lean as Flow •  Lean Software Development •  Lean-Agile •  Transforming into Lean

Outline


2

Ken Pugh

ken.pugh @netobjec:ves.com

Photo Size: Height: 2.25 Posi:on: from top leO corner Horizontal 0.75 Ver:cal 1. Picture Style: Simple Black Frame

No code goes in +ll the test goes on. A journey of two thousand miles begins with a single step.

§  Fellow Consultant §  SPC, Lean, Scrum, ATDD, TDD, OOA&D, Design

PaYerns,

§  Over 2/5 century of soOware development experience

§  Author of seven books, including: –  Prefactoring: Extreme Abstrac+on, Extreme

Separa+on, Extreme Readability (2006 Jolt Award)

–  Interface Oriented Design

–  Lean Agile Acceptance Test-‐Driven Development: BeJer SoKware Through Collabora+on

Lean Enterprise

Business

Management Team

ASSESSMENTSCONSULTING

TRAININGCOACHING

Lean for Executives Product Portfolio Management Business Product Owner

Lean Management Project Management

ILAFYT Kanban / Scrum ATDD / TDD / Design Patterns

technical process


3

§  Lean Thinking, Jim Womack and Daniel Jones §  Lean Software Development, Mary and Tom Poppendieck §  The Principles of Product Development Flow: Second

Generation Lean Product Development, Donald Reinertsen §  Alan Shalloway, http://www.netobjectives.com/blog

Resources

Overall Rule§  There are exceptions to every statement, except this

one

6


4

copyright © 2010 Net Objectives Inc.

Introduction and Background

§  Lean software engineering –  Continuous delivery of high quality applications

In short


5

§  Toyota Production System –  Lean Manufacturing

§  Lean Thinking –  Use lean thinking on workflow –  Software development is workflow

§  Lean Software Development §  Creating software is not the same as producing a car §  Principles derived from Lean

Lean Approaches

§  Taiichi Ohno, chief engineer §  Eiji Toyoda (and cousin Kiichiro Toyoda and his father

Sakichi Toyoda, (Toyoda Loom Works founder)) §  Design out overburden (muri) and inconsistency

(mura), eliminate waste (muda). §  Smooth process - design out inconsistency §  Flexible – without overburden which generates waste §  Elimination of waste

Toyota Production System (TPS)


6

§  Continuous improvement §  Respect for people

§  Kazien

§  Long-term philosophy –  Not short term goals

§  Right process will produce right results –  Stop to fix problems –  Visual controls –  Use reliable, tested technology

§  Add value to organization by developing your people and partners –  Develop exceptional teams

§  Continuously solving root problems drives organizational learning –  Decisions by consensus

TPS Principles

§  Value comes from end customer §  Value stream

–  Eliminate steps not creating value

§  Make remaining steps flow in integrated sequence §  Let customers pull from upstream activity §  Transparency

–  Helps eliminate waste –  Continuous improvement

Lean Thinking


7

§  Eliminate Waste §  Create Knowledge §  Build Quality In §  Defer Commitment §  Deliver Fast §  Respect People §  Improve the System

Lean Software Development Principle

Dilbert on A

gile Agile


8


Workflow


9

drive 'om

Business Value

SMALL INCREMENTS


10

m a k e a l l w o r kvisible

1 concentration


11

Idea Business decision Implementa:on Availability

FLOW

© Warp and Byte Designs, Inc..

outcome


12

business value trumps flow

trumps Reducing Waste



13

Flow From Concept to Consumption

Business Value – What Is It? (1)§  Need to measure business value §  Deliver best ROI for business value

§  "I can't define it, but I know it when I see it“

§  Question: What is it to you?

26


14

Business Value – What Is It? (2) §  Business Value can be:

–  Increased revenue (sales, royalties, fees) ($$) –  Decreased expenses ($$)

§  Less resources § More efficient use of resources

–  Customer satisfaction ($$ ??) §  Promoters / Satisfiers/ Detractors

–  Staying in business ($$ ??) –  Staying out of jail ($$ ??) –  Avoiding risk ($$ ??) –  Your suggestions?

27

Business Value

Projects

Next Project BV = 8

Current Project BV = 13

Previous Project BV= 20


15

Transparency – Trust

Transparency To Do

Working On Done

Next Project Current Project

Previous Project


16

§  Deliver –  Minimum Marketable Feature (MMF) –  Minimum Business Increment (MBI) –  Key = Independently Releasable Item (IRI)

§  Develop –  Stories –  Scenarios

Key = Separately Developable Items (SDI) § Although may be sequenced dependent

Small bites

Small PiecesTo Do

Working On Done

Current Project

Current Part Previous part

S:ll Another Part

Another Part

Some Part


17

Flow

Business Priority

BUSINESS DISCOVERY BUSINESS DELIVERY

Business Planning

Business Readiness

Ready to Pull

Incremental Development

Incremental Deployment

Support & Feedback

Decision Is it technically feasible?

Decision Is it ready to release?

PORT

FOLIO

Decision Is there enough business value?

Flow


18

Cycle Time

Lean Principle

Idea to Delivery

Support & Feedback

ProjectApproval

ProjectStaffing

ProjectDevelopment

ProjectDeploy-ment

Visioning

Total cycle :me


19

Lean Principle

Support & Feedback

ProjectApproval

ProjectStaffing

ProjectDevelopment

ProjectDeploy-ment

Visioning Support & Feedback

ProjectDevelopment

ProjectDeployment

$$$ Cost

Support & Feedback

ProjectApproval

ProjectStaffing

ProjectDevelopment

ProjectDeploy-ment

Visioning Support & Feedback

ProjectDevelopment

ProjectDeployment

ProjectApproval

ProjectStaffingVisioning

Lean Principle

Opportunity Cost


20

Value Stream

1. Identify the actions taken in the value stream

ApproveRequest Reqts Sign Off

Review Deploy

Analysis

Design Code Test


21

0.5 hrs 160 hrs8 hrs 8 hrs

120 hrs 280 hrs 240 hrs

100 hrs

8 hrs2 hrs

ApproveRequest Reqts Sign Off

Review Deploy

Analysis

Design Code Test

1. Identify the actions taken in the value stream2. What was the real time from start to finish of the action?

0.5 hrs 160 hrs8 hrs 8hrs

120 hrs 280 hrs 240 hrs

100 hrs

8 hrs2 hrs

Approve.1 / 7.9 hrs

Request0.5 / 0.0 hr

Reqts60 / 100 hrs

Sign Off1 / 7 hrs

Review 2 / 0 hrs

Deploy3 / 5 hrs

Analysis40 / 60 hrs

Design40 / 80 hrs

Code80 / 200 hrs

Test40 / 200 hrs

1. Identify the actions taken in the value stream2. What was the real time from start to finish of the action?3. What was the average time working on this vs working on other things?


22


120 hrs 280 hrs 240 hrs

100 hrs

8 hrs2 hrs

320 hrs 80 hrs 320 hrs 80 hrs

80 hrs


1. Identify the actions taken in the value stream2. What was the real time from start to finish of the action?3. What was the average time working on this vs working on other things?4. Identify time between actions

Approve.1 / 7.9 hrs

Request0.5 / 0.0 hr

Reqts60 / 100 hrs

Sign Off1 / 7 hrs

Review 2 / 0 hrs

Deploy3 / 5 hrs

Analysis40 / 60 hrs

Design40 / 80 hrs

Code80 / 200 hrs

Test40 / 200 hrs

2 June 2015


120 hrs 280 hrs 240 hrs

100 hrs

8 hrs2 hrs



1. Identify the actions taken in the value stream2. What was the real time from start to finish of the action?3. What was the average time working on this vs working on other things?4. Identify time between actions5. Identify any loop backs required

80 hrs

65% defectiveRepeat 3X

20% rejectedRepeat 1X

Approve.1 / 7.9 hrs

Request0.5 / 0.0 hr

Reqts60 / 100 hrs

Sign Off1 / 7 hrs

Review 2 / 0 hrs

Deploy3 / 5 hrs

Analysis40 / 60 hrs

Design40 / 80 hrs

Code80 / 200 hrs

Test40 / 200 hrs


23

1. Identify the actions taken in the value stream2. What was the real time from start to finish of the action?3. What was the average time working on this vs working on other things?4. Identify time between actions5. Identify any loop backs required6. Calculate Process Cycle Efficiency:

Approve.1 / 7.9 hrs

Request0.5 / 0.0 hrs

Reqts60 / 100 hrs

Sign Off1 / 7 hrs

Review 2 / 0 hrs

Deploy3 / 5 hrs

Analysis40 / 60 hrs

Design40 / 80 hrs

Code80 / 200 hrs

Test40 / 200 hrs


120 hrs 280 hrs 240 hrs

100 hrs

8 hrs2 hrs





80 hrs

Approve.1 / 7.9 hrs


Reqts60 / 100 hrs

Sign Off1 / 7 hrs

Review 2 / 0 hrs

Deploy3 / 5 hrs

Analysis40 / 60 hrs

Design40 / 80 hrs

Code80 / 200 hrs

Test40 / 200 hrs

Avg Time Worked Total Cycle Time

0.5 hrs 160 hrs8 hrs 8 hrs

120 hrs 280 hrs 240 hrs

100 hrs

8 hrs2 hrs


160 hrs 80 hrs 80 hrs



80 hrs

80 hrs

PCE = = 14.9%509 hrs

3433 hrs

509 hrs

3433 hrs

Avg Time Worked Total Cycle Time

Approve.1 / 7.9 hrs


Reqts60 / 100 hrs

Sign Off1 / 7 hrs

Review 2 / 0 hrs

Deploy3 / 5 hrs

Analysis40 / 60 hrs

Design40 / 80 hrs

Code80 / 200 hrs

Test40 / 200 hrs


120 hrs 280 hrs 240 hrs

100 hrs

8 hrs2 hrs





80 hrs


160 hrs 80 hrs 80 hrs



80 hrs

80 hrs

3433 – 509 = 2924

Eliminating delays between what you do

Getting better at what you do

Which gives a better return?


24

Cycle Time§ What’s the cycle time from input to output? §  How can it be shortened?

–  Eliminate delays –  Eliminate loop-backs –  Manage WIP – 

Waste and Delays


25

1.  Partially Done Work 2.  Paperwork 3.  Extra Features 4.  Task Switching 5.  Handoffs 6.  Delays 7.  Defects

Waste Indicators

how much of what you do is

valuable? rework?


26

DELAY IS hand-offs bottlenecks information delay untested code unread requirements transaction related

setup/cleanup coordination related

assign people

findingredoing

reworkingwaiting

J

Pull


27

PUSH

Work enters queue When someone needs new work, they pull from queue Work goes through stages When the work done in a stage, it flows to next. Until work is done

Pull


28

PULL

BUT LIMIT QUEUES


29

Reduce WIP

Queuing theory

Focus on quality

Practice


30

EXERCISE

Part One AGILE IS FUN

EXERCISE

Part Two AGILE IS FUN


31


This is Not an Ending, But a Beginning

§  Shorten time to realize values §  Pay attention to delays §  Actively manage queues (WIP) §  Emphasize cycle time, not utilization

Summary - Focus on Flow


32


Supplementary

Points and Practices


33

§  Driving in Germany - picture of autobahn

policies




34

Measurement



35

Metrics

What is important? Customer /user sa:sfac:on Produc:on defects Rate of delivery of business value


Lean Software Development


36

§  Implement lean across entire value stream –  To deliver business value –  Not just improve development

Optimize the Whole / See the Whole

§  Focus on customer value §  Only start work that can be completed

Eliminate Waste


37

§  Move tests forward –  Acceptance Test Driven Development

§  Automated testing § Write change tolerant code

Build Quality In / Build Integrity In

§  Small batches §  Get feedback fast §  Emphasize cycle time, not utilization

Deliver Fast / As Possible


38

§  Use knowledge learned from creating application §  Cross-functional teams to share knowledge §  Quick feedback

Create Knowledge / Amplify Learning

§  Create clear frameworks for decisions §  Decision making at lowest possible level

Empower People / The Team


39

§  Periodic reflections §  Perform root cause analysis

Continually Improve

§ Wait till last practical moment to make decision –  More information available

Defer Commitment / Decide as Late as Possible


40


Beginning the Transformation

Getting Started §  Agree to goals

–  Why change? §  Map the value stream§  Determine what process to use

–  Scrum, Kanban, Scrumban, etc. §  Agree to transparency

–  Up and down the line §  Agree to policies

–  Done-ness definitions, etc. §  Agree to operational review

–  Team and organization §  Educate the team(s)§  Start doing it

David Anderson. XTC, London 2009, October

Getting started with kanban


41

Old Status Quo New Status Quo

Chaos Transforming Idea

Change Model From Virginia Sa:r

Teams


42

© U.S. Army


Successful teams Collaborate Shared accountability Shared approach to doing work Shared history


43


Feedback


44

Agile Feedback – Small Increments

87

No feedback

Desired Delivered

With feedback

Desired

Delivered

§ Frequency of feedback


45

Deliver Quickly

Multi-Tasking


46

Request 1/Team 1

Month

1

Month

2

Month

3

Request 2/Team 2

Request 3/Team 3

A Harder ProblemSCENARIO B

another way to think of it

Request 1

Month

1

Month

2

Month

3

Request 2

Request 3

A Harder ProblemSCENARIO B

try this: quicker feedback


47

Project 1

Project 2

Project 3

Month 3 Month 2 Month 1 Month 4

Three ways to do three projects

Do one at a time – may not be politically feasible.

Do them all at once, switching between them when delayed waiting for answers

Do them guided by Minimal Marketable Features

Product Development for the Lean Enterprise by Michael Kennedy. Oaklea Press. 2003

Task-Switching and Schedules

Date post:	17-Aug-2015
Category:	Software
Upload:	techwellpresentations
View:	12 times
Download:	0 times