Haste makes waste. Oh no it does not!!

Abstract

'So you have worked at Fuji? Ah... Kanban right?'

This phrase I recorded while overhearing some conversation is just an instance of what many people believe to be lean manufacturing. Many believe that Kanban (pull systems) is at the heart of Toyota's or any other Lean production system. It is of course not. Nor is continuous flow. Both are just one of the 14 management principles from the Toyota way. However flow is to be preferred over Kanban.

'Flow when you can; pull when you must.' (Rother an Shook Learning to see) is a phrase that you should repeat every day when optimizing your process towards a lean system. So what is flow? What does this concept 'flow' mean? What benefits does it bring you? What are the consequences of having continuous flow? And how does this concept map to software development?

We try to answer these questions by having the participants experience the effects of continuous flow through game play. The game mimics software development in terms of speed and quality. Then they will think of how flow can be achieved in their daily software development efforts, or at least how close they can come to flow.

Objectives

To learn flow, experience its consequences and to map the concept to software development.

Benefits of participating

Participants will learn and experience flow, its consequences, related kanban (pull) and jidoka (stop the production line) principles from the Toyota production system and in their own software development practice.

What will the organisers learn

We hope to learn more about continuous flow and how this concept applies to software development.

Session Outline

  • 10 min introduction
    We introduce ourselves and the sessions intent and outline.
  • 15 min calculation production game one
    We play the first round of the calculation production game where calculations are produced in batches.
  • 10 min reflection on game one
    We reflect on what happened in the first game. How many calculations where produced? How many errors where found? Do we know where the errors where produced? Was it a structural problem? It is possible (and if so how difficult is it) to find the root cause of the errors? Where where the errors noticed?
  • 15 min calculation production game two
    We play the second part of the calculation production game where calculations are produced one piece at the time.
  • 10 min reflection on game two.
    Have things been improved? We ask similar questions as in the first reflection.
  • 10 min presentation of flow in a production system
    We explain what happened by explaining the concept of flow.
  • 10 min mapping to software development
    In teams participant will try to map this concept to their daily software development practice and write up they conclusions on a flip chart.
  • 10 min teams presentations and roundup
    Teams present their conclusions we round up the session.