Vincent Spena - Agile and Lean Methods for Hardware Product Development
- 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