Lean Software Development: An Agile Toolkit

In the last couple of years, I have heard many times about lean manufacturing (and in particular the Toyota way of manufacturing). I have also read a couple of articles by Mary Popendieck on the web, so I thought I would get this book and find out more. I am glad I did. It is exactly the kind of book I like to read about software engineering - it is written by somebody with lots of hands on experience, it describes new and interesting techniques for producing high quality software, and it has plenty of references for further reading. It is written by Mary and Tom Poppendieck, but I get the feeling that most of the input comes from Mary. She has solid experience with software development in many roles and places. In addition, she also has extensive experience with manufacturing, and one of the biggest pluses with this book is how she shows how to transfer principles and practises from lean manufacturing to software development. The type of development they advocate is squarely in the agile camp (obvious from the subtitle as well). There are seven chapters on seven lean principles, with 22 "thinking tools" with specific practices or principles. If you are familiar with Extreme Programming (for example through Kent Beck's first XP book), you will recognize a lot of the ideas in the thinking tools. Examples are: Feedback (tool 3), Iterations (tool 4), Options Thinking (tool 7), Refactoring (tool 19) and Testing (tool 20). However, the value for me was the many ideas from manufacturing that I had not previously read about in the agile literature. Examples are: Value Stream Mapping (tool 2), Set-Based Development (tool 6), Pull Systems (tool 10) and Cost of Delay (tool 12) There is actually so much good material in this book that I will have to concentrate on just a few examples. The first lean principal is Eliminate Waste. "Waste is anything that does not add value to a product, value as perceived by the customer". This is a great starting point, and one that has many implications. Examples of waste in software development are: extra features (that are not needed now), task switching, waiting, motion (for example document hand-offs), and of course defects. With this definition of waste, a value stream map helps you to see waste by mapping where value is added, and where there is waiting etc as a product is developed. Another interesting part is tool 10 in chapter 4 (Deliver as Fast as Possible). Here the authors describe how pull systems work (you set things up so workers can figure out for themselves what needs to be done, instead of telling them what to do). They continue with an example of a pull system, the simple and ingenious Kanban card system used in Japan, and show how a similar system can be used for software development. The use of pull systems goes hand in hand with the theme in chapter 5 - Empower the Team. The idea here is that the front-line workers are the ones that know best how things should be done, and they should be empowered to act on this knowledge. Most of this material is covered in regular books on business improvement, and there wasn't much new material here for me. So for me, this was the least interesting chapter, together with the parts on contract negotiation in chapter 7 (simply because I am not involved in any contract negotiations). Another theme in the book is to not sub-optimize. There is a good example from the manufacturing world, where a video tape machine was run at full capacity. The utilization of the machine was maximized, but that did not maximize company profit. It is tempting to break up a task in smaller tasks, and then optimize each task individually. But as the authors show, that is very often a bad strategy. A good analogy from the book is when they point out that Lance Armstrong, winner of Tour de France for many years, only won 4 out of 21 daily stages, even though he was the eventual winner. Had he tried to win each daily stage, he probably would not have won the whole race. There are also many good examples in the book. I particularly liked the one about HP printers. By waiting to do the final electrical configuration of the printer until after it was ordered, it was much easier to match the supply of printers in a certain configuration with the demand. It cost a bit more to do the configuration so late, but that was more than off-set by the savings of not having to forecast exactly how many printers in a certain configuration that were needed at different locations. I also found many interesting nuggets of information about software development sprinkled through the book. The diagram on page 18 for example shows how experienced designers work out a solution to an ill-defined design problem by repeatedly moving between high level and low level design activities. I had never seen this described before, but immediately recognized that that is how I work too (as opposed to a straight top-down approach). This too explains why I think you should also keep coding even if you are an architect - because to find the best solution you must alternate between high and low levels of design. Another good part was their diagnosis of the problems with CMM and ISO9000. They write that both programs have a bias towards documenting and thus standardizing existing process, rather than improving the process, even though it is not the intent of either. I agree completely. This is a practical book, and there are lots of good (and well described) ideas that can be used in software development. It is well worth getting, both for developers, managers and project leaders. Recommended.

I bought Mary and Tom's book when it first came out in 2003 and knew immediately that it would have a lasting impact on my vocabulary around agile software development. Their view of applying lean thinking and lean development to software development gave the entire group of agile methodologies (Scrum, XP, Crystal Clear, etc.) something truly solid upon which to hang their collective hats. For my part, it gave me the theoretical background I lacked while also giving clear practical advice about how to apply the theory. Eliminate waste, amplify learning, delay commitment, delivery fast, empower the team, build integrity in, and see the whole. These are the 7 principles of Lean that are then applied directly into software development practices. It is now several years later and I keep coming back to this title, not just for my own reference, but also for my clients. In my work as an Agile Mentor, this book is one of my all time top references. I recommend this book to developers, managers, executives, stakeholders, testers, customers, everyone! "Lean Software Development" gets this mighty nod from me because it provides straightforward language around productivity, revenue, and quality that helps all of these various roles understand the value of agile software development practices. When development teams eliminate waste daily, they eliminate waste from the overall product release. And when multiple teams eliminate waste from product releases, they are eliminating organizational waste. And with organizatinal waste tracked and eliminated, the entire organization enjoys higher quality and productivity. This progression of benefit occurs with all of the seven principles and the Poppendiecks give you the path to apply these bottom up or top down. If you have but one book to choose in order to understand agile software development, start with "Lean Software Development". If your boss has only one book to choose in order to understand why YOU are interested in agile software development, have her start with "Lean Software Development".

It was seven years and many software projects ago when I first read this book. At the time, I was trying to get my arms around the rapidly emerging agile movement. I enjoyed reading and learning about the practices for XP, Scrum, Crystal and other methodologies. However, this book helped me see the bigger picture and introduced me to valuable concepts from lean manufacturing such as value stream mapping, set based development and pull systems. The book also introduced me to a lean, systems-based way of approaching software development. Although I might have been pressed to enumerate all the principles and the tools in the book, I know that over the years I've applied many of them regularly- adapting them to fit the diverse domains and environments in which I worked. Over the years, my copy has became worn and dog-eared. It was marked with a yellow tag on the spine, my way of marking favorite books on my shelf. As such, it was often loaned out to others. I recently re-read the book and was surprised how relevant it remains in 2009. A few of the specifics in the book are dated, such as its characterization of how CMM, CMMI and PMI relate to agile. However, most of the material, is not only relevant; it's often more applicable today than when it was originally written. The book is well organized, easy to read and filled with "pearls of wisdom". I'll continue to include it right next to Goldratt in my list of recommended reading.

It's pretty much all been said by previous reviewers but this one is worth another accolade. As a CIO with over 20 years in software engineering, I've just about read it all, seen it all, tried it all. As a result I'm a big believer in Lean/Agile, and this is the best introduction I've come across. It's a nice, practical mix of principles and practices and touches on all the right themes. A previous reviewer laments the authors' distaste for CMMI and PMI. For instance: "Between PMI and CMM certification programs, a heavy emphasis on process definition and detailed, front-end planning seemed to dominate everyone's perception of best practices...spending a lot of time and getting the requirements right upfront was the way to do things `right the first time'...CMM, in its eagerness to standardize process, leaves out the heart of discovery and innovation..." Spot on. As a PMP with CMMI experience, I couldn't agree more with the Poppendiecks' observations and concerns. They go on to say, "This is not to say that CMM and PMI are bad, but only that for anyone who has lived through the lean revolution, they tend to give the wrong flavor to a software development program." That "wrong flavor" is called "waterfall." Of course there are Level 5 Agile shops out there, and the author's recognize that "CMM is not supposed to dictate approach, but only assess..." But here's the problem: "CMM programs...may standardize on less than ideal practices...they may be better implemented separate from--and after--process improvements." This book is a must read for software development managers and other business execs pursuing the promise of an Agile company (vs. IT shop). I'll definitely be passing out a few copies!

While the topic of agile software development has been popular at least since the late 90s, and many have written about how various methodologies (XP, Scrum, Crystal, etc) work and how much software developers love them as opposed to CMM and other process-heavy ways of doing things that only managers care to push, until this book came out few had been able to explain WHY these agile methodologies work and what principles are behind them. The main revelation comes at the beginning of the book: while the software engineering gurus (think SEI, DoD, etc) have been busy all these years trying to make software development more like mass production, the manufacturing world has actually moved on to lean production, and there is much we software managers have to learn from it. Drawing from her unique experience as software project manager for companies that follow lean manufacturing, Poppendieck distilled all she has learned from lean manufacturing into seven principles and twenty two practical tools for software development that while not a methodology per se at the very least serve as paradigm busters for managers who believe that believe there is a necessary trade-off between speed and quality, and at best it can provide the necessary building blocks for development organizations to develop custom methodologies that would allow them to work orders of mangitude faster. But more than that, by establishing a relation to lean production, principles which after the spectacular success of companies like Toyota are now unquestioned, Poppendieck provides a more solid foundation and gives greater credibility to agile methodologies that have until now remained controversial. This will hardly be the last word on this topic, and in fact Poppendieck is about to release a second book that goes into more detail on how to put lean development in practice, but nevertheless this work is sure to remain relevant for a long time to come.

This book is a great read for anyone interested in agile software development. That includes developers, leads, and managers interested in speeding up development cycles, improving quality, and getting their customers the best value. This book's been out since May, 2003, but it's well worth picking up. The concepts within are absolutely applicable now, and will continue to be for quite a few years. The book's full of pertinent comparisons between the current state of software development and the massive changes in manufacturing over the last three decades, specifically demonstrated by the Toyota Production System, and 3M's innovative atmosphere for bringing products to life. The Poppendiecks make a great case as to how similar changes in software development can reap great benefits in the software production industry. This really is an important addition to your reading list if you're at all interested in learning how an agile environment can increase your speed, quality, and cost effectiveness. It's a great book if you're in need of guidance on how to look at and improve your current environment. It's also a great book if you need backup for convincing either your co-workers or management that a move to agile is necessary.

I read this book and I was really delighted. Principles are written in a common sense approach, made me really think about the philosophy behind lean principles. No contextless recipes, just the way of thinking you have to use to apply the philosophy in your environment. That's what make this book really different to others that I'd read.

This is a very informative book which looks at best practices that revolutionized manufacturing industry and how they can be intelligently applied to software engineering. Sometimes in our zeal to bring engineering discipline to software development, we strive to make software development like a true engineering profession. However, often times, a key distinction that very much exists is missed. The key distinction is product development v/s product manufacturing. We miss out product development part of it and try to discipline software development like manufacturing. This book address that distinction very well and gives some nice ways to adopt successful principles of lean development which were pioneered by Toyota. The authors, who have had extensive experience with manufacturing and software development, combine their in-depth knowledge of both fields to provide many best practices that can be directly applied to software engineering. 'Avoid wastage', 'Kanban' (JIT) etc. are easy to understand from manufacturing standpoint but translating them into software engineering requires a lot ingenuity. The authors bring this out very well. 'Innovation can not be scheduled' is probably the best punch line of the book. If we get just this out of this book, it's worth it. Nice perspective and support for agile development practices.

Amazing and practical book. A must have for any software development organization. Totally recommended

This is THE leading edge book about Lean Software Development. It is a MUST !!!! I recommand every project manager to read this book.

Si tratta di una guida ben scritta alle idee che muovono il pensiero Agile, arricchita da parecchi riferimenti ad altre fonti (la bibliografia è lunga 8 pagine) tra quelli che illustrano i vantaggi di Lean nella produzione (software e non) , e le fonti "originali" che fanno riferimento alle tecniche e metodologie citate nel testo. Quindi chi ha interesse per approfondimenti su vari temi ha parecchio materiale a disposizione. Il libro divide il pensiero Lean in 7 principi chiave e propone ben 22 "strumenti" che possono aiutare ad adattare le pratiche agili a contesti sempre diversi. Alla fine di ogni capitolo è presente un paragrafo che serve a dimostrare come le particolari tecniche discusse possano essere applicate per migliorare il processo di sviluppo. Alcuni di questi principi sono ovvi a prima vista ("Eliminate waste", eliminare gli sprechi, per esempio) ma questa apparente semplicità nasconde una serie di implicazioni e soprattutto di output produttivi sui quali, agendo a dovere, si può far leva per migliorare di molto il processo produttivo. Consiglio sicuramente questo libro a chiunque sia coinvolto nella produzione di software di qualità, a qualsiasi livello.

obra maestra para quienes buscan optimizar el desarrollo de software utilizando los principios del pensamiento Lean. El libro ofrece una visión clara y profunda de cómo aplicar los siete principios Lean —eliminación de desperdicios, mejora continua, calidad integrada, entre otros— al desarrollo de software, lo que lo convierte en una herramienta poderosa para equipos ágiles que desean ser más eficientes. Los autores logran conectar con facilidad las ideas del Lean Manufacturing con el mundo del software, ofreciendo ejemplos concretos y casos de estudio que ilustran cómo estos principios pueden transformar un equipo de desarrollo. La estructura del libro es clara, con explicaciones directas y ejemplos prácticos, lo que facilita aplicar los conceptos a la realidad cotidiana de los equipos de software. Es una lectura obligada para líderes de proyectos, desarrolladores y cualquier persona interesada en mejorar los flujos de trabajo, reducir desperdicios y entregar productos de mayor valor de manera más eficiente. Sin duda, Lean Software Development es una guía indispensable para cualquier organización que busque agilidad y excelencia en el desarrollo de software.

As a young professional with 2 years digital experience but 0 experience in Lean Software Development, this was the perfect introduction and start. Was able to instantly apply what I learnt from the book to my work.