jidoka at SPA2006

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…

muda workshop 1 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.)

designing metrics at SPA2006

The second session I attended at SPA2006 was Designing metrics for agile process improvement, run by Jason Gorman and Duncan Pierce. Their thesis is that metrics are difficult to design, and making a mistake can lead an organisation down the wrong path entirely.

vernier To demonstrate this, they divided us into four groups and assigned us each a “goal”. My group’s goal was “more frequent releases“. We had to brainstorm metrics that might act as measures of an organisation’s progress towards that goal, and then pick one to carry forward to the remainder of the exercise. We spent some time thrashing around wondering why an organisation might have such a goal, and finally we plumped for the metric average time in days between releases.

At this point, one person in each group took his group’s metric to the next table, where that group (minus one) would attempt to “game” it. The objective of this part of the afternoon was to try to get the metric looking right, but such that the organisation was clearly doing something very undesirable behind the scenes. Our table was joined by Sid, bringing along a metric whose stated goal was “fewer bugs in the product” and whose metric was number of bugs per function point per release. During the next half-hour we had great fun trying to find ways to write more bugs, while still having fewer per function point. These included testing previous release really hard and fill up the bugs database, then hardly test future releases at all; and making it really difficult for users to report bugs. Meanwhile another group was gaming our own metric, by producing zero-change releases and by saving up releases into rapid-fire batches all at once.

Next, if I recall, we had to re-design our original metrics in the light of the panning they had received in the hands of the gamers. We ended up measuring the goal of “more frequent releases” using the metric days per story point between customer feature request and customer acceptance. We tried to phrase it so that it averaged out over easy and difficult features, and so that the count forced us to release the feature to an end user. This neatly side-steps all attempts at gaming (that we could discover), and is roughly equivalent to throughput – or to Kent Beck’s software in process metric.

For the workshop’s final segment, we recognised that a single metric by itself is rarely sufficient to direct process improvement. Change one thing for the better and something else may well slip out of line. Jason and Duncan’s thesis is that we need a system of metrics, each of which balances the others in some way. So as a final exercise, we began an attempt to take the metrics of all four groups and weave them into a system, showing which measures reinforced which others etc. For me this is the key observation from the whole afternoon, and I would like to have spent more time here. I had never really seen the attraction of Systems Thinking, but these models derived from the need for metrics do seem to be a good application of the technique. Food for thought indeed…

thinking at SPA2006

This year my stay at SPA2006 is limited to only one and a half days. Nonetheless I plan to attend some interesting sessions, and in the next few posts I’ll describe my impressions of them. The first of these was Thinking for a Change:

In this 3-hour workshop Pascal van Cauwenberghe and Marc Evers led us through the construction of two of the five Theory of Constraints Thinking Tools. We divided into groups, such that each table comprised one “customer” – someone who had a problem to be solved – and a number of “consultants”. The objective was for each group to build a Current Reality Tree for their customer’s problem, and then to build a Future Reality Tree for a possible solution. The problem on our table was set by Emmanuel Gaillot, who wanted to understand some specific behaviour of the managers in an organisation he had worked with.

Now, I had already read the book Thinking for a Change, and frankly found it quite disorganised. Pascal and Marc had also found the same, so for this workshop they had picked through the book and defined a step-by-step process for building CRTs and FRTs. They took us through this process just-in-time, at each stage showing us the next step using their worked example, and then giving us 5 minutes to perform the step on our own problem. This made for an absorbing three hours, in which we actually got to try the whole process from end to end on a real-life situation.

Unfortunately our group got a little bogged down at various times, mostly due to our particular problem being way too large to solve in a dozen 5-minute chunks. Nevertheless we had fun, and we gained practical experience of building a CRT and a FRT.

jidoka at SPA2006

I’ll be running my trusty Jidoka workshop again soon, this time at SPA2006 in March. I ran the same session at XPday in London last November; see feedback from Lasse.

Lean manufacturing is based on two pillars: Pull and Jidoka. Agile methods focus most of their attention only on Pull: customers pull features or user stories from the development team, and the development team carries out every task just in time and without building up inventory. Jidoka – the policy of stopping the production line whenever a fault occurs, and then fixing both the fault and the cause of the fault – has been largely forgotten. Jidoka is what keeps value flowing fast through the process, iteration after iteration. And yet there are no published studies or collections of Jidoka practices as applied to software development.

The session’s objectives are to learn about Jidoka on a production line, and to discuss its application to adapting a software development process in a learning organization. Participants will play a Jidoka Game which demonstrates the beneficial effects of “stopping the line”. The group will then work together to describe, discuss and discover “jidoka moments” – points at which software development projects are, could be or should be stopped in order to prevent faults passing downstream. It’s a fun session, and I hope informative too.