Kaizen in Software Development: Start by Seeing the 7 Wastes

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.

4 Comments

  1. Rajdeep

    August 13, 2006 - 11:32 pm

    I have had some involvement in applying lean principles in software programming environment. It was before my current job in a bank and that time I was experimenting with applying lean thinking to SW work.
    Most of the points that we experimented with were based on our Quality discussions (I used to be an MBB), picked off literature on the internet or some books/ sites.
    The first thing I tried was in how the software project team is structured and works.
    Earlier we would have a tech/ IT department that had a URF (User Requirement Form) which the requesting department would need to fill out with details about what they need in full specs. Then get it viewed by all relevant people, approved by their line managers, sign off on the version and give to IT. Post that IT would do a detailed time estimation, UAT schedules (that were months out) and roll out dates etc
    This was the biggest NVA because we were pushing paper, worried about the sign offs, IT was working on buffering their time budgets and the requesting department (customer) was never happy to begin with.
    So we applied the first principle of lean – to reduce the waste of information. We got the ITteam and gave them an overview of what we want to do, give a vision of what we expect the thing to look like, and what is the likely impact on us and on the customers. Post that we asked the IT team to only get the information that is going to be used in the next 4 weeks of development work.
    And then we would meet every 2 weeks to relook at this information requirement and plan the next 4 weeks.
    IT VP and his team did not like it. Their big worry wsa the project would never get done and we would take forever to tweak things and last mile would take 50% of the time.
    But the existing reality was:
    How many times have projects completed on time? How many times would you say the user were happy/ comfortable?
    How many times is the team that got the project/ UAT done was happy with the result?
    So anyway it took long, did not benefit the requesting department in a way they wanted and instead of the last mile, the first mile took most of the time.
    A huge level of trust was required to think that we are all working for the same company, we all want to do what is right for the business.
    Another factor was that sr. guys thought that if we don’t take up everything at the beginning, projects would never get done, how will we estimate costs and how will we align resources to future projects if we don;t know when this one gets over … Which is fair. You need to build up a level of knowledge and trust before you can start estimating these things. This again takes trust and time.
    These things are important and should be factors in resourcing. They should not be the main factor going in and the prouduct actually revolving around it.
    In reality we did do a lot of iterations towards the end of the project – things like, change the color to yellow, no, now chnage it to pink etc. Because we were working closely, these were 1 hour sessions where we would finalize 1-2 things and then move on.
    As a result of our experiment, we also ended up trying one more thing. As few handoffs as possible. Because of the experimental nature of what we were doing, we asked for a dedicated team of 4 developers with needed skills and a senior guy to co manage the project.
    What this did was that the developrs were only working on one project at a time. Their own estimate was that earlier they were working on 3 or more.
    Working on only 1 project and not multitasking drove up their own productivity.
    Overall, the project took about 60% of time that the initial IT estimate was. Costing was fuzzy because of the multitasking nature of the developers. But the developers and the department that asked for the software could not be happier. In fact the team that wanted the product said that this is the best in house developement they have ever seen.
    Broadly speaking, we worked on – inventory (of information), waiting time of specifications before someone worked on them and motion (because the developer would go from one project to another)

  2. Jon Miller

    August 14, 2006 - 5:24 pm

    Thanks Rajdeep! That is a great example of Lean principles applied to software development.

  3. Mark Lindberg

    November 1, 2006 - 12:03 pm

    Jon,
    I would like to include this article in our APICS chapter monthly newsletter. Do I have your permission?
    Mark Lindberg

  4. Jon Miller

    November 1, 2006 - 12:55 pm

    Mark,
    That would be great. Yes you have our permission.
    Jon