After reading The Goal and The Phoenix Project, I realized that I'm a sucker for a business novel. After a bit of searching, I settled on the book by Freddy Balle and Michael Balle entitled The Lean Manager: A novel of lean transformation.
The book's setting is in an automotive part plant in France that is under threat from closure. Andy, the books protaganist, agrees a deal with the CEO, Phil (also his mentor), that if the plant becomes competitive it will not close. It's a familiar setting from other books, I suppose the concept is that the best catalyst for change is adversity.
What did this book teach me?
Standardized work and kaizen are two sides of the same coin.
For a long time, I've resisted the idea that standardizing any work to do with programming is a good thing. The best teams I've worked in have always had implicit coding standards created by being a closely knit team unafraid to voice concerns when standards (even if they are only in the heads of a few) weren't met. The idea of explicitly setting coding standards (and I'm not talking about tabs vs. spaces, more in the style of 101 Coding Guidelines for C++) has always been an anathema for me. I think the reasons for this are simple; I used to think standards implied something external to the team influencing how they work.
Standardized work is about agreeing how the work should be done best, to better see the problems. Kaizen is about encouraging operators and frontline supervisors to solve all the problems that appear as gaps to the standard.
I realize this is talking about manufacturing, not software engineering, but the idea of defining a standard and viewing a gap to the standard as a problem is a powerful one. As a stupid example, let's say you define automated acceptance testing as standard for all new features, but fail to meet it. Why x 5? What can you learn from this that changes the way you develop software? By stating a standard and holding yourself to account you see the problems and force a conversation about it. Standardized work encourages problem solving (kaizen) by acting as a tool that allows you to have the right conversations.
Another key theme from the book is the idea of "go and see". The best way to learn is to go and see. This applies everywhere. Go and see (Genchi Benbutsu) teams, Go and see customers. Go to the place where the work happens and magic will happen. Again, this sounds like a very simple thing (management by wandering around) but it's deceptively powerful when adopted as a deliberate technique (or at least, it is in the book!).
Visual Work Management is another tool in the Lean toolbox. Part of Go and See is being able to immediately recognize problems. We already have something like this in the software engineering industry with build status monitoring (Siren of Shame!). What else could we visualize? The advantage of the automative industry is the takt time is often short (if customers are demanding 10K units a week, the takt time is in minutes). In Software Engineering, our sprints are often weeks. It's difficult to know if things are going off the rails. Perhaps some elephant carpaccio is in order?
Does go and see translate to software engineering? Definitely for some parts, namely visiting customers and understanding their requirements (
customers want holes, not drills). Does this apply at other times, such as when teams are writing code? I suspect it does; the only way to understand why teams are flying or struggling is to actually see them in action.
The last big theme from the book was that developing people is just as important as developing the product. The idea is simply that once *everyone* is contributing to product improvement and innovation then you've built yourself a significant advantage that is almost impossible to copy.
All in all, The Lean Manager was an enjoyable read. I'm not sure how many of themes adapt perfectly to software engineering, but definitely food for thought!
