Customer Reviews

Lean Software Development: An Agile Toolkit

5 star:		(30)
4 star:		(12)
3 star:		(0)
2 star:		(3)
1 star:		(0)

 

 

Books written during the first phase of agile software development have been about very specific practices we should employ. There are some excellent books on the Extreme Programming, Feature-Driven Development and Scrum agile processes. These books teach us "do a, b, and c if you want to do Extreme Programming" or "do x, y and z if you want to do Scrum."

In the last year we've seen books by Highsmith (Agile Software Development Ecosystems) and Cockburn (Agile Software Development) that represent the second wave of agile software development-that of learning to think agilely rather than following a prescribed set of agile rules. Mary and Tom Poppendieck's book is the latest and best book for teaching how to think agilely.

The book contains 22 "thinking tools." The thinking tools are drawn from the world of lean manufacturing where they have helped improve product delivery speed, quality and cost. Each tool is presented as a guideline. Each thinking tool is described with enough detail that you can put it into practice; but, more importantly, the reasons supporting each are made explicit. So, instead of simply reading that it is good to "deliver as fast as possible" we learn how rapid delivery is supported by pull systems (where work is pulled into the current step from the prior step), how queuing theory helps us identify bottlenecks, and how to calculate the cost of delay (to see which bottlenecks are worth removing).

This book is the perfect blend of highly actionable instructions and descriptions of why those actions work. I highly recommend this book to anyone who wishes to improve his or her software development process. The authors' ideas are applicable both to projects using agile approaches today and to more traditional, plan-driven projects.

Our reading group at work recently read "Lean Software Development." There are several things I really like about this book:

1. Its thinking is clearer than most. The Poppendiecks make sharp distinctions between principles, tools, and practices. (More on this will follow.)

2. It presents an Agile approach without demanding that one follow all tenets of Extreme Programming (such as pair programming).

3. It recognizes that in the past it has been a mistake to think of software development as being roughly analogous to manufacturing. Creating custom software is not very much like assembling cars within a factory.. Software development is much closer to product development, much more like the work that goes into designing the car in the first place. Principles (not necessarily techniques!) that work well in product design can have a much more straightforward application in software design.

4. They specifically address the needs of safety-critical software, talking about how to apply these principles in environments that are heavily regulated or where a software failure may endanger lives.

The book does suffer at times from and affliction common to this genre: over-enthusiasm. There can be a sense that all we need to do is follow what they say and all will be well. But, for the most part, the authors provide reasonable, realistic guidance for those looking to improve the way they go about creating software.

Now that we have the overview, let's look at the meat of the book: Agile principles. There are seven Agile principles which should govern a group's software development process:

1. Eliminate Waste
2. Amplify Learning
3. Decide as Late as Possible
4. Deliver as Fast as Possible
5. Empower the Team
6. Build Integrity In
7. See the Whole


A chapter is devoted to each principle. In each, the principle is described, examples are given from both product and software development, and a number of "tools" are suggested as ways to apply the principle in software development.

The principles are valid within any development effort, software or otherwise. For example, a good process will always seek reasonable ways to eliminate waste. In product development and manufacturing, waste may include scrap material that does not end up in a product. In software, the definition of "waste" will include things like partially done work, extra processes, extra features, waiting,
etc.

It is very important to keep the distinction between principles, tools, and techniques in mind. Principles must be reasonably applied to a given environment. The authors put it quite well: (pp. 179-180)

* Eliminate waste does not mean throw away all documentation.
* Amplify learning does not mean keep on changing your mind.
* Decide as late as possible does not mean procrastinate.
* Deliver as fast as possible does not mean rush and do sloppy work.
* Empower the team does not mean abandon leadership
* Build integrity in does not mean big, upfront design.
* See the whole does not mean ignore the details.


"One team's prescription is another team's poison. Do not arbitrarily adopt practices that work in other organizations; use the thinking tools in this book to translate lean principles into agile practices that match your environment."


I strongly recommend this book.

I am a senior software systems engineer working for an aerospace company. I recently read the Poppendicks' book and have mixed feelings about it. Overall they present some great lean development principles and tools that appear to be useful in boosting productivity in my software engineering organization. On the other hand, their understanding of CMM/CMMI is so off-base that it is hard for me to take them seriously as authors.

They misrepresented CMM several times in the book, so they either do not understand what CMM is and how it works, or they are intentionally misrepresenting it to "scare" people into using their lean software tools. The reality is that agile software development principles and tools fit perfectly into the CMM/CMMI models and the Poppendicks would have a much stronger book if they realized that. Rather than bashing CMM to make their tools seem more useful, they might do better if they realized that CMM/CMMI and lean software development can work perfectly together.

My advice to people interested in buying the book is to only read the book if you can take what the Poppendicks say with a grain of salt. Read about the lean principles/tools and think of how you could apply them in your software development environment. In the spirit of implementing the primary principle of lean development (i.e. eliminate waste), I would ignore the anecdotes they include in the book. They appear to be intentionally sensational while offering little value.

This is an excellent discussion of how the principles of Lean Manufacturing apply to Software Development. The authors explain why the usual metaphor of software as manufacturing is not quite right, and why the metaphor of Lean Manufacturing is something we can learn from. The book is clearly written and the authors provide examples and anecdotes to help you to understand their points. This was a fairly quick read, and I am likely to refer to it often.

Although this book is from the Agile-series, the approach and advice extends to any methodology from the heavy (and still used) waterfall SDLC, to XP and agile methods.

Key steps in this book will show you how to streamline your development methodology in accordance with lean thinking:
- Eliminate waste by cutting the fat out of processes, reducing rework, viewing your SDLC as a value stream.
- Amplify learning, with an emphasis on iterative planning, feedback loops and team communications.
- Decide as late as possible, which is enabled by concurrent activities, depth-first versus breadth-first problem solving, and other effective tools and techniques.
- Deliver as fast as possible, based on analogies between manufacturing pull systems and scheduling, and how to accomplish the same in development.
- Empower the team, which is a fundamental element of lean thinking. The tools and techniques presented in this section of the book are a mixture of common sense, leadership and management.
- Build integrity in. If ever there were a direct connection between the lean thinking approach to manufacturing and software development, it is here. Tools and techniques given include model-driven development, refactoring and testing techniques.
- See the whole, which emphasizes system thinking, metrics, optimization, and the supporting tools and techniques.

Any or all of the above can be effectively applied to any SDLC or methodology and produce results. Lean thinking was developed by Toyota as a manufacturing paradigm, which has been extended through that company and is applied to business processes outside of the manufacturing domain. That this team of authors has applied it to software development is not as unnatural as it may seem at first glance given how vastly different software is to create versus cars, for example. But, the paradigm has been proven outside of manufacturing before this book was written, and the basic philosophy and principles can be applied - which this book evidences.

If you want to look at development from an entirely unique perspective purge the words agile, XP and any other methodology from your mind while reading this book. I can almost guarantee that you'll find something in every chapter that you can put to immediate use in your own organization. As an aside, a book on software testing that is consistent with lean thinking in many ways, and closely aligned to the content of this book is "Software Testing Fundamentals: Methods and Metrics" ISBN 047143020X.

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".

The authors have done a wonderful job in helping us to look for ways to improve toward "Lean Software Development". One of the great things about this book is the approach that it takes. Rather than giving a prescription of "do this, and you should get these results", they give a framework for thinking through the issues and making good decisions. Each chapter concludes with a section called "Try This". My organization has already benefited from the suggestions for identifying waste. Again, they don't tell you what waste to eliminate, but rather how to go about looking for wasteful items.

Another thing that the authors have cleared up is the improper distinction between principles and practices. The authors claim that many of the problems in software today come from the fact that manufacturing *practices* have been applied to software development rather than manufacturing *principles*.

The principles that are explained throughout the book are based on successful companies outside of the software business, e.g. 3M and Toyota, and how in turn these can be applied to software.

One of the best points that they authors make - and they make many good ones - is that local optimization within an organization can actually slow down the overall process.

The overall tone of the book is very pragmatic, and it is definitely going to be a shock to the system for anyone who is accustomed to CMMI or ISO certifications. However, the potential results from this shift in thinking are worth it.

I found Mary and Tom's book to be a "game changer". I have over 25 years experience, in IT related project management roles, working for both large corporations and small businesses. We, in IT, are always looking for a competitive edge. In today's market place, it's not just about developing creative new products. It's about developing those products faster and cheaper. As Mary's book so aptly describes, you do that by eliminating
waste, you do that by getting Lean. Lean Software Development, An Agile Toolkit, is written in a way that resonates with IT folks. The real-world,"try this" suggestions present a practical method of turning concept into practice. It has proven to be a catalyst for change, challenging some of the long-standing assumptions on how IT projects should be run
Jonathan Cooksey
Six-Sigma Master Black Belt
IT & Strategic Initiatives (Fortune 100 Company)

This is a book about the Principles behind the so-called Agile Methodologies. Those familiar with XP, Scrum and the like will understand where the Practices those methodologies propose came from. These Principles also explain where the iterative model of RUP came from, even when RUP may not be considered agile.

If you have any experience in software development, reading this book will repeatedly make you think "yes, that's exactly how things really are" and "yes! that idea WILL work for me!".

Unlike the methodologies, this book proposes no Practices at all. Finding them is left to you, after understanding the Principles and tailoring them to the practices that best fit your domain and context.

I'm pretty sure your way of working will never be the same after you read this book.

I gave this book five stars becase that is the maximum I am allowed to give it, otherwise I would have rated it higher.

I think this book should be REQUIRED READING for anyone interested in agile software development methods, or even just general software process improvement. This book contains the kind of practical thinking and analytical tools about agility that I was starved for when the first book on agile development methods first hit the software development scene.

The early books on XP said what XP was and described its values and practices. But when wanting answers to the questions about why a particular practice works, where its strengths are, where its gaps are, and how they are/arent addressed by other practices, I was left wanting (particularly since a lot of folks wanting to adopt agile "in bits and pieces" perceived the need to do so incrementally and needed to understand where to begin, which core things to start with, how to adjust and adapt them to ones environment, and what to look for).

This book filled that void for me, showing me how to think about agile "systems" from a systems-thinking perspective, and how to analyze existing processes (agile or otherwise) to identify their "hot spots" and apply 22 practical tools to get on the road to lean/agility, (in an evolutionary fashion) without mandating instantaneous revolutionary organizational change to replace the entire process all at once.