Lean Manufacturing

Lean raised from lean manufacturing, it was developed by the Toyota executive Taiichi Ohno (1912-90) during post-Second World War reconstruction period in Japan. It is production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination. Working from the perspective of the customer who consumes a product or service, "value" is defined as any action or process that a customer would be willing to pay for. The focus of lean manufacturing is on driving rapid, continual improvement in cost, quality, service, and delivery, significant environmental benefits typically "ride the coattails" or occur incidentally as a result of these production-focused efforts. Lean production techniques often create a culture of continuous improvement, employee empowerment and waste minimization, which is very compatible with organizational characteristics encouraged.

Lean thinking is about understanding the management principles behind both pillars... (Just in time and Quality). It involves never-ending efforts to eliminate or reduce ‘Muda' (Japanese for waste or any activity that consumes resources without adding value) in design.

Goals of lean:

To eliminate waste – Anything which is not adding value to customer is waste like insufficiently tested module, unnecessary code & functionality.

To amplify learning – The best approach for improving a software development environment is to amplify learning.

The learning process is to speed up by usage of short iteration cycles – Each one coupled with refactoring and integration testing. Increasing feedback via short feedback sessions with customers help when determining the current phase of development and adjusting efforts for future improvements.

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.

Deliver as fast as possible – 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.

To empower the team – Artificially organized teams - when a team's structure is fixed by upper management with little knowledge of the requirements, customer or the personalities of the team itself - can create situations where personnel are under-utilized. In the worst case, projects fail simply because of poorly organized teams. In an agile development environment, the team is empowered to organize themselves in a way which allows them to be most effective and efficient.

To build integrity in – The customer need 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. 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 – "Think big, act small, fail fast; learn rapidly“– This summarizes the importance of being lean. 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.

Lean Characteristics & Benefits:

Delivering the product early is a definite advantage. It means your development team can deliver more functionality in a shorter period of time, hence enabling more projects to be delivered. This will only please both your finance department, but also the end customers. Empowerment of the development team helps in developing the decision-making ability of the team members which in turn, creates a more motivated team. This benefit really cannot be over stressed enough. Developers hate nothing more than being micro-managed and having decisions forced upon them. This way they can determine how best to develop the functionality which will usually result in a much better end product.