My Jidoka and Hexagonal Architecture sessions have been accepted for XPday Benelux 2005 in Rotterdam this November. Looks like a great programme – shame I won’t be able to attend everything!
Just confirmed that I will be Agile Scotland‘s speaker on Wednesday September 7th – talking about jidoka in software development.
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. In this think-tank the participants will 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.
In no is in the air Esther Derby provides loads of good advice and links for those who just can’t say no.
I particularly liked the idea that a “no” is a fail-fast mechanism. It lets both parties know where they stand, and allows them to immediately move on to something more productive. Which aligns nicely with my current push for jidoka in all things.
In Fizzy Coke Joe Ely tells a simple story in which a little jidoka moment saved another airline passenger from wet trousers. Our software development practices have a lot to learn from this kind of thinking!
Lean manufacturing is based on two pillars: pull and jidoka. And agile software development should be no different. It is one thing to have the customer pull features or user stories from the development team, and for that development team to carry out every task just in time and without building up inventory. But it is quite another to be able to sustain that kind of emergent behaviour over even a few iterations without being beset by problems.
And that’s where jidoka comes in. This is the policy of stopping the production line whenever a fault occurs, and then fixing the fault and the cause of the fault. The time invested in doing this more than repays itself in terms of relentlessly improving quality and decreasing down-time.
This morning I workshopped for an hour or so with an agile team that has come off the rails a little recently. It seems that there are a number of obstacles in the way of them being truly agile, and in the last two weeks these have happened to conspire together, with almost crippling effect. They know what the obstacles are, but they don’t (yet) have a process for eliminating them completely. So the same problems keep on coming back time and again.
I know it has been said many times before, and I know it’s just common sense, but after a little incident this morning I think it bears repeating: When you’re ready to check in your updates, be sure to catch up with the latest version before starting the check-in process.
We – my pair partner and I – were doing a little refactoring exercise at the end of a programming episode. We decided we had done enough for now, so we’d check in what we had and move onto the next card. So we fired up the SourceSafe (I know, I know) check-in process. It told us that someone else had changed one of our source files since we had checked out. That’s good: it prevented us trampling over someone else’s work. We went through the merge items and satisfied ourselves, by eye, that we had made the right choice in each case. SourceSafe then went ahead and committed the merged version to the integration stream. Wait a minute – that means we just checked in code that had never compiled, let alone passed any tests!
Fortunately, in this case no harm was done. Our merge-by-eye had worked. This time. But any decent CM tool should behave differently, in my opinion. Instead of merging and then checking in with cavalier disregard for the consequences, it should have simply aborted the check-in process when it noticed we were out of date. So now we’re forced to adopt a convention, a team policy that says
“merge from the integration stream into your workspace before every check-in, then re-build and re-test, and only then check in.”
I very much dislike the idea of having to rely on a policy for something like this. I find it very difficult to adopt new habits, and onerous to have a whole list of things to remember each time I carry out a task. And to ask a whole team, or department, to do the same is somewhat optimistic, to say the least. We need a CM tool that “stops the line” and forces us to catch up before we are allowed to proceed. This would follow the Toyota principle of jidoka or autonomation, effectively eliminating one source of manual error and rework.
(More on catching up before checking in can be found in the literature on team streams.)
Update, 21 jun 05
Subversion gets it right, of course.
Monday was a public holiday in the UK. We had a typical British summer’s day – watery sunshine interspersed with periods of torrential rain. We needed to keep the kids occupied somewhere new and somewhere indoors, so we decided to visit Paradise Mill. Macclesfield used to be a leading centre for the manufacture of silk garments, and Paradise Mill is a fully restored working Victorian silk mill. The exhibits are great, and the tour is terrific – the kids got to try some of the work that their counterparts (they’re aged 8 and 6) would have been doing in the 1820s!
On the wall at one end of the main weaving room was a notice from the mill’s owners, entitled “Don’t pass on faults”. The mill workers were all paid according to the amount of work they did each week – for example the loom operators were paid a penny or two for each inch of completed, perfect silk cloth. The notice pointed out that any worker who did a faulty piece of work should fix it themselves, and not allow it to be found by the next worker in the process. Faulty work, the notice advised, slows down your co-workers (and so reduces their pay), slows you down (and so reduces your pay) and may create a bad impression on customers (resulting in loss of business and therefore less pay for everyone). The impact was stated just like that – baldly in financial terms.
I remembered reading that the same philosophy held in the 1920s in the Toyoda Spinning and Weaving works. But instead of writing a notice, the mill’s owner Toyoda Sakichi implemented a series of failsafe devices that automatically stopped the looms if they detected a fault. In this mill it was near impossible to pass on a fault. And this became one of the pillars of lean production – pursuit of perfect quality makes the whole process faster and more predictable.
As we know, test-driven development and the daily build help to do this for software development. A while back a very senior manager in a large multi-national dismissed my efforts to improve the agility of a group of software projects: “No defects at all? You’re living in a dreamland!” Paradise Mill, anyone?
The more I think about it, the more convinced I become that selling agile at all is a mistake. Certainly as a coach/manager, what interests me most is the ‘process’ side of things, and agile is always an interesting and rewarding approach for both me and (I hope) the software team. But what interests my bosses is more often the business value delivered to the user base.
I’ve never been someone who believed that it works to simply plonk a methodology onto a team straight from a book. Every team is different, and every business is different; enforcing conformance to some pre-determined monolith is likely to bring out as many minuses as plusses. And I believe that’s true of the agile methods just as much as it is of the heavyweight ones. What’s more, the successes I’ve been associated with have all been due entirely to having the team grow their own processes – gradually, incrementally making the changes required by the current situation. Only when the current way of working is shown to fall short in some respect does the team call a review and work out a different approach. There is never any change simply for the sake of it.
Of course the agile movement directs and informs my thinking, and hence my coaching and management styles. And all of the teams I’ve coached have become increasingly agile over time, without any of them ever consciously adopting a ‘book’ method. The stakeholders get to learn that iterative and incremental delivery is better for everyone, that feedback loops must be short, that quality helps the team go faster, etc etc. But most will never hear the words ‘agile’, ‘SCRUM’ or ‘extreme’.
In the future though, I do expect I’ll be using the word ‘lean’ a lot…