vincent spena - agile and lean methods for hardware product development

Application of Agile and Lean Methods to Hardware Product

Development

By: Vincent Spena

Great Lakes Regional Conference 2012 Copyright © 2012 by: Vincent Spena

Published and used by INCOSE with permission 1

Kanban Approach 1. In a “factory”, the production steps are

repeatable and each pre-defined step adds value

2. Kanban is used to “measure for the purpose of control”

• It can be implemented in many ways including the use of tokens or computerized forms

3. The sample Kanban table to the left provides

• information about how items are flowing though the process steps

• information about the throughput of each station (when time is factored in)

Great Lakes Regional Conference 2012 Copyright © 2012 by : Vincent Spena

Published and used by INCOSE with permission 2

Station A

Station C

Station D

Station B

Station G

Station F

Station E

Line “value” Items

A B C D E F G

1 50 45 40 40 35 20 20 15

2 75 75 70 65 40 15 10 10

3 60 45 45 45 30 25 20 15

4 45 45 45 40 35 25 15 15

5 80 80 40 40 35 35 25 15

Sample Observations: • Line 1 has 5 items that have not been put into the

process • Line 2 seems have some throughput issues at station E

because 25 items are in queue • Line 3 might be “overstaffed” for station B and station C.

Maybe staffing can be redeployed to station A

What is happening?

1. Each item must be processed with a predetermined number of steps ---> A+B+C+D+E+F+G (Not necessarily in sequence)

2. Each step adds a “value” to the item. The “amount” of value for each step may not be known, but the measurement provides information that highlights if the value has been added or if it still needs to be added.

3. A sequence may not be necessary, but if it’s set up to do so, the value in “Station D” cannot be added without the unit having A+B+C

Great Lakes Regional Conference 2012 Copyright © 2012 by : Vincent Spena

Published and used by INCOSE with permission 3

Station A

Station C

Station D

Station B

Station G

Station F

Station E

Line “value” Items

A B C D E F G

1 50 45 40 40 35 20 20 15

2 75 75 70 65 40 15 10 10

3 60 45 45 45 30 25 20 15

4 45 45 45 40 35 25 15 15

5 80 80 40 40 35 35 25 15

Assumptions: • The operation in each station may be short and

repeatable – (ie visible to the operator) • Each step is assumed to be perfect -- the mechanism to

detect and prevent faults in lean systems is left to jidoka, and the operator is an integral part of keeping faults out of the system (Ie “Built in Quality”)

Iterative and Incremental Development - IID

IID Is often associated with Software Development, but consider what happens in the construction of a new building :

1. The plans of the TO-BE building is defined

2. The skeletal framework is constructed

3. The surrounding structure is built up on the skeletal framework

4. The details and final touches are placed in the structure

In all cases the following items are important: A plan with high level requirements of the final outcome

Defined steps and defined requirements for each step. ( Ie: Building frame with 15 floors, concrete structure for 15 floors, 30 rooms in each floor, etc)

Each step requires the previous step to be sufficiently complete before the next step can begin

Refinements can be made along the way as long as they conform to the original plan. (Ie 29 rooms on the 15th floor with one room being double the size of a normal room).

Great Lakes Regional Conference 2012 Copyright © 2012 by: Vincent Spena

Published and used by INCOSE with permission 4

1

2

3

4

Anatomy of complex product development • Product development can be thought of many separate development efforts • Each team develops different parts of the product at different rates depending on difficulty,

resources, knowledge, and dependencies such as part availability, build schedules, and knowledge sharing

Great Lakes Regional Conference 2012 Copyright © 2012 by: Vincent Spena

Published and used by INCOSE with permission 5

Control Panel

GPS Module

Bluetooth Module

Chassis

Software

Certifications

Core Features

Amplifier

Receiver

Oscillator

Processor

Peripherals

These teams share a common board and integrated build plan

These teams can work somewhat independently

Time

Applied Kanban and IID

Great Lakes Regional Conference 2012 Copyright © 2012 by : Vincent Spena

Published and used by INCOSE with permission 6

Activity A

Activity C

Activity D

Activity B

Activity G

Activity F

Activity E

P1

P2

P3

1. A Prototype is a grouping of all the activities that have been performed.

2. Like in IID, prototypes must have planned design targets (requirements to be met). Design targets provide a frame of reference for the whole project

3. IID provides an alignment point for many teams • Without IID targets, teams try to

dictate project changes based on their needs instead of aligning to project goals.

4. Requirements are of two varieties: • Requirements that are internal to

development (Not counted because it cannot be defined- see Assertion #1)

• Requirements that are to be verified for the project (IID targets)

Assertion #1: In development, a station is a type of activity like testing a circuit or collecting part specifications. Therefore the sequence and quantity of development activities is not predictable. Assertion #2: Since the quantity of activities for a prototype cannot be known: A comparable means to gauge the effectiveness of activities is to measure the requirements that have been met for that prototype

Application of IID and Kanban Prototype quantity (plan) and Requirements to be met by each team at each prototype must be defined during the project definition stage.

Great Lakes Regional Conference 2012 Copyright © 2012 by: Vincent Spena

Published and used by INCOSE with permission 7

Control Panel

GPS Module

Bluetooth Module

Chassis

Software

Certifications

Core Features

Amplifier

Receiver

Oscillator

Processor

Peripherals

These teams share a common board and integrated build plan

These teams can work somewhat independently

P1 P2 P3 Project Definition

First Layer Requirements Complete

Second Layer Requirements Complete

Third Layer Requirements Complete

Start

Applied Kanban and IID

Great Lakes Regional Conference 2012 Copyright © 2012 by : Vincent Spena

Published and used by INCOSE with permission 8

Activity A

Activity C

Activity D

Activity B

Activity G

Activity F

Activity E

P1

P2

P3

The # of Prototype is predictable The # of requirements to me met is predictable The requirements met in the Prototype is a direct measure of “Value” added to the design.

Engineer or Team

Project Requirements

P1 Pass

P1 Fail

P2 Pass

P2 Fail

P3 Pass

P3 Fail

Transmitter 150 45 8 107 12 150 1

Receiver 120 60 5 90 9 120 0

GPS 300 35 20 205 6 300 0

Control Panel 105 45 0 45 3 105 0

Sample Observations: • It does not make sense to test for P2 and P3 functionality if

the product is at P1 maturity (should be expected but “test everything” is not always seen as waste)

• The GPS subsystem may be having some issues because >36% of “expected to pass” requirements were not met

• The Control Panel subsystem seems to have had a delay in development/testing relative to the other subsystems.

Additionally: Using similar methodologies, the number of fault items, pass items, time between protos, and other information can be captured to gauge proto effectiveness against targets.

Note: Jidoka is much more difficult in development because steps are difficult to visualize as being related. Reviews and other fault avoidance mechanisms like “best practices” are still needed.

Sample Charts – Overall Prototype Effectiveness

• A Prototype effectiveness chart clearly shows performance relative to plan

• The % Fail line can be used to align to trend information between similar projects

• The chart is similar to a “burn up” chart and the same data can be used to create such a chart (shown below)

Great Lakes Regional Conference 2012 Copyright © 2012 by: Vincent Spena

Published and used by INCOSE with permission 9

0%

2%

4%

6%

8%

10%

12%

14%

16%

18%

20%

0

50

100

150

200

250

P1 P2 P3 P4

Prototype Effectiveness

FAIL Not tested PASS SW % FAIL

0%

20%

40%

60%

80%

100%

120%

P1 P2 P3 P4

Earn

ed

Val

ue

Ramp Up

Actual Planned

Sample Charts – Prototype Effectiveness by team

Great Lakes Regional Conference 2012 Copyright © 2012 by: Vincent Spena

Published and used by INCOSE with permission 10

0

10

20

30

40

50

60

70

80

90

100

ID ME RX TX BT GPS ID ME RX TX USB BT GPS ID ME RX TX USB BT GPS ID ME RX TX USB

P1 P2 P3 P4

Fail Pass SW Not Tested

Summary and Conclusions

• Kanban and IID can be applied to Product Development and allows measurement for control of development activities

• Implementation of Kanban and IID in Product Development requires:

– A plan that defines number of steps (Protos) and the requirements to be met at each step

– A measurement of actual vs planned

– Mechanisms to prevent faults from propagating because jidoka is not as straightforward during development

• Metrics based on Kanban and IID can allow near-real time information about the progress of development

Great Lakes Regional Conference 2012

Copyright © 2012 by: Vincent Spena Published and used by INCOSE with permission 11