The history of software development is studded with stories of failure; projects that fall short on time, budget constraints, customer satisfaction and fitness for use. The breakaway from conventional waterfall models and the rise of agile, iterative methodologies, however, promise considerable improvement. Lean software development borrows from the universally effective Lean principles of manufacturing and extends the foundations of Agile development to render a practicable platform for building successful software.
The Lean chronicle
It all started in the mid-twentieth century at the Toyota Production System. Masterminded by Taiichi Ohno, it involved ‘just-in-Time’ production that focused on removing waste – anything that did not contribute towards customer value. The underlying ‘Lean Principles’ have since been successfully applied to product designing, logistic, supply chain, construction and engineering. Mary and Tom Poppendieck performed the first actual mapping of these principles onto software development and released a book titled Lean Software Development: An Agile Toolkit (2003). The authors identified seven principles for the new paradigm that focuses on customer value, communication flow and the people involved to deliver faster, better quality software. Lean software development is not a methodology per se, but a set of guidelines to formulae best practices for your environment. Its philosophy rejects rigorous upfront planning and requirements elicitation followed by stringent conformance to the plan and trying to “do” it right the first time’ in favor of a composite platform focused on short, iterative, feedback-enabled delivery cycles, on people and learning not speculation and on only performing activities which add to customer value.
Lean vs. Agile
Apparently, Lean and Agile seem intricately interwoven because of their common focus on software quality, development efficiency and staying open and adaptive to changing customer requirements. However, the two differ considerably due to the inherent mindset. The Agile methods focus on close customer coordination and the rapid, incremental delivery of working software is mostly limited to the specific software development activities. While Lean development views Agile as suitable, supporting practices, its scope can extend to enterprise-wide practices and the business context governing the software. While Agile can often introduce ‘waste’, eliminating the same is at the very core of Lean. Moreover, Agile has a number of methodologies (Scrum and XP etc) while Lean does not have any; it is a way of thinking as well as an enabling environment containing recommended practices.
The Lean principles
These are the seven Lean Software Development principles as envisioned by Mary and Tom Poppendieck.
This fundamental Lean principle is about analyzing the customer-perceived value from software initiation to delivery and systematically removing anything that does not contribute to this chain. The seven wastes of software development are:
Partially done work – that ties up resources like inventory in manufacturing.
Extra processes – such as too much paperwork and insignificant, avoidable activities.
Extra features – since they introduce additional complexity, effort, cost and overhead for the life of software.
Task switching – as people work on multiple simultaneous projects wastes time, causes interruptions, is counterproductive and slows things down as compared to everyone doing one thing at a time.
Waiting – for things to happen during planning, designing, documentation, reviews, approvals, testing, deployment and management activities probably amounts to the greatest waste.
Handoffs – are about movement of records and written information among groups and people and are prone to waste since not all the knowledge can be encapsulated in documents; later leading to relearning, lost opportunities and overheads.
Defects – that go undetected or return from production generate extra work and rework, adding to costs and resources.
Lean argues that development is a continuous learning process, unlike production which sticks to a ‘plan the work and work the plan’ philosophy. Learning needs to be amplified by incorporating short iterations laced with constant feedback and acclimatization to variability and change resulting in working software increments. Additionally, immediate testing and integration of code to avoid defect accumulation, experimenting with code to elaborate ideas, gathering requirements and feedback through prototypes and working directly with the immediate customer are all recommended.
Keeping your options open for as long as possible and delaying what may be irreversible decisions until the basis is certainly known, rather than tentatively assumed or forecast, can avoid and impede the costs of change. This is a crucial response to the inherently uncertain and dynamic environment of software and advocates committing only when customers have adequately analyzed their needs. It reduces uncertainty and risk, adds value, curbs complexity and leads to realistic promises and satisfied customers.
The basic idea is to deliver faster than customers can change their minds. Short, iterative delivery cycles have empirically shown to substantially reduce requirement changes. Besides resulting in frequent feedback, increased flexibility, smaller wait cycles for customers and a chance for them to get a “feel” of the software, it also allows the customers to make decisions when they are sure of what they want. It is crucial for the development team to develop responses to these decisions as soon as possible.
Empower the team
Lean values the importance and contribution of people over rigid processes, especially when it comes to decision- making which, it argues, should be made through empowerment and mutual commitment of the team members and not on management instructions to ensure speed and effectiveness. This allows the team to gel, stay motivated and require a sense of responsibility and ownership. Although it makes sense to delegate relevant decisions to the people involved in the day-to-day work, it can all go haywire if roles and expectations and not clear and agreed-upon across the board.
Build integrity in
Integrity exists on two levels. Perceived integrity is the customer’s experience of software and Conceptual integrity is how well the software architectures and components perform. An unrestricted, detailed information flow from the customer to the technical team and among the team members is necessary to achieve integrity and align expectations. A test-centric approach backboned by automated test suites, should investigate the code early, repeatedly and thoroughly to ensure integrity is a feature of the software.
See the whole
Lean suggests that the conventional approach of breaking the whole into smaller parts and optimizing each part actually results in sub-optimized software if focused on just the parts but not their interactions; their complexity being proportional to software size. The suggested solution is to work and measure performance at a level higher than usually associated with a unit; team performance and accountability, for example, instead of an individual’s.
A viable option, though not without its limitations, Lean implementation in its entirety does require considerable change in organizational processes and culture. Its principles accompanied by sound project management, however, can inspire far better results in any development effort.
About the Author