APICS Northern Colorado

It's worth repeating time and time again that what makes an organization Lean is not whether they have implemented the methodologies, tools and procedures that people recognize as part of the Toyota Production System model. In other words what is important is not whether you have kanban systems or don't, or whether you produce in u-cells or with giant machining centers.

The kaizen philosophy is the thinking behind why you choose to do these things. What's important is that you have the kaizen philosophy of never being satisfied, taking action now and always making things better based on looking at the facts and asking "why?" until you find the root cause.

You can have a very good physical and system level copy of TPS and still lose money. Many U.S. automotive firms are proving this. The Lean methods, tools and procedures may look similar to and even be award-winning, but aren't really kaizen without the thinking. This thinking extends beyond the factory in to how everyone solves problems. When the problem is "we have no orders" or "we are not making money" then problem solving can't be limited to the factory.

When we see Lean expanding into new areas or new industries it's common to see this same copying of form but not the thinking behind it. It's much easier for companies to rearrange the people, machines and materials than to rearrange what's in the heads of leaders. Software development may be one of these areas.

I spoke to a friend who is a Microsoft programmer last month. He described several recent projects (he was unsure but thought they were Six Sigma or Agile) that basically involved documenting the entire development process and adhering very closely to it. Measuring a process and setting a baseline standard sounds like a reasonable approach. Yet he reports that the success rate with this approach is still about 50%.

Based on our experience in teaching Lean principles to people who are not familiar with them, the lack of understanding by the Microsoft programmers on the "why are we doing this?" may be a big contribution to the low success rate. Defining the software development methods, tools and procedures seems to be where the focus is at the moment.

But what about kaizen? Rather than new tools, faster methods or defined procedures why not start by seeing the waste? If programmers agree that waste is bad, then choosing a tool or method to get rid of that waste becomes more natural to the way they work.

What are the 7 types of waste a programmer should look for?

Overproduction could be adding in features and processes that are not needed, or not needed right now to support the current version and the needs of the market. Imagine if software did only what we needed it to do? How much of what you see on your screen right now is "pushed" at you?

Transportation is always a difficult one to identify in the knowledge work arena, but anytime distance (such as distance between development centers) creates artificial batches and economies of scale, you have the avoidance of transportation waste as a cause. If you could code it, check it, build it one at a time with no transportation delays would you have a better software product?

Motion waste can be a wide range of things since due to keyboard interface software development is largely manual labor. Any movement of hands, movement of pieces of code, building of code, etc. that doesn't get you closer to a good finished product would be a waste of motion.

Waiting if you're having to multi-task, you're probably waiting for something. I'd like to imagine that programmers have lightening-fast machines and never have to wait for anything to happen, but there are probably times when you have to let you code compile, test, etc. before you can see the results of your work and come back to kill bugs.

Defects would be bugs, bad code, all of the things that make my Windows PC crash. I wonder how much of the work programmers do is correcting and rework versus simply creating something new that they know will work correctly the first time? How much of that is truly inventing something new and how much of that is knowing what to select? Building quality is in is where standardization, better tools, procedures, and methods comes in. Looking for bugs after a lot of coding has already been done is pretty much the opposite of jidoka, which is to check the quality of work early and often and stop the work when as soon as a defect is found.

Processing waste would be things like redundant lines of code, or code that is a less elegant (i.e. longer) than it needs to be, or methods of programming that add extra steps. Meetings, from what I have heard, are often a form of wasted processing at software developers.

Inventory is harder to see in knowledge work but this would be any "work in process". Any project or part of a project you are working on but is not complete would be inventory. It has labor and thought added into it, but is not ready to ship. So it has a cost. The key thing with inventory is not to explain it away or accept that it is inevitable, but to understand that it is a waste and root cause of that inventory is where you should focus kaizen.

It's been 25 years since I took a programming class, and I think that was Basic on a TRS 80 so I would be interested in hearing from any real programmers out there if this makes any sense.

Certified Lean Master

File Repository