What do you think?
Rate this book
A Kent Beck Signature Book
Implementing Lean Software Development: From Concept to Cash
"This remarkable book combines practical advice, ready-to-use techniques, and a deep understanding of why this is the right way to develop software. I have seen software teams transformed by the ideas in this book." --Mike Cohn, author of Agile Estimating and Planning "As a lean practitioner myself, I have loved and used their first book for years. When this second book came out, I was delighted that it was even better. If you are interested in how lean principles can be useful for software development organizations, this is the book you are looking for. The Poppendiecks offer a beautiful blend of history, theory, and practice." --Alan Shalloway, coauthor of Design Patterns Explained "I've enjoyed reading the book very much. I feel it might even be better than the first lean book by Tom and Mary, while that one was already exceptionally good! Mary especially has a lot of knowledge related to lean techniques in product development and manufacturing. It's rare that these techniques are actually translated into software. This is something no other book does well(except their first book)." --Bas Vodde "The new book by Mary and Tom Poppendieck provides a well-written and comprehensive introduction to lean principles and selected practices for software managers and engineers. It illustrates the application of the values and practices with well-suited success stories. I enjoyed reading it." --Roman Pichler " In Implementing Lean Software Development, the Poppendiecks explore more deeply the themes they introduced in Lean Software Development. They begin with a compelling history of lean thinking, then move to key areas such as value, waste, and people. Each chapter includes exercises to help you apply key points. If you want a better understanding of how lean ideas can work with software, this book is for you." --Bill Wake, independent consultant In 2003, Mary and Tom Poppendieck's Lean Software Development introduced breakthrough development techniques that leverage Lean principles to deliver unprecedented agility and value. Now their widely anticipated sequel and companion guide shows exactly how to implement Lean software development, hands-on. This new book draws on the Poppendiecks' unparalleled experience helping development organizations optimize the entire software value stream. You'll discover the right questions to ask, the key issues to focus on, and techniques proven to work. The authors present case studies from leading-edge software organizations and offer practical exercises for jumpstarting your own Lean initiatives. Implementing Lean Software Development is indispensable to anyone who wants more effective development processes--managers, project leaders, senior developers, and architects in enterprise IT and software companies alike.
304 pages, Paperback
First published September 1, 2006
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 43 reviews
December 20, 2016
This book does a great job of covering most of the critical concepts of lean/agile development. The organization of the book is a bit random and the writing can occasionally be dry (especially the intro chapter), but the book is packed so full of useful insights that it's worth reading anyway.
Some of my favorite non-obvious ideas from this book:
* Smaller batches have less variation. The variation in a 60 minute task is typically going to be measured in minutes; the variation in a 60 day task is typically going to be measured in weeks. By doing work in small batches, you can reduce variation, which makes it easier to predict and optimize your schedule.
* A CPU becomes less efficient above a certain utilization percentage; for example, above ~80% utilization, the CPU may start thrashing and spending much of it's time on overhead (e.g. context switching). It turns out the same is true of people. As you fill someone's schedule more and more, initially their efficiency goes up, but above a threshold of roughly 80% utilization, the efficiency actually goes back down (i.e. cycle time goes up, sharply). Leaving some slack in the system is essential for efficiency. This may have been one of the biggest benefits of programs like Google's 20% time: these programs not only allow for trying out new ideas, but also ensure there is enough slack in the system to avoid thrashing.
* Optimizing local metrics does not necessarily optimize global metrics; in fact, once a system passes some base level of efficiency, optimizing a local metric often comes at the cost of a global metric. Therefore, always focus on big-picture, global metrics, such as cycle time and customer satisfaction.
* If you want to work quickly and efficiently, especially in a large team, you'll find that a centralized point of management and dispatch is simply too slow and inefficient. The only way to get things done fast is to make sure everyone can self-direct their work.
* Make decisions as late as possible (but no later!), as that's the point when you'll have the most knowledge about the situation. This means you should not do a huge, up-front planning process and come up with massive, immutable specs, as in the early stages, you lack the information you need to make good decisions. Instead, set high level goals, make everyone aware of them, and let teams incrementally ("just in time") discover the best way to move you towards those goals.
* Automation is generally good, but there is a danger to completely removing people from the equation: an automated process typically cannot change, adapt, or improve.
As always, I've jotted down some of my favorite quotes from the book:
"Almost everything we know about good software architecture has to do with making software easy to change. And that’s not a surprise because well over half of all software is developed after first release to production."
"Far and away the biggest source of waste in software development is extra features. Only about 20 percent of the features and functions in typical custom software are used regularly. Something like two-thirds of the features and functions in typical custom software are rarely used."
"Any company that expects to maintain a competitive advantage in a specific area must develop and nurture technical expertise in that area. Companies that buy all the expertise they need will find that their competitors can buy it also."
"The cost of complexity is not linear, it is exponential, and the cost of complexity eventually comes to dominate all other costs in most software systems. Complex code is brittle and breaks easily, making it almost impossible to change safely. Wise software development organizations place top priority on keeping the code base simple, clean, and small."
"Requirements churn is a symptom of writing requirements too early. Requirements should be done in smaller chunks, much closer to the time they will be converted to code, preferably in the form of executable tests."
"Centuries ago, the critical constraining resource was land. Those who controlled the land controlled everything. At some point, the constraint became skills, and guilds and merchants created more wealth than did landowners. Later, the industrial revolution moved the constraint to capital, and power became financially driven. Today, the constraint is knowledge: technical knowledge, management knowledge, process knowledge, and market knowledge. Much of this knowledge is being expressed as software."
"There are two kinds of software—change tolerant software and legacy software. Some software systems are relatively easy to adapt to business and technology changes, and some software systems are difficult to change. These difficult-to-change systems have been labeled “legacy” systems in the software development world. Change tolerant software is characterized by limited dependencies and a comprehensive test harness that flags unintended consequences of change. So we can define legacy systems as systems that are not protected with a suite of tests. A corollary to this is that you are building legacy code every time you build software without associated tests."
"Repetitive tasks are not only error prone; they send the message that it’s OK to treat people like robots."
"Eliminate barriers that rob people of their right to pride in workmanship. Artificial deadlines, managers with no idea about what good code really is, sloppy code bases and coding practices, no way to see if new code works, no idea what the users really want, individual rewards for team contributions—all of these rob every member of the development team of pride in workmanship."
"We propose that instead of proliferating measurements, it is best to reduce the number of measurements and find system-level measurements that drive the right behavior at the subsystem level. In lean organizations, it is well known what these measurements are: cycle time, financial results, and customer satisfaction."
Some of my favorite non-obvious ideas from this book:
* Smaller batches have less variation. The variation in a 60 minute task is typically going to be measured in minutes; the variation in a 60 day task is typically going to be measured in weeks. By doing work in small batches, you can reduce variation, which makes it easier to predict and optimize your schedule.
* A CPU becomes less efficient above a certain utilization percentage; for example, above ~80% utilization, the CPU may start thrashing and spending much of it's time on overhead (e.g. context switching). It turns out the same is true of people. As you fill someone's schedule more and more, initially their efficiency goes up, but above a threshold of roughly 80% utilization, the efficiency actually goes back down (i.e. cycle time goes up, sharply). Leaving some slack in the system is essential for efficiency. This may have been one of the biggest benefits of programs like Google's 20% time: these programs not only allow for trying out new ideas, but also ensure there is enough slack in the system to avoid thrashing.
* Optimizing local metrics does not necessarily optimize global metrics; in fact, once a system passes some base level of efficiency, optimizing a local metric often comes at the cost of a global metric. Therefore, always focus on big-picture, global metrics, such as cycle time and customer satisfaction.
* If you want to work quickly and efficiently, especially in a large team, you'll find that a centralized point of management and dispatch is simply too slow and inefficient. The only way to get things done fast is to make sure everyone can self-direct their work.
* Make decisions as late as possible (but no later!), as that's the point when you'll have the most knowledge about the situation. This means you should not do a huge, up-front planning process and come up with massive, immutable specs, as in the early stages, you lack the information you need to make good decisions. Instead, set high level goals, make everyone aware of them, and let teams incrementally ("just in time") discover the best way to move you towards those goals.
* Automation is generally good, but there is a danger to completely removing people from the equation: an automated process typically cannot change, adapt, or improve.
As always, I've jotted down some of my favorite quotes from the book:
"Almost everything we know about good software architecture has to do with making software easy to change. And that’s not a surprise because well over half of all software is developed after first release to production."
"Far and away the biggest source of waste in software development is extra features. Only about 20 percent of the features and functions in typical custom software are used regularly. Something like two-thirds of the features and functions in typical custom software are rarely used."
"Any company that expects to maintain a competitive advantage in a specific area must develop and nurture technical expertise in that area. Companies that buy all the expertise they need will find that their competitors can buy it also."
"The cost of complexity is not linear, it is exponential, and the cost of complexity eventually comes to dominate all other costs in most software systems. Complex code is brittle and breaks easily, making it almost impossible to change safely. Wise software development organizations place top priority on keeping the code base simple, clean, and small."
"Requirements churn is a symptom of writing requirements too early. Requirements should be done in smaller chunks, much closer to the time they will be converted to code, preferably in the form of executable tests."
"Centuries ago, the critical constraining resource was land. Those who controlled the land controlled everything. At some point, the constraint became skills, and guilds and merchants created more wealth than did landowners. Later, the industrial revolution moved the constraint to capital, and power became financially driven. Today, the constraint is knowledge: technical knowledge, management knowledge, process knowledge, and market knowledge. Much of this knowledge is being expressed as software."
"There are two kinds of software—change tolerant software and legacy software. Some software systems are relatively easy to adapt to business and technology changes, and some software systems are difficult to change. These difficult-to-change systems have been labeled “legacy” systems in the software development world. Change tolerant software is characterized by limited dependencies and a comprehensive test harness that flags unintended consequences of change. So we can define legacy systems as systems that are not protected with a suite of tests. A corollary to this is that you are building legacy code every time you build software without associated tests."
"Repetitive tasks are not only error prone; they send the message that it’s OK to treat people like robots."
"Eliminate barriers that rob people of their right to pride in workmanship. Artificial deadlines, managers with no idea about what good code really is, sloppy code bases and coding practices, no way to see if new code works, no idea what the users really want, individual rewards for team contributions—all of these rob every member of the development team of pride in workmanship."
"We propose that instead of proliferating measurements, it is best to reduce the number of measurements and find system-level measurements that drive the right behavior at the subsystem level. In lean organizations, it is well known what these measurements are: cycle time, financial results, and customer satisfaction."
June 15, 2015
Em geral é um livro muito bom. Alguns capítulos são bastante esclarecedores, como o que fala sobre desperdício (melhor de todos) e sobre velocidade. Contudo, alguns capítulos abordaram assuntos de maneira muito superficial, dificultando a aplicação de alguns conceitos. Talvez esteja mais detalhado no livro anterior dos mesmos autores. Vou partir para a leitura dele agora.
April 5, 2021
This book originally appeared in 2006. As of of 2021, the content described in the book is very much futuristic for many to most software organisations. Well worth your time to grasp the fundamentals of lean and how it relates to software development. There’s so much to learn from this book. Highly recommended!
March 3, 2019
Want to understand Lean Software Development better or systematize already existing knowledge? That's the book you need.
March 28, 2013
I've read Poppendieck book's before and followed their teachings for some time already. This book had slipped my radar for some reason and I'm actually glad it had. It was really nice to go through thoughts from basics of Lean and Agile software development, without still wasting many pages on those. This book excellently reminds on the basics, but still give valuable information for the more experienced ones.
Book is full of excellent examples starting from the 70's and 80's, but coming back to the latest years. It explains all the things shortly, but understandably. It is excellent source for information and ideas for further information seeking.
What I've always liked about their thinking, is that they don't ever seem to get in to the hype's. They understand that hype's are hype's and Lean and Agile are something more sustainable. Getting better in software development is never about some specific ways of working. It is always about improvement and doing things better than previously.
I don't recommend it to be the first book about Lean or Agile software development. It gives something for everyone, but it is more valuable when one has got more experience to map the information against.
It was an excellent book and I enjoyed it enormously.
This review was originally published in my blog - here
Book is full of excellent examples starting from the 70's and 80's, but coming back to the latest years. It explains all the things shortly, but understandably. It is excellent source for information and ideas for further information seeking.
What I've always liked about their thinking, is that they don't ever seem to get in to the hype's. They understand that hype's are hype's and Lean and Agile are something more sustainable. Getting better in software development is never about some specific ways of working. It is always about improvement and doing things better than previously.
I don't recommend it to be the first book about Lean or Agile software development. It gives something for everyone, but it is more valuable when one has got more experience to map the information against.
It was an excellent book and I enjoyed it enormously.
This review was originally published in my blog - here
July 22, 2008
This is a book I wish everyone in my company would read--project managers, business analysts, QA engineers, developers, janitors, etc. It's an excellent primer to lean and agile thinking, and I think the "Try This" sections at the end of each chapter would be great exercises for getting our company to think about process improvement.
The book did get repetitive, though, and it seemed a little excessive in its praise of Toyota. And for a book with such an emphasis on quality assurance, I was mildly annoyed at some editing oversights.
Overall, a great book for people in the software industry.
The book did get repetitive, though, and it seemed a little excessive in its praise of Toyota. And for a book with such an emphasis on quality assurance, I was mildly annoyed at some editing oversights.
Overall, a great book for people in the software industry.
May 19, 2019
A very good reminder of what lean is about.
This book will be very good for people who don't know where to start and how to find opportunities for improvements.
Also will be a good knowledge refresher for people who already know a lot about Software development processes, but forgot how and why all practises need to be combined together.
This book will be very good for people who don't know where to start and how to find opportunities for improvements.
Also will be a good knowledge refresher for people who already know a lot about Software development processes, but forgot how and why all practises need to be combined together.
February 16, 2022
After reading the first installment in the Lean Software Development series, Lean Software Development: An Agile Toolkit, I had high expectations for this book. Unfortunately, most of the actionable advice on how to go about implementing Lean Software Development (or any resemblance for that matter) is outlined in the last 4 pages of the book where the Poppendiecks introduce their 21-step program.
In truth, those steps are more elaborated throughout the book but I couldn't help but feel that there is so much chaff in this book, in order to fill it up to have more pages, that the message gets lost.
Also, I believe this book was published in 2007 when the concept of DevOps was not existent. Unless you happen to be working for an organization that deals with legacy code, some of the advice given in this book regarding "delivering fast" (quotes are mine) can be taken for granted in the day and age of automated deployment pipelines.
However, it is not all doom and gloom. For the careful reader wanting to study this subject, his/her best ally will be a marker pen. There's plenty of good ideas in the book, it is just a matter of highlighting whatever can be salvaged from all the repetitive references to Toyota's TPS and management practices.
Sadly, I failed to see how this book could improve on the first one in the series.
In truth, those steps are more elaborated throughout the book but I couldn't help but feel that there is so much chaff in this book, in order to fill it up to have more pages, that the message gets lost.
Also, I believe this book was published in 2007 when the concept of DevOps was not existent. Unless you happen to be working for an organization that deals with legacy code, some of the advice given in this book regarding "delivering fast" (quotes are mine) can be taken for granted in the day and age of automated deployment pipelines.
However, it is not all doom and gloom. For the careful reader wanting to study this subject, his/her best ally will be a marker pen. There's plenty of good ideas in the book, it is just a matter of highlighting whatever can be salvaged from all the repetitive references to Toyota's TPS and management practices.
Sadly, I failed to see how this book could improve on the first one in the series.
March 22, 2019
I enjoyed reading this book so much, that I after finishing it, I had to read it again. I was already somewhat familiar with the topics of value, speed and quality, but chapters on waste, knowledge, people, partners and journey gave me a whole new set of ideas. This book really motivates me to dig deeply into the lean thinking.
Implementing Lean Software Development is truly remarkable, comprehensive, very-well written and easy to read. Mary and Tom show a deep understanding why the lean principles and practices presented in the book are the right way to develop software.
I compiled a list of books from the bibliography: https://www.goodreads.com/list/show/134198.Bibliography_from_Implementing_Lean_Software_Development. It could be useful, if you want to dig deeper.
Implementing Lean Software Development is truly remarkable, comprehensive, very-well written and easy to read. Mary and Tom show a deep understanding why the lean principles and practices presented in the book are the right way to develop software.
I compiled a list of books from the bibliography: https://www.goodreads.com/list/show/134198.Bibliography_from_Implementing_Lean_Software_Development. It could be useful, if you want to dig deeper.
November 11, 2020
This book is an interesting mix, lean, development and the good old world of enterprises. Some concepts I knew, but most of it was pretty readable and worthwhile. I especially enjoyed to read a bit more about "Six Sigma" and the comparison to the "Theory of Constraints", because so far I never touched "Six Sigma" as a topic before.
I really enjoyed all these examples from the experience of both of the authors and wonder what kind vita they must have and the excerpts from their courses.
Mapping lean to software development works rather well, I never thought about e.g. code reviews as a waste in regards to the lean idea though.
I really enjoyed all these examples from the experience of both of the authors and wonder what kind vita they must have and the excerpts from their courses.
Mapping lean to software development works rather well, I never thought about e.g. code reviews as a waste in regards to the lean idea though.
September 7, 2019
Wonderful book: a must-read for every manger.
Some of my favorite quotes:
Discipline (p. 190): "You mean we have to do all that stuff? We though lean meant going fast, but that quality stuff looks like a lot of work!" Indeed.
Code Reviews (p. 194): We think that using code reviews to enforce standards or even to find defects is a waste. Code analyzers and IDE checks are the proper tools to enforce most standards, while automated testing practices are the proper way to avoid most defects.
Some of my favorite quotes:
Discipline (p. 190): "You mean we have to do all that stuff? We though lean meant going fast, but that quality stuff looks like a lot of work!" Indeed.
Code Reviews (p. 194): We think that using code reviews to enforce standards or even to find defects is a waste. Code analyzers and IDE checks are the proper tools to enforce most standards, while automated testing practices are the proper way to avoid most defects.
May 3, 2023
La mauvaise nouvelle pour moi : c’est le bouquin que je voulais écrire…
La bonne : c’est que j’ai appris pas mal de trucs et que je vois suffisamment de choses a ajouter / améliorer pour que ne tue pas mon projet d’en écrire un :)
Le bouquin date de 2007 et applique directement la stratégie lean au software. Les premiers chapitres notamment sont top sur le waste, les value stream mapping. Sur la fin un peu moins puissant mais la lecture vaut le coup et donne de bons modèles sur ce qu’on essaye de faire en software.
La bonne : c’est que j’ai appris pas mal de trucs et que je vois suffisamment de choses a ajouter / améliorer pour que ne tue pas mon projet d’en écrire un :)
Le bouquin date de 2007 et applique directement la stratégie lean au software. Les premiers chapitres notamment sont top sur le waste, les value stream mapping. Sur la fin un peu moins puissant mais la lecture vaut le coup et donne de bons modèles sur ce qu’on essaye de faire en software.
July 9, 2018
It is now a classic, but it's still very valuable and the suggestions still hold valid. It adds much more than the first book "Lean Software Development" (2003), and from the pages you get to understand concepts and techniques of Lean applied to software, like 5S or A3. Testing, configuration management, integration or contracts are also covered with a, surprisingly, still valid narrative.
April 20, 2020
Gives a good overview of Toyota Production System principles & how they can be applied to software development. Then it sets an ambitious goal to cover nearly all aspects of lean software organization (people, quality, knowledge, etc) and here it often feels shallow and lacking flow.
April 23, 2019
Excellent summary of good practices and a healthy view on organizing effective enterprises.
October 17, 2019
Practical, concise, thoughtful. Great book
January 5, 2021
It's a milestone to understand how lean philosophies applies to software management.
Read carefully and apply it when possibile.
It's a book for continuous reference.
Read carefully and apply it when possibile.
It's a book for continuous reference.
April 25, 2021
Very interesting. I have taken some courses into Lean approaches recently, and this, while a bit older, gave me a lot of detail that I hadn't seen yet, as well as being a pleasant read.
October 23, 2007
I'm a big fan of agile. Big 'A' agile makes me a little suspicious, but lean and small 'a' agile? Big fan.
I'm part of a small team that supports a legacy application at work. It's also what makes the money to pay the bills for our company, so there is a lot of pressure to keep it up and running and still meet client requests.
The system is sprawling. Most of the work was done in VB6, but we have tons of SQL, Stored Procedures, a good chunk of HTML with JavaScript, and a healthy dose of ASP.Net done in VB.Net and C# (.Net 1.1) all spread across 2 major web systems and over a dozen smaller programs. I'm the sole programmer fully tasked to keeping the whole disparate system up and running and meeting new requests. The database is huge, we have a 180 gig workspace on the database server. Our team is awesome, the other programmer that is a shared resource with another group (he's their manager and programmer) wrote a good deal of the system and is absolutely invaluable, our two DBAs, a senior and junior, are top notch, our BA is sharp and on the ball and the network team is very responsive and knowledgeable.
Anything that helps me do my job makes me happy. Anything that helps all of us do our jobs makes me happy.
This book has lots of techniques aimed at lean development. We are already using a few of these ideas, and they are working really well. It makes me happy.
We will be examining this book as a team and seeing what else we can use and implement. Lean development practices work well in supporting legacy applications, in my opinion.
The authors did their homework and get the theory, pulling examples from Toyota as their main support, they also cite a number of successful projects ranging from small and in house business software projects all the way to large commercial systems and Open Source.
They have tons of suggestions and real life examples and a "Try This" at the end of each chapter to reinforce the lessons.
If you are faced with a similar situation as mine, I recommend this book.
I'm part of a small team that supports a legacy application at work. It's also what makes the money to pay the bills for our company, so there is a lot of pressure to keep it up and running and still meet client requests.
The system is sprawling. Most of the work was done in VB6, but we have tons of SQL, Stored Procedures, a good chunk of HTML with JavaScript, and a healthy dose of ASP.Net done in VB.Net and C# (.Net 1.1) all spread across 2 major web systems and over a dozen smaller programs. I'm the sole programmer fully tasked to keeping the whole disparate system up and running and meeting new requests. The database is huge, we have a 180 gig workspace on the database server. Our team is awesome, the other programmer that is a shared resource with another group (he's their manager and programmer) wrote a good deal of the system and is absolutely invaluable, our two DBAs, a senior and junior, are top notch, our BA is sharp and on the ball and the network team is very responsive and knowledgeable.
Anything that helps me do my job makes me happy. Anything that helps all of us do our jobs makes me happy.
This book has lots of techniques aimed at lean development. We are already using a few of these ideas, and they are working really well. It makes me happy.
We will be examining this book as a team and seeing what else we can use and implement. Lean development practices work well in supporting legacy applications, in my opinion.
The authors did their homework and get the theory, pulling examples from Toyota as their main support, they also cite a number of successful projects ranging from small and in house business software projects all the way to large commercial systems and Open Source.
They have tons of suggestions and real life examples and a "Try This" at the end of each chapter to reinforce the lessons.
If you are faced with a similar situation as mine, I recommend this book.
April 6, 2014
This is the missing link to anyone doing Agile software development. I have been using Agile successfully for years but, as with any process, there is always room to improve. Beyond the basic framework that an Agile process provides, many of the challenges that arise are specific to the the organization or the customer. While Agile processes provide the mechanism to address these issues (e.g. retrospectives), they don't offer as much as they could when it comes to specific techniques. Thus, finding a method or direction for improvement can be difficult and often seems to take longer than it should.
Lean, as illuminated by this book, is a great starting point to tackle organization-specific challenges quickly and effectively. The techniques described here have already been exceptionally effective in just a few weeks for my team. Not only does this book provide useful techniques, but it eloquently states the arguments that need to be made to convince stakeholders to try things that seem counter-intuitive at first.
Lean, as illuminated by this book, is a great starting point to tackle organization-specific challenges quickly and effectively. The techniques described here have already been exceptionally effective in just a few weeks for my team. Not only does this book provide useful techniques, but it eloquently states the arguments that need to be made to convince stakeholders to try things that seem counter-intuitive at first.
May 26, 2015
Another great book written by Mary Poppendieck. If you are interested in Lean Software and how you can build better products based on proven concepts, then this book is a treasure trove. You will find the fundamental ideas behind lean, the mind-set it requires (trust and self-improvement, not micro-management) and how the idea of lean production developed over the last century until it was transformed to fit needs of software development. It’s well written and you will reach the appendix far too soon.
However, if you don’t know anything about lean then you should look for a different book. In that case you are better served with a step-by-step guide or The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses.
However, if you don’t know anything about lean then you should look for a different book. In that case you are better served with a step-by-step guide or The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses.
December 14, 2015
Another good book for Marry & Tom Poppendieck. The first one, "Lean Software Development: An Agile Toolkit for Software Development Managers" was very exiting to read, good & simple introduction to Lean for newcomers. In addition to variety of tools to apply & examples to make the idea clear enough.
In this second book, the beginning wasn't that attractive for me as the previous book, but by mid of the book it started to get more interesting. The book is packed with very good examples for success stories when things go right & sad stories when things go wrong. At the end of the book, it provides a road map for who would like to find his way to implement a Lean initiative in his organisation.
In this second book, the beginning wasn't that attractive for me as the previous book, but by mid of the book it started to get more interesting. The book is packed with very good examples for success stories when things go right & sad stories when things go wrong. At the end of the book, it provides a road map for who would like to find his way to implement a Lean initiative in his organisation.
November 3, 2014
This book is great! Published 7 years ago just when the "Agile" development movement was hitting its critical mass, this book talks about the roots of Lean and ties almost everything back to the TPS (Toyota Production System) roots. Organized differently than most Lean/Agile/Scrum books I have read, Concept to Cash still includes all the major ideas - e.g. pull scheduling, testing (testing testing), deferred specification/commitment, and frequent communication for all stakeholders - and offers some interesting insight into all of them. I would rate this a must-read for anyone developing software, even if you aren't 100% committed to moving to a "lean/Agile" approach today.
July 28, 2007
Mary Poppendieck has great understanding of lean development. She studied the Toyota method of manufacturing and found a way to apply it to software. The "YAGNI" idea is key - You Ain't Going to Need It principle. Only develop what is necessary, nothing more and nothing less and get it out the door quickly. I have heard her speak and she tells the story about a retailer who can ship it quickly has fewer returns than a retailer who can't quite get the shipment out so soon. There is time for the consumer to change their mind if it takes too long.
June 17, 2015
This book explains "lean" software development: how the agile processes can be seen as applying the key ideas beyond the Toyota Production System (TPS) to software development. I liked the many stories which illustrate various lean success stories as well as some unexpected historical references. What I retain is that "lean" adds a human-centered dimension to agile: empowering people so they get creative, try, fail, learn and eventually improve their work processes by themselves. Though, how to implement it on a daily basis remains less obvious to me.
April 11, 2016
I have read Russian version of this book and frankly speaking the translation is awful. The book has been translated unprofessionaly and consists of grammatical errors, typos and "hard-to-read-and-understand-sentences". It took me 2-3 times to reread paragraphs in order to understand the meaning of Russian words. Overall, the book's content is good. I have already read Lean Startup by Eric Ries, hence I understand ideas behind lean approach especially for software development and MVP development.
I highly recommend this book for product managers/executives in software development.
I highly recommend this book for product managers/executives in software development.
March 26, 2017
This book is a joy. I may even call it as "Handbook Of Lean Software Development" or "Lean Software Development Manual". The book contains a great deal of experience from different companies Mr. and Mrs. Poppendieck worked with as well as from Toyota automobile manufacturer. Actually the way how Toyota works goes as a red line across the book. The material has solid reference base.
I will definitely go for other books from Poppendieck pair.
I will definitely go for other books from Poppendieck pair.
June 2, 2011
I appreciate the Poppendieck's approach to explaining lean concepts and applying them to software development. However, after reading three of their books, I'm convinced that what they really need to do is condense it down to 1 slightly longer book. There's too much overlap in content between each of their publications.
January 9, 2010
Well, finally, after 2 years partially read, I finally dug back in. Definintely and interesting book, some great portions to reference and use later.
May 31, 2008
cookbooks
Displaying 1 - 30 of 43 reviews