Just in Time doesn’t mean exactly when the raw material is needed - it means just before it’s needed. This concept can certainly be applied in an agile software development process to ensure that story cards don’t spend too long in any column before moving to the next one. The reasoning in our case being that the knowledge behind the analysis/development of them is at its greatest just when the card has completed that stage.

If you make defects you have not worked - this is related to the idea of building quality into the process. You are not adding value if the work that you produce has defects in it. This is quite an interesting contrast to the more typical 'hours worked' approach whereby the productivity in these hours is not considered to be that important.

The job of team leaders is tomake life on the gemba (i.e. shop floor) better. This has some similarities with the Tech Lead role on software projects where the person playing that role will spend a lot of their time reflecting on the development process and looking for ways to make it work better. This can be through driving pair rotation on a team, running analytics on the code to find areas of weakness, helping t setup test frameworks etc. Reflection on these types of things is the only way to drive improvement.

Stop defects moving through the system - this is achieved in agile by having story kickoffs and walkthroughs, the former to ensure that everyone is clear what is expected of a story and the latter to ensure that those criteria have been met. Catching defects early makes them much easier to fix since the story is still freshly in the head of the developers that worked on it.

Stop the line for defects - the idea here is to prevent defects from moving through the system, similar to the above point. In this case I’d have thought it’s more similar to not wanting code to be checked in on a red build so that the problems can be fixed before the line continues so to speak. It does seem a bit over the top to stop people checking in just because the build is red though, a better strategy perhaps being a team discipline to not check in when this is the case.

Don’t automate for the sake of it - look for manual improvements in the process before deciding to automate something. I think this is quite interesting as automating processes in software development is not as costly as it would be on a production floor. One area where maybe there is more debate is automated acceptance testing using UI driven tests. These can often take ages to run as part of the build when there may in fact be better (also probably automated) ways of testing the same functionality. In this case perhaps recognising that there are options when it comes to automating is the key take away.

There were several mentions of standardising the approach which is probably more applicable to manufacturing than software development, although there are certainly areas, such as debugging, where a standardised approach would probably be more effective.