Customer Reviews

Implementing Lean Software Development: From Concept to Cash

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

 

 

While the book contains many interesting ideas, it is very tedious reading; an in-depth article could have adequately covered the same material. The book is often fairly repetitious with the same story used to make the same point in multiple places. While the title might lead one to expect a fairly "applied" book ("Implementing" and "concept to cash", the actual purpose is to sell you on the concept of lean software development.

The authors like to bring in real-world examples to help bolster their arguments but frequently get the facts or their interpretation wrong. While the authors need not be experts in areas outside their expertise, one would expect that they would fact-check the basis of some fairly definitive statements; here are some examples: "... 16 is the standard number of missiles in a submarine to this day" (wrong since 1979 when first 24 missile Trident sub was launched); "... in 1985 the value of the yen started its steep fall" (actually the value of the yen rose). Nitpicking?---perhaps, but I find them wrong on areas that I know a little bit about, it makes me wonder how well they are doing when citing knowledge that is unfamiliar to me.

The authors belittle an "efficient expert" (the subject of "Cheaper by the Dozen") for believing there is only one way to efficiently do things. They later turn around and advocate that all developers be subjected to inspections---not inspections of their software but inspections of their desks to insure that they are tidy. They opine that a developer with a messy desk will probably be responsible for messy software; do they feel that a little maid-service will massively reduce software defects? (Why is it that morning people and neat-freaks always so self-righteous?). Sounds pretty "one-way" to me.

The bottom line is that you could probably find a good article in print somewhere that would provide you with most of the content here saving both time and money (sounds like the "lean" way to do things). Still you will get some value for your time and money if you do invest in this book.

This book is a great follow-on to the Poppendieck's "Lean Software Development" book. That book gave readers "an Agile Toolkit" for understanding what lean and agile are all about. This book is similar to its predecessor both in tone and content with practical examples of what works and what doesn't. Much of the book is still framed by lessons learned from Toyota's manufacturing system and Mary Poppendieck's experience at 3M.

That said, the book isn't just a rehash of the earlier, seminal work. This book seems to have a solid core of how to get the most out of development teams with two sections specific to people and partners. There are also terrific sections on knowledge-sharing, speed, and how to get the highest quality while delivering in a rapid and lean fashion. Some things aren't covered at all, such as the fundamentals of value stream or Pareto charts, but those areas are by far the minority.

One other reviewer remarked about the lack of anything specific to Extreme Programming, but I think that's missing the point a bit: this book isn't about a specific implementation of agile/lean/whatever, it's about the general approach to the principles of lean development. The book guides readers to explore what's not working in their own environment and alter bits and pieces to improve production. An example of this is the closing section to each chapter where a "Try This" section guides readers to examine how their own environment is working or not working.

Folks who have done plenty of reading on agile/lean concepts may not find anything earth-shattering in this book, but it's a terrific read for anyone regardess of their exposure to and involvement in agile. Well-steeped readers will find lots of head-nodding stories and a few provoking exercises and topics. Newcomers will have their eyes opened by a wealth of riches.

I don't think I've ever tried to fit software development into the model of lean manufacturing techniques. But surprisingly, it has a number of parallels, and they are outlined well in the book Implementing Lean Software Development - From Concept to Cash by Mary and Tom Poppendieck.

Contents: History; Principles; Values; Waste; Speed; People; Knowledge; Quality; Partners; Journey; Bibliography; Index

The authors take the Deming-type principles of manufacturing and show how they relate to agile software development, using many of the same concepts and terms that have been handed down to us from the Japanese methodologies that revolutionized manufacturing. For instance, Shingo's seven wastes of manufacturing get translated into the seven wastes of software development: In-Process Inventory (Partially Done Work), Over-Production (Extra Features), Extra Processing (Relearning), Transportation (Handoffs), Motion (Task Switching), Waiting (Delays), and Defects (Defects). To take one of them specifically... Over-production is the making of product that isn't immediately needed. It builds up, costs money to store and maintain, and may never be used if the requirements change before the product is used. Likewise, extra features in software, ones not needed to get the customer's job done, should be avoided at all costs. It's code that needs to be maintained, it can break software that *is* essential, and the requirements for the feature may change dramatically by the time it is actually requested. Granted, these are guidelines and not hard-and-fast rules, but they make a lot of sense in terms of making the software development process more efficient and productive.

Both authors have a manufacturing background in their software development past, so the content is liberally sprinkled with real-life examples of these guidelines as they have played out in companies. It's amazing how we accept things in software development that we would never stand for in a well-run manufacturing set-up (such as running your "machines" over 100% capacity for long periods of time... sound familiar?)

If you're having a hard time getting your organization to give "agile" methodologies a try, you might want to reframe the discussion around "lean" software development. You could break out of the language misconceptions and discover new insights. This book can help you make that leap...

I've long considered Mary and Tom Poppendieck to be among the primary theoreticians in the agile software development movement. Their first book, Lean Software Development, provided insights into the theory behind agile software development. That first book has been widely praised for helping those of us doing agile software development know why what we were doing worked.

With their new book, Implementing Lean Software Development: From Concept to Cash, the Poppendiecks move their ideas a giant leap forward. In this book they move very much from theory straight into what teams should do tomorrow to create better products. The book is full of practical, agile- or lean-minded, do-this-tomorrow advice on topics such as how to solve problems, how to structure compensation and recognition programs, how to get started on a lean initiative, how to write contracts for agile projects, and many more. The practicality of the book is reinforced by the "Try This" exercises that conclude each chapter.

The book starts out with a wonderful description of their seven principles of lean software development. For each principle they single out and dispel a common myth associated with the principle. Their description of the principle "build quality in," for example, includes a highly effective argument against the myth that the job of testing is to find defects.

The book then moves on to chapters on value, waste, people, knowledge, quality, and partners before concluding with a chapter on the journey ahead for companies embracing the theory and the practical advice given in this wonderful book.

Some of this is so counter-intuitive. But once I began reading, I could see waste in software development where before I had seen good process. Just the concept of unfinished software as Inventory has caused me to rethink my previous willingness (even eagerness) to accommodate context switches between different projects. If the project being switched from has not issued a new iteration of the software, then there is wasted functionality that might have been providing value to users if it had been finished, just sitting on a "shelf" gathering dust. And the further cost of getting back up to speed on that project to transform partly finished work into deliverable software.

I would like to recommend also these other two lean books Lean Thinking : Banish Waste and Create Wealth in Your Corporation, Revised and Updated and The Machine That Changed the World: The Story of Lean Production-- Toyota's Secret Weapon in the Global Car Wars That Is Now Revolutionizing World Industry which go into the research and rational behind the concepts in this book. It will sort out your doubts.

I found myself reading this book during coffee breaks. It's a great read.

The seven principles of Lean Software Development are; Eliminate Waste, Build Quality In, Create Knowledge, Defer Commitment, Deliver Fast, Respect People and Optimize the Whole. Each of these principles is discussed in detail. The theoretical foundations are supplemented by real-world examples, case studies and experience reports. Each section ends with a list of concrete exercises called "Try This", which invites you to put your knowledge into practice. This book is an excellent way for agile leaders focus on the most significant factors for success.

This book explains how to apply the lean manufacturing principles developed by Toyota to Software Development. It focuses on increasing the development speed, since a faster speed results in higher efficiency, lower costs, better value for the customer and also drives higher quality. I strongly recommend it as an introduction to the Agile software development methodologies.

This is excellect book for seasoned software developer. I had trouble with some books on XP pushing process as rigid thing ... here in this book there are reasons behind XP process, knowing them allows one to modify process to fit environment... This is just what I needed - this book was excellent investment of my time and money

I'm very impressed with this book. Unlike most Agile books (that focus on the decorations of the process), this gem dives right into the principles of the process. I especially like how the authors go back to proven manufacturing models to show that software development is engineering and not science. I've read a ton of Agile books, but find every myself continually delighted as I turn each page. This is the first Agile book that I think someone completely new to Agile could use to bootstrap the process into their own organization (but still would recommend a consultant).

Highly recommended for both experts and novices.

Whether you build software for internal use only, or, as I do, you build and maintain commercial software for businesses and government .,. you have to read this book.

First, this book is for management ... especially those who manage the managers who manage project leads, product managers and line of business management ... this is a MUST READ for anyone who pays for software, invests in software, thinks about software or maintains software.

While I am well-steeeped in the agile methods of Scrum, this is an excellent text that builds on a long body of knowledge and experience.

I used the concepts in this and a few other learned books and experts to reduce the costs of supporting some $70 million worth of software business from $12M to $6M!!! Quality improved, employee satisfaction soared. Customers were appreciative.

I use a yellow highlighter when I read books I learn from. This books was YELLOW when I finished .. and I have purchased over a dozen copies for colleagues who manage software.

A must have for your library!!!