Go see. Stop and fix it.
I’ve read a fair bit about Lean Manufacturing and Lean Software Development. Lean Manufacturing is old and Japanese and not really related to Agile at all. Lean Software Development is an attempt to apply some of those ideas to software development. It shares a lot in common with the values and principles of the Agile Manifesto. There are two ideas from Lean that I really like. I call them “Go See” and “Stop and Fix It”. Go See is pretty easy to implement. Stop and Fix It is much harder to implement but will have more effect.
These two ideas are actually not in the seven principles of Tom and Mary Poppendieck’s “Lean Software Development“. Maybe they should be. So what does “Go see” really mean?
Go See, aka Gemba
One of the foundation principles of Lean Manufacturing is Gemba. This Japanese word roughly translates to “the real thing” or “the real place”. It is strongly associated with the idea of the actual source or place that an event is occurring. For example, a journalist who is reporting live from somewhere like an actual war zone or crime scene would be said to be reporting from “gemba” (as opposed to from a newsroom or something).
The Gemba concept in Lean is that the best way to understand what is happening in a system is by personally visiting the place of the system. So if a manager wants to know how a factory is working, they should go have a walk around the factory floor and see for themselves. As opposed to the traditional management way, which would be to read a report or look at a spreadsheet or organise a conference call with some supervisors or something.
The LeSS (Large Scaled Scrum) book describes this as “Go See”, which I think is a good English translation. As in, “go see for yourself”. The principle applies just as well to software as it does to physical manufacturing. Managers should be regularly if not constantly walking around and looking at what is going on, i.e. doing a “Gemba Walk”. They should be regularly observing standups.
This is not “spying” or “sneaking about”, they should be completely transparent that they are there and watching. An experienced observer can pick up lots of clues from things like body language, the arrangement of work on a Visual Management Board, or even how furniture is arranged and how people are sitting and working. Things they wouldn’t get from looking at graphs or reading reports.
Different types of Gemba
There are actually two different types of gemba. There is the place of value creation, and the place of value realisation. Both are important.
Value creation is the place where the work is done to build a product or service. It could be anything. In the case of Lean Manufacturing, it is probably a car factory. In the case of Agile software development, it is probably the place where the developers are building an app or similar. Value realisation is the place where customers actually get value out of your product. So it is when and where people are driving your car, using your software, and so on.
People usually do Gemba walks in the place of value creation. But don’t forget the value realisation place, either. Get out of the building and go talk to your customers!
Stop and Fix It
Another concept in Lean is “Stop and Fix it”. You won’t actually see this in a book like Lean Software Development. I saw it best explained in the excellent book “High Velocity Edge” by Steven Spear. The idea is that if there is a problem in a system, any problem in any system, it is everyone’s responsibility to stop whatever they are otherwise doing and fix the problem.
Andon cords
In Toyota car factories, this is implemented via something called “Andon cords”. These are big cords that hang from the ceiling in the car factory. If there is a problem anywhere that needs attention, and cannot be quickly fixed by one person, they pull the cord. Pulling the cord shuts down the whole assembly line. Everyone stops working on whatever they are doing and comes over to help sort out the problem. This might sound insane, but it isn’t. This is Toyota we are talking about here, the most successful car business on the planet. They pretty much invented Lean and they know what they are dong. Andon cords encourage a culture where problems don’t lie around and take root. They get fix and fast. Which means the rest of the business can then restart and keep going.
This is genuinely hard
Imagine for a moment if every time you encountered a problem at your work, you stopped and tried to fix it, and didn’t go back to your job until it was fixed. Every time you encountered a wasteful process, got blocked for no good reason, got frustrated with a bad feature of a crappy piece of software, you stopped, and fixed it. If you needed help, you asked for help and whoever you asked dropped whatever they were doing and helped until it was fixed. “But that’s impossible!” you’re probably thinking. “I wouldn’t get anything done!”.
Well, nothing would get done for the first few days. Or maybe the first couple of weeks. Then things would start getting better. And better, and better. Since problems went away, and people would be very careful not to let them come back, because they knew what would happen. How many defects do you think Toyota lets into its manufacturing process, knowing that just one will cause their entire production at a plant to shut down?
Andon fail
If you know of any organisations that have implemented this (besides Toyota obviously), please let me know about it in the comments, I’d be very interested to hear about it. Interesting fact: a US car company tried implementing Andon cords. Nobody ever pulled them. After some investigation by management, they discovered the reason. The car workers had performance incentives tied to how many cars rolled out of the factory. They didn’t want to pull the cords because it would lower their productivity and therefore their bonus. There is a very powerful lesson there, on a number of levels:
- culture cannot be imported or “fixed”, it is an outcome of existing structural and HR systems
- if you don’t change those systems, cultural change will always fail
- local optima produce a global sub-optimisation
- KPIs and bonuses are generally a terrible idea (and we’ve all known this for a long time).
So let’s ditch the stupid bonuses, and do some real continuous improvement. Because it’s not just retrospectives – it is the responsibility of the whole organisation and we need to do it all the damn time.
