After Norm Kerth’s keynote on Tuesday morning, I ran my Jidoka in Software Development session again. This time there were nine attendees, which I guess reflects the perception that this topic occupies a specialist niche. The discussion was lively and interesting again, and yet again we covered topics that had never come up before. (Dave Draper, one of the participants, has posted his reflections on the session here.) I never cease to be suprised and delighted by how the specific combination of individuals’ interests and experiences can produce new insights in a topic I had heard discussed a dozen times already. My thanks to all who took part, both in this session and its predecessors.
During the next few weeks I’m planning a series of posts detailing what I’ve learnt from these sessions about applying the lean jidoka concept to software development. In the meantime, several of you have asked me to describe the mechanics of the session itself. So for details, read on…
The session begins with the story of Paradise Mill, which I also relate to the early days of the Toyoda Spinning and Weaving company, where autonomation was first introduced. At this point it is important to point out that the metaphor of software development as manufacturing doesn’t work well. Developing software is more akin to designing the product, as opposed to making many copies of it. Consequently we need to ask the question: can a practice from lean manufacturing be translated to development at all?
Next we do the Walking About exercise. Participants pair up, and assign one member of the pair to be the “worker”, while the other is the “manager”. The worker must walk 60 paces in 1 minute, but may only do what the manager says. Meanwhile the manager may only say “go”, “stop”, “turn left” or “turn right”. In a crowded room with many participants and chairs and tables it turns out to be rare for anyone to achieve 60 paces. But then we re-run the exercise, this time with no managers, and with every participant able to direct himself. Of course, everyone completes 60 paces well within the time allowed. We then discuss briefly the difference in effectiveness between teams whose process and plan are imposed, versus those teams who are empowered to decide for themselves how to reach their goal. This empowerment and autonomy – together with a supportive incentivisation scheme – are a critical, albeit oft neglected, component of the success of lean manufacturing. (I’ll explore this more in future posts on the Jidoka workshops.)
Next I briefly run through a chalk-n-talk description of the classic elements of jidoka: detect the fault; stop everything; fix the problem; fix the cause of the problem. (I believe there’s a fifth element, whose importance is increased in the software development domain: measurement. More soon.)
At this point we move on to the centrepiece of the session: a simulation of a manufacturing line. The participants group into circles of around 10 people, with each person acting as a machine in a production line. (On reflection, having the groups stand in a line, instead of a circle, might have been clearer.) Each line will play Chinese Whispers, using as input a phrase supplied by me. The last person in each line writes the resulting “sentence” on a whiteboard at the front, and the results – usually very funny – are compared to the original. There ensues a brief discussion about late discovery of faults etc.
I then invite each team to re-design their process in order to achieve better results next time around. The only constraints are that the message must be passed to every team member by whispering. Most teams toy with pair-listening (these are agile programmers, after all), and with repeating back the sentence after hearing it. Many then settle on some variation of supplementing the whispering with a written version of the text. We then re-run the game, this time with much better – although rarely perfect – results. (If there’s loads of time available at this point, we may repeat this process, allowing the teams to explore ways to eradicate the small errors that crept in last time.)
Having seen the dramatic improvements in quality that can result from empowering a team to design its own process, we move on to mapping jidoka to software development. In teams or as a group (depending on the time available and the number of participants) we explore the four steps (detect, stop, fix, prevent), looking for things we already do under each heading. The takeaway from this session is that the ‘prevent’ step is what makes the approach economical, and I will continually bring the discussion back to that area so that we explore ways to change and evolve software development processes. Then we wrap.
(There’s a session handout too, which is essentially a dump of the SoftwareJidoka squidoo lens.)