Lean Oven Beets

I wanted to make some oven beets (beetroots) for lunch. The process for making those was simple and I wanted to make it as lean as possible.

Raw material was a bag of beetroots, about 30 pieces. It will represent the supplier. Then there are two necessary working phases which add value to the customer. The beetroots need to be first peeled. Then they must be sliced into bits. Finally they go into the pan.

Process Flowchart.

The production plant could be set up in different ways. But in order to eliminate waste, everything should preferably be close to avoid unnecessary motion and transportation. With only two work phases there's not many places for inventories, but one possible place would be between peeling and slicing. If you first peel all the beetroots, you need to keep them somewhere before the slicing. But if you work in a one piece flow, you don't need any extra storage between the phases. Then there's also no over production, because one beetroot is always enough to enter the next work phase.

My factory had only one employee who needed to task switch between the phases. There was also some need to move. With two employees this could have been avoided. But unfortunately recruitment for housework is sometimes really hard.

Factory setup: Sink, Work Phase 1, Work Phase 2, Pan.

Keep things tidy and in order. When the equipment is on their places they are easy to find. Keeping your gear in good condition (knives sharp) makes your process more efficient. With tools fit for purpose, like my peeling knife, you can not fail. You can cut off just the skin and no valuable beetroot is lost. In lean this mistake-proofing is referred as Poka-yoke.

Proper peeling knife. Poka-yoke.

Fortunately the supplier had provided me with so good material that there were no defects. Quality control happened visually before the peeling phase.

Because the employees were both trained in continuous improvement and empowered to make changes to the plant layout, they came up with a slight process improvement after the first half of the work. The need for movement was decreased by moving the pan closer to the slicing place.

Factory layout mark 2: More compact.

When the materials ran out, the plant was simply shutdown. No capital was left in inventories. In the end, the customer received a pan full of sliced beetroots. As she had ordered.

After shutdown and clean-up.

In the text above I have tried to identify different types of waste and write them with italics. One could argue this wasn't a process, but a project. If the work would have continued, there would have been a need for a proper disposal of beetroot peelings. They were simply piled and thrown to garbage after the work was completed. But how to do this properly in a continuous process is left for the reader as homework . ;)

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...

DIY Build Light Indicator

This post will differ from my typical posts. It's not about processes or methods. But actually it's related to the practice of Continuous Integration. That's one of the key engineering practices most Agile teams use. Originally proposed by Grady Booch, but later popularized as one of the eXtreme Programming practices. For many Continuous Integration is simply "that build system".

There are many free and commercial tools available for CI. I have actually played around with CruiseControl (not much and I've never actually configured any builds in CC. It was more or less fading away when I joined my company), TeamCity (this one I like a lot), Jenkins and lately Bamboo.

The problem with all these CI tools, and all other online tools, is that you need to navigate to a specific place to find out if the build is passing or not. Similar thing for a Scrum wall or Burndown chart if you use for example JIRA. For us physical humans the physical things just work well...

The build light is a remedy for this. It converts the status of the build in our CI tool to a physical form: colored light. If the light is green, the build is passing. If the light is red, someone needs to fix the build ASAP! This kind of information radiator can easily spark action and foster self-organization.

Making yourself a build light isn't that difficult nowadays. In our case the most difficult thing was to get a Phillips hue Starter kit. With that you get a light that you can control with your computer. Then you will need a CI tool. In our case we connected our build light to a Bamboo build.

Then maybe the most difficult part: you need the glue code between your CI and your lamp. But today that's not too difficult either. Node-RED has made the task of connecting our physical devices to internet lot easier. (I'm not sure if it was difficult before. I'm just assuming it was.) Instructions for connecting your hue to Node red can be found from this blog post. (Actually before you get to use Node-RED, you will need node.js installed.)

But skipping ahead a few steps you get this: voila! Now we can diminish the "is the build passing?" questions. Simply check the lighting. If it's pleasant green you have nothing to worry. :)

Our buildlight. Who broke the build!?