Vincent Spena - Agile and Lean Methods for Hardware Product Development
-
Upload
vincent-spena -
Category
Documents
-
view
311 -
download
0
Transcript of 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