In his recent post “Go Faster By Not Working” Adrian talks about how having the entire team stop when the build breaks can result in the entire project going faster.
Lean manufacturing, the precursor to the “Agile” methodologies, has the concept of “Stop the Line”. When a defect in the product is identified, the entire assembly line stops to locate and rectify the factors that caused the defect.
The major difference in a software development “line” is that there is no physical assembly line, so it is easy to blur the distinction between what is and isn’t part of the product and hence the “line”.
In the Lean manufacturing model it’s acknowledged that the cause of the defect may be more than just a faulty component. It may be the tools, processes or even the skills of the people involved in the manufacturing of the component that contributes to the defect. With the line stopped, the right solution can be found before production resumes.
In software development however, development continues. One of the problems Adrian points out is that
if developers keep working while the build is broken, they build up a large backlog of commits which makes it more difficult to identify which revision broke the build
It goes further than that however. By continuing to develop, the team and management are assuming that the defect was caused simply by a mistake in coding of that feature or the build process. What if the problem is in the development process, the tools or the experience of the developers involved?
Adrian goes on further to suggest that some companies go a little closer to a “Stop the line” approach by putting
an embargo on commits or close the source tree to prevent any further changes from being committed
Once again, development doesn’t stop, we simply stop putting things on the assembly line. Once the build breakage is resolved, all these potentially broken changes are pushed through.
By stopping the entire line, your development team can not only address the current defect, they can also perform a “Root Cause Analysis” of why the problem occurred, leading to better processes, tools and people.
So why do so many companies see “stopping the line” as a waste when it is the complete opposite?
I believe it’s based on a management perception that if you aren’t developing code directly related to the final product, in other words features or bug fixes, then you are not being productive. In addition, there is a belief that the number of hours spent coding directly relates to the productivity of the team. So a team is discouraged from taking the time to not only improve their tools and processes, but also to analyse what needs improving.
