1

Leankit Webinar 29 Jun 2016 Hamish McMinn

Introducing Kanban to Automotive Product Development: A New Vehicle Case Study

2

Who? Why?

Hamish McMinn M.A. PMP® • Engineering Apprentice MOD Aquila • IT Operations • Project Manager (Automotive & IT) 2003 • Kanban epiphany 2012 Objectives: • How Automotive NPD offers rich opportunities for

improving time, cost and quality equations • Challenges transferring agile software techniques into

hardware development • Highlights of our learning

3

What Happened?

Kanban proof of concept

Independent study reported delivery rate and quality up

Delivery rate and quality up with 30% fewer resources

2nd vehicle programme

Rollout to all new vehicle programme

Quantitative data on time & cost improvements, quality improvements

dec jan feb mar apr may jun jul aug sep oct nov dec jan feb mar apr

Users 60 60 60 60 60 60 60 80 80 80 80 80 180 220 280 330 380

Support 2 2 2 2 2 2 2 2 2 2 2 3 4 4 4 10 10

4

Time: 2-4 years

cost of delay - Clark, Chew, Fujimoto estimated nearly $1M/day in 1987

(over $2M / day in today’s dollars)

Cost: £100M - >£1B (9 to 11 figure sums) Quality: cost of poor quality:

defect containment (inspect, palliatives)

escaped defects:

warranty

cost of lost sales

So What?

Sources:

Kim B. Clark, W. Bruce Chew, and Takahiro Fujimoto Product Development in the World Auto Industry

US Bureau of Labor Statistics, CPI Inflation Calculator, www.bls.gov/data/inflation_calculator.htm

Investment

Return

Cashflow

-45

-35

-25

-15

-5

5

15

25

35

45

Time Breakeven

Cash

5

Project Scaling

PCDS v2 345

Pilot

PCDS v2 666/664

Time

Pilot vs PCDS v2

UNV1 UPV0 UNV2 UPV1 UPV2 UPV3

Pilot delivered a 666 scale programme with 345 resource (30% fewer) and improved timing and quality

Planned

Planned

Actual

6

Engineering Team Structure

Body S

tru

ctu

re

Mechs

Clim

ate

Sa

fety

Ext T

rim

Int T

rim

Se

atin

g

Ca

bin

Syste

ms

Do

or

Syste

ms

Chassis

Ste

erin

g

Bra

ke

s

Wh

ee

ls &

Tyre

s

Su

sp

en

sio

n

Fra

me

s &

M

ou

nts

Electrical

Dis

trib

utio

n

Info

tain

me

nt

Sw

itch

ge

ar

Drive

r A

ssis

t

Powertrain

Engin

e

Tra

nsm

issio

n

Co

olin

g

Exh

au

st

Drive

line

Hyb

rid

Project

Leaders

Module

Leaders

Lead Engineers

Component Engineers

CAD Engineers

100 - >300 Engineers, multiple sites, countries, continents

Circa 7000 parts to release

700-7000 CAD files

Requirements, FMEA, Test Plan, Cost, Weight, Supplier…

7

1. How do they ensure compatibility of their design? 2. How can they collaborate effectively? 3. What parts do they need to interface to? Give clearance to? 4. What is latest design intent? 5. Software complexity (lines of code)

• Boeing 787 14M

• F35 Fighter 24M

• Modern Luxury Car 100M

The Challenge for Engineers

Source: http://www.informationisbeautiful.net/visualizations/million-lines-of-code/

8

Visual Management

9

Improving Collaboration

10

Continuous Feedback

11

1. Queues are the root cause of the majority of economic waste in product development

2. Queues are the analogue of inventory

3. We do not measure or manage queues (practically no one does)

4. Every transaction in product development is a potential queue

5. We have thousands of transactions (opportunities to improve)

To improve data supply stability:

1. Make process visible

2. Limit WiP (optimise batch sizes)

3. Focus on flow

4. Identify and reduce blockages and feedback delay

Flow and Kanban

Donald G. Reinertsen The Principles of Product Development Flow: Second Generation Lean Product Development 2009

David J. Anderson Kanban: Successful Evolutionary Change for Your Technology Business 2010

12

Applying Software Development Techniques

Constraints in physical product development

• Minimum viable product

• Architectural hard points

• 6 degrees of freedom to control

• Material requirements and properties

• Material lead times

• Production representative prototype parts

• Build time and cost

• Duplication time and cost

• Modular design constrained by all of the above

Mitigation

• Decompose interim releases (internal

customers)

13

Automotive Product Development Lead Time

Source: James M. Morgan, Jeffrey K. Liker: The Toyota Product Development System: Integrating People, Process, and Technology 2006, 71

Concept

Styling

CAD Design

Prototype

Mfr. Eng.

Tooling

Launch

Design Concept Start of Production Time

Marketing Business Model

Clay Model Theme Selection

CAD Engineering Change

Launch Support

Product Quality Process Development

Tooling Construction

Supplier Development

= Non Value Add Time (Waste)

= Value Add Time

14

Automotive Product Development Lead Time

Concept

Styling

CAD Design

Prototype

Mfr. Eng.

Tooling

Launch

Design Concept Start of Production Time

= Non Value Add Time (Waste)

= Value Add Time

Value Added Time is only a very small percentage of the Lead-Time

Source: James M. Morgan, Jeffrey K. Liker: The Toyota Product Development System: Integrating People, Process, and Technology 2006, 71

15

Automotive Product Development Lead Time

Concept

Styling

CAD Design

Prototype

Mfr. Eng.

Tooling

Launch

Design Concept Start of Production Time

= Non Value Add Time (Waste)

= Value Add Time

Value Added Time is only a very small percentage of the Lead-Time

Source: James M. Morgan, Jeffrey K. Liker: The Toyota Product Development System: Integrating People, Process, and Technology 2006, 71

16

Virtual

Virtual Series

CAD Progression

UNV1

CAD Progression

UNV2

CAD Progression

UPV2

CAD Progression

UPV3

Analysis

Issue

Resolution

Data

Freeze

Data

Freeze

Data

Freeze

Data

Freeze

Analysis

Issue

Resolution

Analysis

Issue Resolution

Analysis

Issue Resolution

Virtual Series Loops

10-16 weeks duration

Data

Freeze

M1 Prototype Release VP Prototype

Release

M1 Build and Test

Physical

17

Virtual Series

CAD Progression

UNV1

CAD Progression

UNV2

CAD Progression

UPV2

CAD Progression

UPV3

Analysis

Issue

Resolution

Data

Freeze

Data

Freeze

Data

Freeze

Data

Freeze

Analysis

Issue

Resolution

Analysis

Issue Resolution

Analysis

Issue Resolution

Virtual Series Loops

10-16 weeks duration

Data

Freeze

Current batch sizes and feedback delay render virtual series data delivery systemically

unstable, forcing a stark choice: scale upstream resource, or tolerate delays

Defect Created

Defect Detected

Defect Resolved

Detection Delay Resolution Delay

18

Late “hockey stick”

delivery results in

asynchronous

engineering i.e low

quality, incompatible

data.

Sprint 1 Sprint 2 Sprint 3 Sprint 4

The Hockey Stick G

ate

wa

y D

ata

Re

ad

ine

ss

-12 -9 -6 -3

Countdown (weeks)

+2

100%

Av loop slip 2 weeks

Reduced delta represents

improved compatibility at the

same point

Data flow is driven by Sprint

glidepaths, not single deadline.

Data integrity improved

19

Shortening Feedback: Sprints

20

Shortening Feedback: Sprints

21

22

Effect of Batch Size

23

0

2

4

6

8

10

12

14

16

18

20

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56

Batch size 1

Batch size 1 with Errors

Batch size 5

Batch size 5 with Errors

Batch size 10

Batch size 10 with Errors

Effect of Batch Size

Un

de

tec

ted

Defe

cts

24

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%Combined Status

Combined Completion Prediction

Combined Compatibility Target %

Compatibility Achieved

Metrics

25

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%UPV2 Geometry - Chassis Assessment Readiness

Chassis Completion Prediction

Chassis Compatibility Target %

Compatibility Achieved

Metrics

26

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%UPV2 Geometry - Chassis Assessment Readiness

Chassis Completion Prediction

Chassis Compatibility Target %

Compatibility Achieved

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%UPV2 Geometry - Electrical Assessment Readiness

Electrical Completion Prediction

Compatibility Achieved

Electrical Compatibility Target %

Metrics

27

Daily Stand up Meetings

In front of the board, three questions: 1. What did we accomplish yesterday? 2. What will we do today? 3. What obstacles are impeding our

progress? Objective is not to discuss details in the meeting, but to agree offline help required

28

So What is the Board Telling Us?

The board is a signalling system, its effectiveness relies on our ability to read the signals and

raise the questions it prompts. E.g.:

• What needs to happen to progress these items?

• Why is this item blocked?

• Who has the next action?

• What is date to green?

• When will overdue be ready?

29

The Big Picture

30

Highlights of Our Learning to Date

• Visual Management

• Accelerate feedback

• Decompose large batches

• WIIFM

• Success breeds success

• People’s behaviour (not tools) delivers outcomes

• Replicate good practice

• Deep vs superficial learning

31 Contact: hamish@flowlogic.co W: Flowlogic.co

Summary

• Reduced batch size

• Shortens feedback loops

• Reduces defects / rework

• Increases throughput and quality

• Adopt Kanban / visual management to enable intense collaboration

• Result – complex programme achieved in less time with

• Improved quality

• 30% fewer resources

32

Questions and Answers

Contact: hamish@flowlogic.co W: Flowlogic.co

33

Summary

• Reduced batch size

• Shortens feedback loops

• Reduces defects / rework

• Increases throughput and quality

• Adopt Kanban / visual management to enable intense collaboration

• Result – complex programme achieved in less time with

• Improved quality

• 30% fewer resources

Contact: hamish@flowlogic.co W: Flowlogic.co