More on Muda, Mura, & Muri

from http://3point4.wordpress.com/

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.

MURA

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.

MURI.

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)

Advertisements

One thought on “More on Muda, Mura, & Muri

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s