Tuesday, 2 August 2011

Lean Software Development: An Agile Toolkit

Poppendieck & Poppendieck (2003) borrow the notion of 'lean' from Taiishi Ohno's Toyota Production System approach and adapt the system to software development. The guiding principle behind the idea of 'lean' software development is to eliminate waste in the form of inventory stock and piece work dwell times from any and every aspect of work possible. In borrowing lean principles and terminology, which were developed for physical goods manufacturing, how does 'lean' apply to software's 'perfect' manufacturing environment (perfection in this sense meaning to software's potential for its manufacture of exact copies of an original via digital copying)?

Waste is present in the guise of unnecessary formality and management overhead.
Extensive documentary efforts lead to waste, excessive communication (meetings) lead to waste, excessive processes, interruption, delays and defects all lead to waste in the software process.
Using the 'lean' model requires that we apply tests to work activities to establish their validity.
"A good test of the value of paperwork is to see if there is someone waiting for what is being produced." (Poppendieck & Poppendieck, 2003:5) They note that the most wasteful work around documentation efforts surrounds attempts to produce documents that "contain all of the information that the next person in line needs to know." (p7) Explicit documentation requires infeasible completeness; rely instead on tacit knowledge and direct communication between producer and receiver. The cases given in this book emphasise processes of communication, on incremental delivery, communication with customers, taking care to produce and give what is really needed, delivering simplest possible meaningful feature sets as quickly as possible.

All software is partially done, or rather is always potentially subject to change. Because software is amenable to change and its requirements are difficult to establish unambiguously software development processes are designed to reduce risk. Managing large software developments is an inherently risky process (Royce, 1970). In industry two polar extremes are taken by attempts to address risk: to establish perfect clarity prior to commencing the work, or to get feedback by producing something as early as possible (to give producer and customer a concrete artefact to explore, clarify, negotiate and make sense of. Lean takes the second position as its goal. P&P paraphrase Royce (1970) by stating that "every step in the waterfall process except analysis and coding is waste." (Poppendieck & Poppendieck, 2003:4). However Royce's own position was that "there are two essential steps common to all computer program developments, regardless of size or complexity. There is first an analysis step, followed second by a coding step... This sort of very simple implementation concept is in fact all that is required if the effort is sufficiently small and if the final product is to be operated by those who built it" (Royce, 1970: 328).

Value stream mapping is one way of describing the 'as-is' situation and preparing to change current processes and the balance of effort invested in development. Lean thinking applies the view that early feedback reduces waiting, the goal for which is to free the developer somewhat and the customer too, to give each the opportunity to clarify meaning and learn from each other what is desired, desirable, degrees of freedom and constraints. The implication of providing and giving early feedback is to recast the idea of who controls and manages development, instead control or management figure through involvement in production. Development may at this extreme be better understood as co-production. How then is this heightened communication between customer and developer attained?

  • Poppendieck, M. & Poppendieck, T. (2003) Lean Software Development: An Agile Toolkit Upper Saddle River, NJ, USA, Addison Wesley.
  • Royce, W. W. (1970) Managing Development of Large Scale Software Systems. IEEE WESCON. TRW.


SA 1: Is the use of a manufacturing metaphor in what is clearly a field of design and development work strictly applicable?

SA Note 1: The two fields of design and manufacturing are both conceptually and physically different. Certainly software duplication does not require the sorts of controls and efficiencies sought for in scaling production of physical goods manufacture. For digital media the finished product is absolutely the end of the story. More importantly, in the case of software a shift of focus from reproducing a digital good towards the work of designing the good is absolutely necessary. Software development's focus must be upon everything that precedes the production of the first copy of the end product. The manufacturing metaphor has limits when applied to software development however the principles of 'lean' are still relevant and applicable to software's activities: design, analysis, coding etc.