Muda, TSA Style

From Seth Godin’s blog:

Don’t snowglobe me, bro

Snowglobe How important is it? Is it so important you need to interrupt everyone, every single one of your customers?

There are only a few signs on my way through security, yet there, on the biggest of all, is a warning about snow globes. Snow globes are apparently a big enough threat/cause for confusion that they get their own sign.

Every time you interrupt your prospect or consumer, you better ask, “is it important enough…” Most of the time, it’s not. Most of the time, the interruption is a selfish, misguided effort by a committee that doesn’t get it.

Yes, I know the TSA doesn’t care about customers. But it’s a good lesson for anyone who does.

Don’t snowglobe me. Interrupting everyone so you can properly alert one person in a thousand is just silly.


Bottom line… just because we can cc everyone, doesn’t mean we should.


Lean Thinking

Lean Thinking: What is Distinctive About It and Where is It Going?

Marc Baker discusses the origin of Lean and how it has developed into a complete business system. He also reviews the current frontiers of lean thinking and practice and wraps it up with insights from lean transformations for IT and software development.

More on Muda, Mura, & Muri


Agile maps to Lean – Muda, Mura and Muri

Posted on February 10, 2009 by krshna

Dr. Shigeo Shingo and Mr. Taichi Ohno have contributed immensely towards improving production processes at Toyota through concepts Muda, Mura and Muri. They enriched the Toyota Production system now became to be called as famous Lean Production system.

Let us try to understand the meaning w.r.t Industry in general and software development in particular.

Muda : Non value added activity or waste.

Mura : Unevenness or inconsistency

Muri : Overloaded or excessive strain

Reworks, multiple compilations and check-ins after code is developed due to inadequate design are some of the classical points of wastes in software development. In Scrum management, project team delivers sprint in prefixed duration called sprints, during which different types of Muda elements are need to be avoided, so that maximum number of prioritized stories can be burnt during the current release. If upstream activities like Architecture, Design and Planning have been carried out effectively then during the sprints there will be less abnormal variations leaving the teams with little rework to be done. Since Agile adapts to the changes from stakeholders requirements that means true to the Lean Management it wonderfully implements pull system from product owner and makes changes in the upstream activities like backlog management and priority settings. Hence optimized upstream Pull systems along with adequate upstream activities like good design and test activities will ensure that Muda in the system is eliminated to minimum.

Muda examples in software development :

Multiple check-ins and compilations of code : This will happen because of inefficient resources or not understanding the requirements of the customer specs. This is most critical factor in making the software defect prone. If we can ensure that right resources with right skills prudently understand, define, design and develop the system, we can avoid maximum rework.

Delaying testing to the end of the life cycle. Not testing the application till the end of the life cycle means that undiscovered defects, risks are carried till the end of the product development. This will create huge rework and heavy costs to the organization. These reworks can be identified and corrected by being iterative in development and use tests early in the life cycle. The test suites should be automated and the integration of code also should be automated. This will ensure less waste in the system.

Waiting time due to many handoffs in the product life cycle. In typical waterfall development models every phase artifacts should be approved by next in process stakeholders and if the stakeholders are occupied the work products simply get stagnated leaving some people in the system to remain without productive work. If we follow the peer reviews, group reviews and tester-developer collaboration from early on the wastes arising out of wait time can be overcome.


Not following standards / tools / best practices :

If a particular application is tested by five different people it produces 5 completely different results. Even different developer develops a particular module in different Ways. The best way to bring about consistency in development and testing is to make everyone follow the standards, conventions and policies of particular organization based on their own best practices. Using tools like FxCop, Cruise Control and other development / testing tools will reduce inconsistencies in outputs of resources. When inconsistency (MURA) is removed from the system the predictability towards estimation, cost will be better. This will lead help the product owner with high degree of certainty in bringing the product to the market on time. For the software organization it will results in more business.

Not understanding requirements, ambiguity in requirements, not capturing implicit and no functional requirements. Avoid these MURAs

Multiple contacts from software organization as well as customer side without taking a common view on the product evolution. Avoid these using transparent stakeholders’ collaboration by white boarding and sharing.


Excessive strains put on the development teams and expecting unrealistic outcomes with less time available. This can be the result of under estimation / poor planning w.r.t scope, schedule and skills. Prioritization of product backlogs by understanding the variables like resource, time and ability should be done properly to avoid these kinds of strains. It is better to negotiate with customer either on increasing the sprint duration or team size as it may be feasible, instead of over committing. This will help us avoid customer dissatisfaction as well as increase the team morale. In Agile scenarios even the customer is not always sure about what the market wants and hence the software vendors should not just act as mere vendor catering to the needs of the customers but also work consultatively to help customer get his product rolled to the market in reasonable time and high quality. This will increase customer confidence on the software vendor and therefore better business.

Other MURIs could be understaffed teams and less or almost nil tools and making teams work longer hours due to poor planning. All these MURIs should be avoided by following Good Project Management principles.

This is just a thought on mapping the great Toyota Gurus concepts to software development scenarios. Suggestions welcome here.

Possibly related posts: (automatically generated)

Muda, Mura, and Muri


 Muda (無駄) is a traditional general Japanese term for an activity that is wasteful and doesn’t add value or is unproductive, etymologically none (無)+ trivial or un-useful (駄) in practice or others. It is also a key concept in the Toyota Production System (TPS) and is one of the three types of waste (Muda, Mura, Muri) that it identifies. Waste reduction is an effective way to increase profitability.

A process adds value by producing goods or providing a service that a customer will pay for. A process consumes resources and waste occurs when more resources are consumed than are necessary to produce the goods or provide the service that the customer actually wants. The attitudes and tools of the TPS heighten awareness and give whole new perspectives on identifying waste and therefore the unexploited opportunities.

Muda has been given much greater attention as waste than the other two which means that whilst many Lean practitioners have learned to see muda they fail to see in the same prominence the wastes of mura (unevenness) and muri (overburden). Thus whilst they are focused on getting their process under control they do not give enough time to process improvement by redesign.


Mura (斑 or ムラ)[1] is traditional general Japanese term for unevenness, inconsistency in physical matter or human spiritual condition. It is also a key concept in the Toyota Production System and is one of the three types of waste (Muda, Mura, Muri) it identifies. Waste reduction is an effective way to increase profitability. Toyota merely picked up these three words with prefix mu-, which every Japanese know, as product improvement program or campaign.

Mura is avoided through Just In Time systems which are based on little or no inventory, by supplying the production process with the right part, at the right time, in the right amount, and first-in, first out component flow. Just in Time systems create a “pull system” in which each sub-process withdraws its needs from the preceding sub-processes, and ultimately from an outside supplier. When a preceding process does not receive a request or withdrawal it does not make more parts. This type of system is designed to maximize productivity by minimizing storage overhead.

For example:

  1. The assembly line “makes a request to,” or “pulls from” the Paint Shop, which pulls from Body Weld.
  2. The Body Weld shop pulls from Stamping.
  3. At the same time, requests are going out to suppliers for specific parts, for the vehicles that have been ordered by customers.
  4. Small buffers accommodate minor fluctuations, yet allow continuous flow.

If parts or material defects are found in one process, the Just-in-Time approach requires that the problem be quickly identified and corrected.


Production leveling and frequent deliveries to customer are key to identifying and eliminating Mura. The use of different types of Kanban to control inventory at different stages in the process are key to ensuring that “pull” is happening between sub-processes. The use of Heijunka will aid in scheduling work in a standard way that encourages lower costs.

It is also possible to smooth the workflow by having one operator work across several machines in a process rather than have different operators; in a sense merging several sub-processes under one operator. The fact that there is one operator will force a smoothness across the operations because the workpiece flows with the operator. There is no reason why the several operators cannot all work across these several machines following each other and carrying their workpiece with them. This multiple machine handling is called “multi-process handling” in the Toyota Production System.


Muri (無理, “unreasonable”)[1] is a Japanese term for overburden, unreasonableness or absurdity, which has become popularized in the West by its use as a key concept in the Toyota Production System.

Avoidance of muri in Toyota manufacturing

Muri is one of three types of waste (Muda, Mura, Muri) identified in the Toyota Production System. Waste reduction is an effective way to increase profitability.

Muri can be avoided through standardized work. To achieve this a standard condition or output must be defined to assure effective judgment of quality. Then every process and function must be reduced to its simplest elements for examination and later recombination. The process must then be standardized to achieve the standard condition. This is done by taking simple work elements and combining them, one-by-one into standardized work sequences. In manufacturing, this includes:

  • Work Flow, or logical directions to be taken,
  • Repeatable Process Steps and Machine Processes, or Rational methods to get there, and
  • Takt time, or reasonable lengths of time and endurance allowed for a process.

When everyone knows the standard condition, and the standardized work sequences, the results observed include

  • Heightened employee morale (due to close examination of ergonomics and safety),
  • higher quality,
  • improved productivity, and
  • reduced costs.


One contribution of Henry Ford and his manufacturing techniques was the reduction of Muri and not so much the production line itself. In order for the production line to function each station on the line had to achieve standard work because the next station was only equipped to work on standard condition components.

The Ford production line approximates to an implementation of Takt time which gives enough time to perform the standard work.

The Seven Wastes

One of the key steps in Lean and TPS is the identification of which steps add value and which do not. By classifying all the process activities into these two categories it is then possible to start actions for improving the former and eliminating the latter. Some of these definitions may seem rather ‘idealist’ but this tough definition is seen as important to the effectiveness of this key step. Once value-adding work has been separated from waste then waste can be subdivided into ‘needs to be done but non-value adding’ waste and pure waste. The clear identification of ‘non-value adding work’, as distinct from waste or work, is critical to identifying the assumptions and beliefs behind the current work process and to challenging them in due course. Breakthroughs in SMED and other process changing techniques rely upon clear identification of where untapped opportunities may lie if the processing assumptions and beliefs are challenged.

The expression “Learning to see” comes from an ever developing ability to see waste where it was not perceived before. Many have sought to develop this ability by ‘trips to Japan’ to visit Toyota to see the difference between their operation and one that has been under continuous improvement for thirty years under the TPS. Shigeo Shingo, a co-developer of TPS, observed that it’s only the last turn of a bolt that tightens it – the rest is just movement. This level of refined ‘seeing’ of waste has enabled him to cut car body die changeover time to less than 3% of its duration in the 1950s. Note that this period has allowed all the supporting services to adapt to this new capability and for the changeover time to undergo multiple improvements. These multiple improvements were in new technologies, refining value required by ‘downstream’ processes and by internal process redesigns.

The following seven wastes identify and classify resources which are commonly wasted. They were identified by Toyota’s Chief Engineer, Taiichi Ohno as part of the Toyota Production System:

One More Waste

Any failure to fully utilize the time and talents of people is a waste of talent.


  • muda, 無駄 translation to English on Sanseido “EXCEED Japanese-English dictionary“.
  • mura, 斑 translation to English on Sanseido “EXCEED Japanese-English dictionary“.
  • muri, 無理 translation to English on Sanseido “EXCEED Japanese-English dictonary”.
  • Jeffrey K Liker: The Toyota Way. McGraw-Hill. 2003.
  • James M. Morgan, Jeffrey K. Liker: The Toyota Product Development System: Integrating People, Process and Technology. Productivity Press. 2006.
  • Mary and Tom Poppendieck: Implementing Lean Software Development: From Concept to Cash. Addison-Wesley. 2006.
  • Donald G. Reinertsen: Managing the Design Factory. A Product Developer’s Toolkit. Free Press. 1997.
  • Allen C. Ward: Lean Product and Process Development. Lean Enterprise Institute. 2007.
  • James P. Womack, Daniel T. Jones: Lean Thinking. Touchstone Books. 1996.
  • Shigeo Shingo, A study of the Toyota Production System, Productivity Press, 1989
  • Ohno, Taiichi, Toyota Production System, 1988, Productivity Press