Transforming Your Value Streams 11 - 12: The Future State

Thoughts from watching Gemba Academy's Transforming Your Value Streams videos 11 and 12: The Future State:

9 questions for designing a future state:

1. Where can we balance cycle times with takt time? (I don't think this is relevant for us)
2. Where can we connect processes through one piece flow?
3. Where must we pull with kanban to maintain flow?
4. Will we pull sequentially or based on replenishment? (Where are the queues? What are the limits? What is the prioritisation scheme?)
5. Where will we schedule production (that is, what is the pacemaker)?
6. How will we level the mix and volume of production (heijunka)? (Volume is relevant as is capacity allocation but that's not quite the same as mix)
7. Where can we build in quality (jidoka) rather than inspect it in?
8. Which processes have losses and must be improved?
9. Who, What, When?

Operational Takt Time = Takt Time x Efficiency Factor

How much can we pre-balance teams vs dynamically rebalance?

It occurred to me that this is the issue every time someone asks about developer to tester, developer to analyst ratios.  The assumption there tends to be that everything is pre-balanced where most Agile folk will tend much more strongly towards dynamic re-balancing.

Can we ever remove final inspection?

The example company in the video decided to completely remove final inspection and instead have each process self-inspect and never leak defects to the next process.

This reminds me of the final inspection process during final assembly at the Toyota plants I visited.  Even if the intention is to build-in quality, they still don't remove that final safety net so as to not leak defects to the customer.

Unlike mass physical manufacturing, we are not constructing the same thing off a validated design.  What we do is more like what R&D product development does.  We happen to have a magic robot factory (simplistically the compiler, and more likely these days, an automated build system) that produces whatever we send to it in a relatively short period of time.  So we can never really remove final inspection.  Even if every component self-inspects quality, we still can't be 100% confident that the overall integrated system deployed on the particular platform will behave as we expect.  We can however dramatically reduce the number of unexpected discoveries in final inspection by building-in quality in previous steps.

4 steps to Jidoka:

1. Detect the abnormality
2. Stop
3. Fix or correct the immediate condition (aka Containment)
4. Investigate the root cause and install a countermeasure

This is pretty much the structure of a Problem / Countermeasure board

Kaizen Newspaper

I've actually heard of this concept before (which is actually serves the same purpose as a Problem / Countermeasure board) but didn't pay too much attention.  I'm now thinking that it's a good way to get people used to visual management.