1. 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

2. 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

3. 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”)

4. 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

5. 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

6. 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

7. 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 P3Project
Definition
First Layer
Requirements
Complete
Second Layer
Requirements
Complete
Third Layer
Requirements
Complete
Start

8. 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.

9. 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
EarnedValue
Ramp Up
Actual Planned

10. 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

11. 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