20 November 2018
Our IT team always tries out various management techniques. And recently, we’ve made one of our most significant decisions ever and implemented the “stop the line” practice.
Actually, this was invented at the Toyota factories. The administration there was of an opinion that those who work at the assembly line understand the situation better than managers. So if there was an issue with the product on the line, any worker could push the red button and stop the whole line to deal with the cause of the problem. Of course, our IT department is no assembly line, and although flaws happen, they can’t be readily seen. We use the “stop the line” method in our own way.
Our software releases take 24 to 48 hours on average. But sometimes lots of teams come up with lots of additional patches, and then the release takes up to three days.
Such a cumbersome release is not a good thing. In three days, all our teams can develop even more features, so we will have to deliver all of them in a single patch. And the larger the patch package, the higher the risk that something goes wrong.
So if the release takes more than two days, we apply the emergency brake and stop this mammoth work altogether. Why write new code if it’s bound to get stuck in the bottleneck anyway? Instead, our teams focus on the urgent delivery of a release that got stuck and on the elimination of the cause of the delay. Then we launch our “assembly line” again.
For the fun of it, we even have a flasher. It blinks as long as the line is stopped.
We’ve used the “stop the line” practice three times already, fixing several unstable UI tests and expediting the build process.