Lean Development – A team approach to Software Application Development

Lean Development – A team approach to Software Application Development

1. Introduction

Some of the best-known Software Development Methodologies are the Waterfall model, the Iterative Development model and the Agile Model (like Extreme programming).

During the boom of e-business applications Dr. Bob Charette came up with the “Lean Development” paradigm. According to the National Institute of Standards and Technology Manufacturing Extensions Partnership’s Lean Network, Lean Development is “A systematic approach to identifying and elim nating waste through continuous improvement, flowing the product at the pull of the customer in pursuit of perfection1”. But when applied to software development it translates to “Lean Software Development reduces defects and cycle times while delivering a steady stream of incremental business value 2.”

But putting the same in simple words, Dr. Bob Charette calls it “Creation of change-tolerant software”. We will deal with principles of lean development in this note, but it must be remembered that none of the principles are new in themselves, but their collation under one theme that is well focused, makes them particularly powerful.

2. Background

Lean Development (LD), has its origins in lean manufacturing, as was perfected by Taiichi Ohno (co-developer of the Toyota Production System). To get a better idea, we must understand that lean principles rely on ‘reducing waste’. Let us examine
some of the lean building blocks used in production systems and their relevance in software development.

Pull System – This is a technique for producing parts at customer demand. Manufacturers have historically operated using a Push System, building products to stock (per sales forecast), without firm customer orders. In the software context,
practitioners tend to visualize the bigger picture and long-term view of the software application. This has traditionally delayed projects, as decision-making on technology components becomes complex, or end-users lose interest. Modular or phased implementations have advocated making applications on user demand, more incrementally and showing benefits all the way.

1 Kilpatrick, Jerry. Lean Principles.
2 Windholtz, Mark. Lean Software Development.

Work Cells – This is a technique of arranging operations and/or people in a cell (U-shaped, etc.) rather than in a traditional straight assembly line. Among other things, the cellular concept allows for better utilization of people and improves
communication. Waterfall methodology tries to compartmentalize people into stages (those who gather requirements, the system analysts, the designers or architects, the coders, the testers etc.). This results in tending to rely on individuals (or skills of a coherent group) for excellence and quality. Teamwork, which works like a cell (complete in most if not in all respects of software development) has been used quite effectively in agile programming models.

Total Productive Maintenance – TPM capitalizes on proactive and progressive maintenance methodologies and calls upon the knowledge and cooperation of operators, equipment vendors, engineering, and support personnel to optimize machine performance. Agile programming or extreme programming tries to mimic such concepts by using feedback, rather than pre-planning, to ensure results are closer to expectations. The same can be extended to Total Quality Management (TQM) also. SEI CMMI compared to SEI CMM proposes a more integrated view to reduce defects and improve quality. SEI CMMI model stresses more on overall capability rather than individual exceptions.

Quick Changeover (a.k.a., Set Up Reduction and Single Minute Exchange of Dies) – This is a technique of reducing the amount of time to change a process from running one specific type of product to another. The whole concept of LD is to develop ”change-tolerant” software.

Batch Size Reduction – Historically, manufacturing companies have operated with large batch sizes in order to maximize machine utilization, assuming that changeover times were “fixed” and could not be reduced. Because LD calls for the production of parts linked to customer demand, the ideal batch size is ONE. However, a batch size of one is not always practical, so the goal is to practice continuous improvement to lean principles. In software many practitioners including proponents of LD stress on gradual development and deployment to help the user see early benefits.

Download

Download full paper At
http://www.enjineer.com/forum