Lean manufacturing in software development

Francisco López-Lira Hinojo

TCPPI, Spain
flopezlira@tcppi.com

This article has the intention to answer -from the author point of view- the question of how can be lean manufacturing applied to software development.

Enter Lean Manufacturing.

Lean Manufacturing (LM) or Toyota Production System has its roots in the work made by Taiichi Ohno and Eiji Toyoda (nephew of Taichii Toyoda) in Toyota between 1948 and 1975. It is an organizational way to approach the work that seeks to eliminate the waste (muda in Japanese) in a production system. LM is based on several principles (Liker, 2006):

1. Have a long-term philosophy
• Follow long-term goals, not short-term financial goals
• Generate value for the customer, society and the economy
2. Right process = right results
• Create a continuous process flow in order to link process and people together and bring problems to surface
• Use "pull" systems to avoid overproduction - Avoid stocking inventory (Just in time)
• Level out the workload - Avoid spikes and peaks
• Build a culture of stopping to fix problems, to get quality right the first time
• Use standardized tasks and processes as the foundation for continuous improvement and employee empowerment
• Use visual controls - show problems
• Use only reliable, thoroughly tested technology that servers your people and process
3. Develop people and partners
• Grow exceptional leaders 
• Develop exceptional people and teams who follow your philosophy
• Respect your extended network of partners and suppliers. Help them to improve
4. Solve root problems continously
• Go and see for yourself
• Make slow decisions by consensus and implement them rapidly
• Reflexion and continuous improvement will make you a learning organization

Several tools and techniques are associated with LM:

1. Andon - Signboard used to notify problems
2. Continous flow 
3. Takt time calculation - Average time required to fulfill customer demand
4. Kanban - Index card
5. Jidoka - Make problems visible. Automatically stop the production if there is a problem
6. Poka-yoke - Avoid inadvertent errors
7. Heijunka - Production leveling or smoothing
8. Genchi gebutsu - Go and see for yourself
9. Kaizen - Continuous improvement
10. Nemawashi -Dig around the roots of the tree before transplanting it
11. Hansei - Awareness and recognition of problems leads to improvement

Comparing software development and car manufacturing.

Before trying to use Lean Manufacturing in software development, it is important to understand the similarities and differences between producing cars and developing software:  

• The design of a car takes 2-4 years and involves the use of prototypes. Once the car design is finished you are able to setup the production system for that particular model. The production line will then generate a different car per minute or so using the same design. In software development we (ideally) have a design phase -in a waterfall lifecycle model- or a design activity -in a iterative or incremental lifecycle model- where we find the solution to the user needs and requirements. Then we can implement the solution using a programming language (translating design into coding is a syntactic problem, not a semantic one, Frederick Brooks dixit). In reality, we often design and code at the same time (des-coding) and it's not clear where design ends and where programming begins.  
• Now, a car is a complete product when it comes out of a production line. The equivalent in software development is the system or a minimum subset of the system that makes sense to the final organization. This is important because we may divide the system in features, user stories, use cases, etc.  but we haven't finished until we deliver the whole system. Even when we use an iterative lifecycle we are just delivering a part of the system
• In a car production line, the car is mostly assembled because the majority (if not all) of the pieces (chassis, wheels, seats, etc.) are produced before the car enters the line. In software development the "car" (the system) is "produced" once we have "produced" all the pieces (components) and have integrated them. We don't just assemble the solution but we "produce" the pieces and then we assemble them. In this sense, software development is not equivalent to a car production line but to all the production lines of all the pieces of the car at the same time
• Every system is different and that is equivalent to producing a different car for every customer (not a car with a different color or optional equipment, but a totally different car).
• To further complicate this scenario, in software development we don´t design all the pieces and fit them together before producing (coding) them, but instead we design and try to fit at the same time, without a comprehensive and detailed picture (there are some exceptions like Cleanroom Software Engineering, Modeling based development, among others)
• In car production, requirements are established at front and they usually don't change. If they happen to change that won't be in production. In software development, requirements may change any time
• Takt time in software development is hard to implement because the user demands all the system requirements at once. Ok, yes, we may divide the system in function points or features or user stories and estimate Takt time for a function point, for example, but again, the user needs the whole system (the complete car). We also may adopt an iterative lifecycle and elicit requirements gradually, but that doesn't necessarily mean the user needs the requirements implemented iteratively, it is a restriction established by our production capacity. To put it in another way, the user enters in the room and ask us for a car, then we start "producing" all the pieces, knowing there are going to be changes, and in the best scenario we deliver it by pieces. In any case, the equivalent of Takt time in software development would be the time to develop the whole system
• While in car production the capacity of the workers tend to be the same, in software development the difference can be 20:1 between the best and the least experienced programmer. In car production the workers are trained before entering into the production line. In software development we usually don't train programmers but instead we hire them with a established level of capacity and then we put them to "produce"

Adopting LM in software development.

Once differences between car production and software development have been established, we may try to analyze how to adopt some principles, techniques or tools of LM for software development.

• A long term philosophy of quality must be part of software development organizations
• An emphasis must be made in adding value to the customer. This involves not only eliminating non-adding value activities but also in trying to understand the customer requirements better. A robust requirements engineering phase or activity (again, depending on your lifecycle) must be realized
• We must bring problems to surface, but before that, we need to change the way problems are seen in software development, i.e., nobody must be punished for alerting about problems in the "production line". If we find problems we must stop the (related) development until they are fixed. What we do now (in general) is to pass problems to the testing phase. We must make more emphasis in quality inspections along the development and in the root analysis of problems
• We will never have an excess of inventory because every "piece" is, let say, hand made at the moment. However we must avoid gold-plating in software development
• We can avoid spikes and peaks by dividing the system in parts (features, use cases, user stories) and maintaining a leveled workload between analysts, designers and programmers
• We should standardize processes, but building flexibility into them (tailoring), and use them as the foundation for continuous improvement. Developers must be involved in the design and improvement of processes from the very beginning
• Improvement culture must surpass the project level and be embedded in the organization
• As for the elimination of muda in software development:
• Transportation muda. Not a problem for us seen as transportation, but we do move information along the participants
• Inventory muda. Not a problem either. We are always behind schedule
• Motion muda. Equipment needs to be replaced if damaged but that seldom occurs
• Waiting muda. This is actually a big problem in software development. If we use waterfall lifecycle model for example, we may have designers waiting for weeks, programmers waiting for months and testers waiting for years
• Over-processing muda. This may be a problem and to avoid it we must assure that all design and coding is tied to the requirements and nothing more, even in an iterative lifecycle where we are eliciting requirements every time
• Over-production muda. We may never be over-producing in software development
• Defects muda. This one is the biggest problem, in my opinion, in software development.
• Skill muda. We waste skills mostly when we don't involve developers in the definition and improvement of processes

 Conclusions.

While there are significant differences between car production and software development, many of the LM principles and tools may be used to improve the way we develop software.

 References.

• JEFFREY K. LIKER and DAVID MEIER, The Toyota way fieldbook: A practical guide for implementing Toyota's 4 P, (2006), Mc-Graw Hill