This is Lean is a high level book about lean, the philosophy of lean, not the methods and tools. The book was written by Niklas Modig, a Swedish researcher. He spends most of the book framing lean as an operational business strategy. I’m sure there is a large amount of bias from his academic experience leading to that conclusion, so I wouldn’t mind reading another book that frames lean some other way. If you’re aware of a book like that, let me know 
Summary
If I had to summarize the book in a few words, I’d say it is about two types of efficiency; flow efficiency and resource efficiency. Resource efficiency is the degree to which your resources are utilized. Are your machines running all day every day? Are your programmers spending 8 hours a day writing code? Then you have 100% resource efficiency. Flow efficiency is about getting whatever you’re making done as fast as possible once cash exchanges hands. I’m am not really sure what would constitute 100% flow efficiency though, maybe a product being completed with no wait periods.
Resource and flow efficiency
At a superficial level, it seems like these two things go hand in hand, but that isn’t the case. It is not theoretically possible to have 100% resource efficiency and 100% flow efficiency at the same time. Resource efficiency requires that you have a queue of orders already made, all of the product inventory readily available, basically everything has to be waiting in line to keep your resources busy. Resource efficiency creates secondary needs such as a need for inventory, inventory management, bug tracking systems, and project managers.
Flow efficiency on the other hand means that you need extra resources to be available at a moments notice. So, people, machines, resources, whatever will definitely not be utilized at maximum capacity.
The book describes the goal of lean as attempting to make flow efficiency as high as possible while keeping resource efficiency at a reasonable level. You want to satisfy customers quickly, but not at the expense of the business.
Examples
The intro to these topics is done through a example framed in the healthcare industry. Two patients discover symptoms suggesting some type of cancer, one patient experiences the healthcare system modeled around getting the highest resource efficiency possible, the other patient goes through a system oriented for flow efficiency.
One patient has to go to an appointment, get a referral, wait, go to another appointment, wait, get another, referral, wait, and on and on. The other goes to a facility with all types of doctors and equipment, gets a diagnosis, a referral to another doctor in the same facility, and begins treatment that same day. It is not so clear to me which situation is ideal. While one patient has to wait a long time to begin treatment, the other is immediately thrown in which may be emotionally tragic or alternately could be bad if there is an erroneous diagnosis. I think this is a good illustration of that even if 100% resource and 100% flow efficiency could be achieved at the same time, is might not always be a good thing.
Personal opinion
Overall, I liked the book a lot. It talks about lean as a philosophy or a goal, not a means. Lean isn’t about kanban, or inventory levels, or a tidy work space, it is about how much you have improved from yesterday. Lean is about focusing on where you currently are, and where you want to be. Other lean books I have read so far focus more on specific methods and tools to use in order to be lean. I think this is where agile went wrong. There is a conversation in the book that I really enjoyed in this regard. The writer had one of the creators of the Toyota Production System to his factory to evaluate how lean they were. They would walk around and observe this and that and the writer would ask the question of “Are we lean?” and he was repeatedly met with the reply of “Interesting…”. At the end of the tour, the writer asked the question once more, “You’ve seen everything now, do you think we are lean?”. The reply was different this time: “How would I possibly know that, I wasn’t here yesterday.”
How this book has changed my work
I started a new gig not too long ago and this book helped me to see product flow in a new light. As a result, I made three suggestions: shorten the length of the sprints, do less stuff each sprint, and get testable builds earlier and much more often. With the support of the development group, we were able to achieve all three of those. Releases are MUCH more smooth now. This isn’t about sitting on laurels though, so we’ll have to find the next thing to improve and see how that goes.
Recent Comments