Customer Value Through Lean, part 1

I haven't blogged in a while so let's do some blogging! I recently saw the below image in Twitter:

I'm not (yet) familiar with William Glasser's work, but I'm willing to believe this. Maybe that's actually one reason why I write this blog: to learn. So, let me try to teach you something about Lean. And this is somewhat personal and subjective lesson, not a result of sound scientific research. Hopefully the facts are close to reality. If you find an error, consider dropping me a comment.

Origins

Lean has it's origins in Japanese car manufacturing. Specifically Toyota had developed a very well performing production system which later become well known as Toyota Production System (TPS) and people from different countries have tried to copy. But it is not as simple as taking the separate practices and rolling them out in your environment. It's the whole package. (You might want to check The Machine that Changed the World by Womack et al.)

Some essential topics in Lean are Continuous Improvement, maximizing the flow of value and respecting people. (I'm not anymore sure about what is Lean, what is Kanban, Scrum or just good way of doing things. I've read too much about processes and methods and my mind has started making it's own synthesis...)

Wastes, Support work and Value Adding work

Many people who aren't that familiar with Lean, are at least familiar with eliminating waste. Waste can be characterized as everything in your chain of actions (value chain) that the customer is not willing to pay for. This includes waiting, unnecessary movement, time spent for finding things, defects, producing too much of something, over processing and inventory. Also I like the idea of adding underutilized employee talent to this list.

Minimizing the inventories is also closely connected to the notion of a pull system. Let's say you have three baskets. From the third one you sell products to your customers. The two first ones represent some work stages where you add value to the end product. If you want to minimize your inventories, you can wait until customer buys something from the third basket. This creates a vacant spot in the basket. At the same time it triggers you to finalize one piece of work from the second basket and move it to the third. While you do this, there will be a vacant spot now in the second basket which you can fill.

You would probably also want to aim for a one piece flow. Large patches are usually typical source of waste, because you have too much money tied in your inventory and you might end up producing things your customer doesn't want.

But the main thing is not really about eliminating waste. It's also about identifying which parts of the value chain are value adding. And with value adding I mean things that add value from the customer's point of view. Observed separately from your internal point of view they even appear as waste. Good rule of thumb is something that the customer is willing to pay for.

Third category of work is the mandatory non-value adding work. These are things that do not really add value, but are necessary. Many support functions like bookkeeping go into this category. You cannot totally squeeze them out, but you should try to minimize the amount of time spent on them.

Processes

Another key Lean principle are well defined processes and accompanying metrics. If you can't measure it, you don't understand it. You get what you measure. You can't improve if you don't know where you currently stand. There are quite many phrases about measuring, but I guess there must be something behind them.

Once the processes are defined, you can start improving them. In Lean jargon this is called kaizen. Radical changes have a different term, kaikaku. Big organizational changes definitely are kaikaku rather than kaizen. In software development if you are applying Scrum or Kanban practices, you probably already have working practices for continuous improvement. For teams the events are Retrospectives. In my own role as Release Train Engineer I hold retrospectives that span beyond team levels.

Usually processes will always have a bottleneck somewhere. This means a limiting value for the flow of value. And when you remove it (with some awesome kaizen practices), the bottleneck will be somewhere else. But you will never get perfect. You can always improve.


I need to get back to this subject later. There's much more. Slack, queue theory, WIP etc. Really interesting...