Communicating Lean principles, concepts, and terminology can be tricky. Many Lean terms originate in Japanese, introducing a barrier to understanding. In an effort to sidestep the language barrier, Stappan Noteberg posted this presentation on Slideshare.com. I think it’s an innovative way to show some Lean ideas and hope you think it’s worth a look. 😉
Bob Hubbard, Sept 2010
Lean Thinking: What is Distinctive About It and Where is It Going?http://www.infoq.com/presentations/lean-thinking-distinctions
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.
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)
Exclusive to thefabricator.com
Scraping the hull: Ridding your organization of barnacles
By Gary Conner, Contributing Writer
April 6, 2004
Editor’s Note: A version of this article previously appeared in the March 2004 Lean Into It newsletter.
Barnacles are a form of sea life that everyone’s heard of but probably knows little about. Many different types exist, but let’s talk about the type of barnacles that attach themselves to ships.
These crustaceans are roughly the size of a quarter, and they attach themselves to a host (ship) for life. The adhesive properties of the cement that they excrete are amazing. This small animal glues itself to a host with a compound so strong that it could hold the weight of a compact car (2,500 pounds).
Estimated costs associated with speed loss (caused by increased drag) and increased fuel consumption resulting from these marine mollusks’ growth on ship hulls are an astronomical $1.4 billion per year. “Fouling,” as it is referred to, can contribute to an increase in fuel consumption of up to 7 percent after only one month and 44 percent after six months (Swedish International Development Authority, 1986).
For ships, the traditional remedy has been a regular visit to the dry dock. There, barnacles and other organisms are scraped or sandblasted off the hull, which is then covered with a coat of antifouling paint designed to discourage their return. As long as 2,000 years ago, hulls were sheathed with lead and smeared with concoctions of oil laced with sulfur and arsenic. In 1625 a lethal recipe combining arsenic, copper, and gunpowder was considered worthy of an English patent as an antifouling compound.
The danger for shipping companies is that the barnacles are hidden below the water line. Out of sight, out of mind. The only indication that fouling has occurred is the vessel’s reduced performance.
Barnacles-Non-value-added Activities Parallel
Could our companies be fouled—slowed down or consuming resources unnecessarily— by barnaclelike behaviors? How do we “scrape the hulls” of our organization to ensure smooth, unrestricted, and cost-efficient advancement?
Barnacles can be likened to the non-value-added activities we perform every day. During a kaizen event at a client company in Nevada, we performed a value-added, non-value added (VA-NVA) observation of a sawing process. The operator was a large man (325-plus pounds). He was working in 95-degree-F heat and wearing a shop coat over his coveralls. This poor man was sweating profusely, to the degree that I was worried about his health. The initial observation showed that he was able to spend only 19 percent of his day in a value-adding mode. Eighty-one percent of his day was spent on either necessary non-value-added tasks (things like paperwork and stacking parts), or, worse yet, unnecessary non-value-added tasks (activities like looking for a supervisor or a pallet).
After the kaizen team rearranged his work area, developed a new work standard, and set his operation up to run at takt time, this worker produced three times as many parts. He now spent well over 60 percent of his time in pure value-added activities (still room for improvement). At the time of our kaizen presentation, he was unaware that he was producing 200 percent more material through his two saws. Before we told him about the documented improvement, we asked him if the new layout and new work steps were easier or harder. He expressed a great deal of satisfaction with the new process, describing it as “so much easier than before.” He was producing three times as much, with less effort. Kind of like pushing a ship through water with less effort because the barnacles had been scraped off.
Organizational barnacles can grow anywhere. Engineering, order entry, purchasing, finance, and, of course, the production departments may need to be put into “dry-dock” and examined for non-value-added activities. A fabrication team VA-NVA examination found that 25 percent of its time was spent in non-value added activities. For this $14M company, this meant $3.5 million worth of potential sales opportunity was being left on the table each year.
Interestingly, after a ship has had barnacles removed, the entire hull must be treated to inhibit barnacle regrowth. So it is with organizations; sustainment is by far the hardest part of improvement. Changing the behaviors of the individuals who comprise the organization is necessary to avoid reverting back to non-value-added activities.
Kaizen must become a way of life, and one trip to the dry dock will not create a barnacle free ocean or organization. Continuous improvement is not just a program title, it is a verb, and verbs demand action. I’m sure that scraping barnacles off a ship isn’t easy work, but the rewards of improved performance and reduced costs must be worth it, because every viable shipping company in the world does it.
So, where will you start scraping?
Lean Enterprise TrainingAward-winning author Gary Conner is president of Lean Enterprise Training, 1995 Pioneer Road, Dallas, OR 97338, phone 503-831-0401, Web site www.leanenterprise.bigstep.com