Template builder - Plugin Template

Womack, Jones and Roos published two successful books entitled “the machine that changed the world” (1990) and Lean thinking (1996). Both books address the revolutions in manufacturing represented by the Toyota production system of the Toyota Corporation of Japan. They compared this way of working with the traditional mass production system that was used by other companies in the western world. They described in their books Lean thinking the following five principals:

Toyota Production System (TPS)

Toyota developed the Toyota production system (TPS). TPS borrowed ideas from ford but developed the just in time philosophy (JIT) pull concept to address the issues or high cost associated with fords large inventories. The Toyota production system in an integrated system, that comprises of its management philosophy and practices.

Philosophy

• Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals.

Process

• Create a process flow to surface problems
• Use pull out systems to avoid overproduction
• Level out the workload(Heijunka)
• Stop when there is a quality problem (Jidoka)
• Standardized tasks for continuous improvement
• Use visual control so no problems are hidden
• Use only reliable, thoroughly tested technology

People & partners

• Create leaders who live the philosophy
• Respect develop and challenge your people and teams
• Respect challenges and help the supplier

Problem solving

• Go see for yourself to thoroughly understand the situation
• Make decision slowly by consensus, thoroughly considering all options : implement decisions rapidly.
• Become a learning organization through relentless reflection (hence) and continuous)

House of quality

Toyota visualized its values, principals way of working and the ,most important tools in the Toyota house of quality, the roof of the house expresses the goals of the organization (best quality -lowest cost-shortest lead time-best safely- high morale). The foundation of the house addresses the principles, followed by number conditions that are always needed. Here you can find standardized work and visual management. There are two pillars. The first pillar is called Jidoka and is about building in quality thaw second pillar is called Just In Time and inclines a number of logistical principles and tools. In the centre of the house you will find the continuous effort of improving the organization.

Within the Toyota production system the following three types of variation can be distinguished:

Muda : waste, uselessness, non-value added or idleness

Muri : overburden, impossible, beyond one’s power excessiveness.

Mura : unevenness, irregularity or lack of uniformity.

These are also called the 3 M’s of lean. The reduction of these types of waste is the fundament of the Toyota production system to increase effectiveness and profitability. For each of the three types, we will review a number of principle and techniques to reduce the type of variation.

Improvement KATA

The Improvement Kata grew out of the Toyota Production System as a structured way to create a culture of continuous learning and improvement. A kata is any structured way of thinking and acting that you practice until the pattern becomes a habit. Through practice, a pattern of behavior becomes second nature.

The 4 steps in Improvement KATA

The 5 Questions

• What is the target condition?
• What is the actual condition now?
• What obstacles do you think are preventing you from reaching the target condition?
• What is your next step? (next PDCA/experiment)
• When can we go and see what we have learned from taking that step?

Reducing Muda (waste)

Reducing Muda can be achieved by assuring that a process will not consume more resources than are necessary to produce the goods or provide the service that the customer actually wants reducing Muda can be achieved by avoiding activities that do not add value to the product, meaning producing ‘first time right’ without loss of materials, loss of resources, rework, repair and waiting. In most Lean programmes this is the first variation that will be addressed because it is easier distinguished that the other types. Also redesigning processes or products (innovation) can result in using fewer resources.

A value adding activity must meet the following criteria: the customer is willing to pay for the activity; it must be done correctly the first time and action must change the product or service in some way. If one of these criteria is not met, the activity is classified as a ‘non-value adding activity and therefore as ‘waste or Muda’ which should be eliminated. Initially there were 7 types of waste, but many acknowledge also an 8^th type of waste. Necessary activates are needed to keep the process running. These activities cannot (easily) be deleted but should be limited as much as possible.

1. Over production Producing more than asked by market
2. Waiting Waiting idling or defect equipment
3. Transport Transporting materials or products
4. Over processing Taking unneeded steps to process parts
5. Inventory Unnecessary supplies or stock
6. Movement Searching unnecessary supplies or stock
7. Defects Faults, scrap or bad quality
8. Unused expertise Not using existing expertise or knowledge

Reducing Muri (overburden)

Reducing Muri can be achieved through producing according to takt time, implement ‘flow’ and standardized work. Flow should be observable and every process step must be reduced to its simplest elements or components. The number of different components and specialized steps throughout the organization should be limited. Limiting the number of different screws for instance will result in fewer tools, less training, less stock, less mistakes etc. A world class example of this is the truck producer scania. This principle is also known as ‘smart customization’. Muri can also be avoided by not pushing equipment or employees to the edge of what they are capable of. Working overtime for a longer period, bad ergonomics and pushing out preventive maintenance increase Muri.

Reducing Mura (unevenness)

A common misunderstanding is that improving productivity is working faster. Lean however has not the intention to treat every job as a sprint and to complete every task as soon as possible. Lean is not about increasing speed, but about reducing unevenness in speed in order to increase predictability which will create a smooth and regular basis for further improvement initiatives.

Lean IT

The core idea is to maximize customer value while minimizing waste. Simply, lean means creating more value for customers with fewer resources.

A lean organization understands customer value and focuses its key processes to continuously increase it. The ultimate goal is to provide perfect value to the customer through a perfect value creation process that has zero waste.

To accomplish this, lean thinking changes the focus of management from optimizing separate technologies, assets, and vertical departments to optimizing the flow of products and services through entire value streams that flow horizontally across technologies, assets, and departments to customers.

Eliminating waste along entire value streams, instead of at isolated points, creates processes that need less human effort, less space, less capital, and less time to make products and services at far less costs and with much fewer defects, compared with traditional business systems. Companies are able to respond to changing customer desires with high variety, high quality, low cost, and with very fast throughput times. Also, information management becomes much simpler and more accurate.

Lean IT principles

Lean development can be summarized by seven principles, very close in concept to lean manufacturing principles:

1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build Quality in
7. See the whole

Eliminate waste

Lean philosophy regards everything not adding value to the customer as waste. Such waste may include:

• unnecessary code and functionality
• delay in the software development process
• unclear requirements
• avoidable process repetition (often caused by insufficient testing)
• bureaucracy
• slow internal communication

In order to eliminate waste, one should be able to recognize it. If some activity could be bypassed or the result could be achieved without it, it is waste. Partially done coding eventually abandoned during the development process is waste. Extra processes and features not often used by customers are waste. Waiting for other activities, teams, processes is waste. Defects and lower quality are waste. Managerial overhead not producing real value is waste.

A value stream mapping technique is used to identify waste. The second step is to point out sources of waste and to eliminate them. Waste-removal should take place iteratively until even seemingly essential processes and procedures are liquidated.

Amplify learning

Software development is a continuous learning process with the additional challenge of development teams and end product sizes. The best approach for improving a software development environment is to amplify learning. The accumulation of defects should be prevented by running tests as soon as the code is written. Instead of adding more documentation or detailed planning, different ideas could be tried by writing code and building. The process of user requirements gathering could be simplified by presenting screens to the end-users and getting their input.

The learning process is sped up by usage of short iteration cycles – each one coupled with refactoring and integration testing. Increasing feedback via short feedback sessions with customers helps when determining the current phase of development and adjusting efforts for future improvements. During those short sessions both customer representatives and the development team learn more about the domain problem and figure out possible solutions for further development. Thus the customers better understand their needs, based on the existing result of development efforts, and the developers learn how to better satisfy those needs. Another idea in the communication and learning process with a customer is set-based development – this concentrates on communicating the constraints of the future solution and not the possible solutions, thus promoting the birth of the solution via dialogue with the customer.

Decide as late as possible

As software development is always associated with some uncertainty, better results should be achieved with an options-based approach, delaying decisions as much as possible until they can be made based on facts and not on uncertain assumptions and predictions. The more complex a system is, the more capacity for change should be built into it, thus enabling the delay of important and crucial commitments. The iterative approach promotes this principle – the ability to adapt to changes and correct mistakes, which might be very costly if discovered after the release of the system.

An agile software development approach can move the building of options earlier for customers, thus delaying certain crucial decisions until customers have realized their needs better. This also allows later adaptation to changes and the prevention of costly earlier technology-bounded decisions. This does not mean that no planning should be involved – on the contrary, planning activities should be concentrated on the different options and adapting to the current situation, as well as clarifying confusing situations by establishing patterns for rapid action. Evaluating different options is effective as soon as it is realized that they are not free, but provide the needed flexibility for late decision making.

Deliver as fast as possible

In the era of rapid technology evolution, it is not the biggest that survives, but the fastest. The sooner the end product is delivered without major defects, the sooner feedback can be received, and incorporated into the next iteration. The shorter the iterations, the better the learning and communication within the team. With speed, decisions can be delayed. Speed assures the fulfilling of the customer’s present needs and not what they required yesterday. This gives them the opportunity to delay making up their minds about what they really require until they gain better knowledge. Customers value rapid delivery of a quality product.

The just-in-time production ideology could be applied to software development, recognizing its specific requirements and environment. This is achieved by presenting the needed result and letting the team organize itself and divide the tasks for accomplishing the needed result for a specific iteration. At the beginning, the customer provides the needed input. This could be simply presented in small cards or stories – the developers estimate the time needed for the implementation of each card. Thus the work organization changes into self-pulling system – each morning during a stand-up meeting, each member of the team reviews what has been done yesterday, what is to be done today and tomorrow, and prompts for any inputs needed from colleagues or the customer. This requires transparency of the process, which is also beneficial for team communication.

Empower the team

There has been a traditional belief in most businesses about the decision-making in the organization – the managers tell the workers how to do their own job. In a “Work-Out technique”, the roles are turned – the managers are taught how to listen to the developers, so they can explain better what actions might be taken, as well as provide suggestions for improvements. The lean approach favors the aphorism “find good people and let them do their own job,” encouraging progress, catching errors, and removing impediments, but not micro-managing.

Another mistaken belief has been the consideration of people as resources. People might be resources from the point of view of a statistical data sheet, but in software development, as well as any organizational business, people do need something more than just the list of tasks and the assurance that they will not be disturbed during the completion of the tasks. People need motivation and a higher purpose to work for – purpose within the reachable reality, with the assurance that the team might choose its own commitments. The developers should be given access to the customer; the team leader should provide support and help in difficult situations, as well as ensure that skepticism does not ruin the team’s spirit.

Build Quality in

The customer needs to have an overall experience of the System – this is the so-called perceived integrity: how it is being advertised, delivered, deployed, accessed, how intuitive its use is, price and how well it solves problems.

Conceptual integrity means that the system’s separate components work well together as a whole with balance between flexibility, maintainability, efficiency, and responsiveness. This could be achieved by understanding the problem domain and solving it at the same time, not sequentially. The needed information is received in small batch pieces – not in one vast chunk with preferable face-to-face communication and not any written documentation. The information flow should be constant in both directions – from customer to developers and back, thus avoiding the large stressful amount of information after long development in isolation.

See the whole

Software systems nowadays are not simply the sum of their parts, but also the product of their interactions. Defects in software tend to accumulate during the development process – by decomposing the big tasks into smaller tasks, and by standardizing different stages of development, the root causes of defects should be found and eliminated. The larger the system, the more organizations that are involved in its development and the more parts are developed by different teams, the greater the importance of having well defined relationships between different vendors, in order to produce a system with smoothly interacting components. During a longer period of development, a stronger subcontractor network is far more beneficial than short-term profit optimizing, which does not enable win-win relationships.

Lean thinking has to be understood well by all members of a project, before implementing in a concrete, real-life situation. “Think big, act small, fail fast; learn rapidly” – these slogans summarize the importance of understanding the field and the suitability of implementing lean principles along the whole software development process. Only when all of the lean principles are implemented together, combined with strong “common sense” with respect to the working environment, is there a basis for success in software development.