Toyota “Stop the Line” mentality
It was years ago when I first heard of the manufacturing concept of “stop the line whenever something goes wrong”. At the time, it seemed crazy…why should everyone stop what they are doing just because one person has a problem? After all, others can continue working, and they’ll just get a little ahead.
Once I started learning lean, I thought that it was about maintaining the flow, and not building up inventory. More recently, I have understood something else:
“When something go wrong, the cause is almost always inherent in the system”.
In other words, when we “stop the line” it is because we want to understand the cause of the problem, and create a solution that eliminates the cause.
How is this applicable to software? Developers become inured to day-to-day problems. Few developers would consider saying “stop work – the ASP.NET form life-cycle is too complex for our needs”, or “stop work, the deployment is too manual and error prone”.
There is even a culture wherein individuals get recognition for working around problems, rather than solving root causes. Let Tom do the deployments, because Joe screws it up. Anne is good at working with the complex ASP.NET lifecycle, what a great developer she must be!
Its not exactly wrong – Anne is more skilled, Tom is more careful, they should be commended for that. But they did not go the extra mile – to automate and error-proof the process. Why would they – they have not been trained to do it, and their manager would probably chastise them for wasting time if they tried.
We have not been taught scientific thinking practices, such as “Plan, Do, Check, Act“. We’re woefully uneducated when it comes to the basic tools that would allow us to improve our own processes. We are not even aware that it should be our responsibility to improve the process.
Process improvement? That’s someone else’s job – I’m here to code!
That’s an easy line to buy – when you think of process as a big, abstract thing. However, if you take a look at the day-to-day things that we do, then there are many, many opportunities to improve. The real challenge is to have the right thinking tools (PDCA or similar), and to just try.
The most interesting fact that today, i see same article:).
Although I do not remember there may be a link to the source,
but probably not – but your site look solid.
Great post. Again, Toyota is getting the best of the common sense approach. If you get down to the bottom, all their philosophy is about applying pure common sense over bureaucracy and rigid management hierarchy.
[...] Flow diagram is a very good starting point for stop-the-line or retrospective meeting. Here is a real example from TargetProcess [...]
[...] 두고 찬찬히 읽어보길 권한다.) Cumulative Flow 다이어그램을 잘 활용하면 라인 정지(stop-the-line)[4] 나 애자일 회고(retrospective)를 시작해야할 시점을 쉽게 발견할 수 있다. [...]