What do you think?
Rate this book
A Kent Beck Signature Book
Leading Lean Software Development: Results Are not the Point
Building on their breakthrough bestsellers Lean Software Development and Implementing Lean Software Development, Mary and Tom Poppendieck’s latest book shows software leaders and team members exactly how to drive high-value change throughout a software organization—and make it stick. They go far beyond generic implementation guidelines, demonstrating exactly how to make lean work in real projects, environments, and companies.
The Poppendiecks organize this book around the crucial concept of frames, the unspoken mental constructs that shape our perspectives and control our behavior in ways we rarely notice. For software leaders and team members, some frames lead to long-term failure, while others offer a strong foundation for success. Drawing on decades of experience, the authors present twenty-four frames that offer a coherent, complete framework for leading lean software development. You’ll discover powerful new ways to act as competency leader, product champion, improvement mentor, front-line leader, and even visionary.
Systems thinking: focusing on customers, bringing predictability to demand, and revamping policies that cause inefficiency Technical excellence: implementing low-dependency architectures, TDD, and evolutionary development processes, and promoting deeper developer expertise Reliable delivery: managing your biggest risks more effectively, and optimizing both workflow and schedules Relentless improvement: seeing problems, solving problems, sharing the knowledge Great people: finding and growing professionals with purpose, passion, persistence, and pride Aligned leaders: getting your entire leadership team on the same page
From the world’s number one experts in Lean software development, Leading Lean Software Development will be indispensable to everyone who wants to transform the promise of lean into reality—in enterprise IT and software companies alike.
441 pages, Kindle Edition
First published January 1, 2009
67 people are currently reading
1416 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 19 of 19 reviews
December 29, 2011
There are a few things I really, really liked about this book, and a few that I really, really hated.
What I liked most was this is the least dogmatic of the Poppendieck books, with much less of the "do it this way" and much more of the "generally follow this approach, here's a few variants, but maybe it might not apply for you". The chapters covering aligned leadership, working within the constraints of your current system, and managing a product portfolio were all really good. The pull scheduling was well explained as well.
For the bad: the authors tend to massive confirmation/survivor biases and will hunt for data supporting their ideas rather than the other way around. Djikstra's approach and attitude towards testing was (I feel) wildly mischaracterised to back up their arguments for TDD (something which I'm totally for, but I hate bad reasoning). While I agree that waterfall development processes should be taken out the back and shot, the way in which they outlined the history of waterfall was kind of wrong (see http://sinnema313.wordpress.com/2010/... for a bit of background) which makes me worry how many other chapters covering topics I don't know much about are just as wrong.
What I liked most was this is the least dogmatic of the Poppendieck books, with much less of the "do it this way" and much more of the "generally follow this approach, here's a few variants, but maybe it might not apply for you". The chapters covering aligned leadership, working within the constraints of your current system, and managing a product portfolio were all really good. The pull scheduling was well explained as well.
For the bad: the authors tend to massive confirmation/survivor biases and will hunt for data supporting their ideas rather than the other way around. Djikstra's approach and attitude towards testing was (I feel) wildly mischaracterised to back up their arguments for TDD (something which I'm totally for, but I hate bad reasoning). While I agree that waterfall development processes should be taken out the back and shot, the way in which they outlined the history of waterfall was kind of wrong (see http://sinnema313.wordpress.com/2010/... for a bit of background) which makes me worry how many other chapters covering topics I don't know much about are just as wrong.
July 13, 2020
Maybe 3 start as I've already know a lot of that but it's a good book and I think it would be decent 4 stars if I read it a couple years later.
September 3, 2016
Some of the best anecdotal stories on software development that I have read. Great wisdom and content, but failed to push me towards lean being significant short of a methodology. I think that if you are developing software you should read this book. Some people will love it and consider it a bible others will find it useful but not earth shattering.
May 28, 2018
I really liked this book. But I feel that some chapters were much more completed and detailed than others, whereas the diagram showing the chapters and frames seems to put the same importance on all of them. For example, I think that System Thinking could be put at a higher level than others because as its name suggests, it needs to take into account to all other parts of the system.
Some of good parts:
You are not going to change things by looking for scapegoats or setting more aggressive targets. Your current way of working produces the results in the chart; if you don’t like the results, you have to change the way the work is done. We frequently see efforts aimed at removing variation from every process, without recognizing that such efforts usually make things worse. Almost all variation (perhaps 95%) is common-cause variation—it is inherent in the system—and the only way to remove it is to change the way work is done. He concluded that most variation is a management problem.
You measure system capability; you do not prescribe it. As Deming once said, “If you have a stable system, then there is no use to specify a goal. You will get whatever the system will deliver. A goal beyond the capability of the system will not be reached. If you have not a stable system, then there is no point in setting a goal. There is no way to know what the system will produce: it has no capability.”
Incentive systems based on performance targets make the assumption that if people would only try harder, they could achieve better results—hence targets communicate an implicit assumption that people are not currently contributing their best efforts. Wouldn’t it be better to challenge people and teams to excel at delivering exceptional customer outcomes and communicate trust that they will do their best?
Stop putting features into our systems that aren’t absolutely necessary. If something has to be compromised— cost, schedule, or scope—the default choice should routinely be scope.
Our customers often want to use software to automate their complex processes. This is not a good idea. Business processes should be simplified first and automated later. How often do we help our customers simplify their processes before automating them?
The cost of complexity is hidden; it has a second-order effect on cost, so we just don’t see it in our financial systems. This makes complexity all the more pernicious—it’s hard to cost-justify spending money to keep things simple.
From a lean perspective, the fundamental job of managers is to understand how the work they manage works and then focus on how to make it better. This is not to say that all leaders must know all the answers; the critical thing is that they know what questions to ask.
When the only career path for these people is to leave their core expertise behind and become managers, we will never have top-notch technical leadership on the ground.
We might learn a lesson from the open-source movement, where all communication is written and the focus is on making the communication system extremely simple, appropriately concise, quickly searchable, and never bypassed by verbal communication.
We see that simple, low-dependency architectures and skilled technical implementation are the never-changing ingredients of successful software development. And more: those concepts have been robust over time.
I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you are led back to where you are, sitting in appreciation of the code someone left for you—code written by someone who cared deeply about the craft. (Michael Feathers)
Spear suggests that the main barrier to rapid learning does not lie within functions, it lies in the gaps between functions. High-velocity organizations do not focus of getting the work done, they focus on learning how to get work done.
As complexity increases, so does the need for specialists. As specialists have to deal with more and more information, they frame the world through increasingly narrower frames, and the view of the overall system fades from view even as it grows more complex. Handovers between specialties are breeding grounds for ambiguities, work-arounds, and failures. The problems are usually associated with spanning boundaries.
Boundary-spanning problems are resolved by focusing on the customer.
In the book Workplace Management (Taiichi Ohno) said:
There is something called standard work, but standards should be changing constantly. Instead, if you think of standard as the best you can do, it’s all over. Standard is only a baseline for doing kaizen.
When creating standard work, it will be difficult to establish a standard if you are trying to achieve “the best way”. Document exactly what you are doing now.
That is why one way to motivating people to do kaizen is to create a poor standard. But don’t make it too bad. Without some standard, you can’t say “we made it better” because there is nothing to compare it to, so you must create a standard for comparison. Take that standard and if the work is not easy to perform, give many suggestions and do kaizen.
In the book What is Total Quality Control? The Japanese Way, Kaoru Ishikawa writes: “Standards and regulations are imperfect. They must be reviewed and revised constantly. If newly established standards and regulations are not revised in six months, it is a proof that no one is seriously using them. Detailed standards and regulations are useless if they are established by headquarters staff and engineer-specialists who do not know or do not try to know the workplace and who ignores the wishes of the people who have to use them.”
If process standards are rules telling people what to do, improvement will be suppressed. If they are a baseline that workers are expected to improve, people will discovery better ways to do their work than a central organization could ever imagine.
The most important thing in a continuous improvement environment is to expose problems, look for them, learn how to see them, and welcome them. Do not ignore problems or think of them as background noise. Problems are simply the work process telling you that you don’t understand it well enough, so pay attention and hear. Problems should never carry blame, because then they will just be suppressed and the opportunity to learn will be extinguished. Ignore problems and you will get to work around the same problem every day. Expose and welcome problems and you will have the opportunity to resolve them once and for all.
Problem solving takes time, so it must be an essential part of the work being done, not a peripheral activity that takes place when there’s some leftover time.
Where the laissez-faire, hands-off manager will content himself to set targets and delegate everything, essentially saying “I don’t care how you do it, as long as you get the results”, the Toyota manager desperately wants to know how you’ll do it, saying, “I want to hear everything about your thinking, tell me about your plans”. Only then can the manager mentor the problem solver.
The Toyota Way has two pillars: continuous improvement and respect for people. By people, we mean employees, supply partners and customers. “Customer first” is one of the company’s core tenets. We don’t mean just the end customer. On the assembly line the person at the next workstation is also your customer. That leads teamwork. If you adopt that principle, you’ll also keep analyzing what you do in order to see if you’re doing things perfectly, so you’re not troubling our customer. That nurtures your ability to identify problems, and if you closely observe things, it will lead to kaizen: continuous improvement. The root of the Toyota Way is to be dissatisfied with the status quo. You have to ask constantly “Why are we doing this?”.
Drucker believed that increasing knowledge worker productivity is the most important management challenge of the 21th century. He insisted that the only way to measure knowledge worker productivity was to measure the outcomes of the system in which they work.
even when it is easy for members of the leadership team to agree on what they want, it is often very difficult for them to agree on cause and effect. Worse, the lack of agreement is often not obvious. Leaders often assume that their colleagues think the same way they do, when in fact their views may be quite different.
Plans Are Worthless, But Planning Is Everything
Some of good parts:
You are not going to change things by looking for scapegoats or setting more aggressive targets. Your current way of working produces the results in the chart; if you don’t like the results, you have to change the way the work is done. We frequently see efforts aimed at removing variation from every process, without recognizing that such efforts usually make things worse. Almost all variation (perhaps 95%) is common-cause variation—it is inherent in the system—and the only way to remove it is to change the way work is done. He concluded that most variation is a management problem.
You measure system capability; you do not prescribe it. As Deming once said, “If you have a stable system, then there is no use to specify a goal. You will get whatever the system will deliver. A goal beyond the capability of the system will not be reached. If you have not a stable system, then there is no point in setting a goal. There is no way to know what the system will produce: it has no capability.”
Incentive systems based on performance targets make the assumption that if people would only try harder, they could achieve better results—hence targets communicate an implicit assumption that people are not currently contributing their best efforts. Wouldn’t it be better to challenge people and teams to excel at delivering exceptional customer outcomes and communicate trust that they will do their best?
Stop putting features into our systems that aren’t absolutely necessary. If something has to be compromised— cost, schedule, or scope—the default choice should routinely be scope.
Our customers often want to use software to automate their complex processes. This is not a good idea. Business processes should be simplified first and automated later. How often do we help our customers simplify their processes before automating them?
The cost of complexity is hidden; it has a second-order effect on cost, so we just don’t see it in our financial systems. This makes complexity all the more pernicious—it’s hard to cost-justify spending money to keep things simple.
From a lean perspective, the fundamental job of managers is to understand how the work they manage works and then focus on how to make it better. This is not to say that all leaders must know all the answers; the critical thing is that they know what questions to ask.
When the only career path for these people is to leave their core expertise behind and become managers, we will never have top-notch technical leadership on the ground.
We might learn a lesson from the open-source movement, where all communication is written and the focus is on making the communication system extremely simple, appropriately concise, quickly searchable, and never bypassed by verbal communication.
We see that simple, low-dependency architectures and skilled technical implementation are the never-changing ingredients of successful software development. And more: those concepts have been robust over time.
I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you are led back to where you are, sitting in appreciation of the code someone left for you—code written by someone who cared deeply about the craft. (Michael Feathers)
Spear suggests that the main barrier to rapid learning does not lie within functions, it lies in the gaps between functions. High-velocity organizations do not focus of getting the work done, they focus on learning how to get work done.
As complexity increases, so does the need for specialists. As specialists have to deal with more and more information, they frame the world through increasingly narrower frames, and the view of the overall system fades from view even as it grows more complex. Handovers between specialties are breeding grounds for ambiguities, work-arounds, and failures. The problems are usually associated with spanning boundaries.
Boundary-spanning problems are resolved by focusing on the customer.
In the book Workplace Management (Taiichi Ohno) said:
There is something called standard work, but standards should be changing constantly. Instead, if you think of standard as the best you can do, it’s all over. Standard is only a baseline for doing kaizen.
When creating standard work, it will be difficult to establish a standard if you are trying to achieve “the best way”. Document exactly what you are doing now.
That is why one way to motivating people to do kaizen is to create a poor standard. But don’t make it too bad. Without some standard, you can’t say “we made it better” because there is nothing to compare it to, so you must create a standard for comparison. Take that standard and if the work is not easy to perform, give many suggestions and do kaizen.
In the book What is Total Quality Control? The Japanese Way, Kaoru Ishikawa writes: “Standards and regulations are imperfect. They must be reviewed and revised constantly. If newly established standards and regulations are not revised in six months, it is a proof that no one is seriously using them. Detailed standards and regulations are useless if they are established by headquarters staff and engineer-specialists who do not know or do not try to know the workplace and who ignores the wishes of the people who have to use them.”
If process standards are rules telling people what to do, improvement will be suppressed. If they are a baseline that workers are expected to improve, people will discovery better ways to do their work than a central organization could ever imagine.
The most important thing in a continuous improvement environment is to expose problems, look for them, learn how to see them, and welcome them. Do not ignore problems or think of them as background noise. Problems are simply the work process telling you that you don’t understand it well enough, so pay attention and hear. Problems should never carry blame, because then they will just be suppressed and the opportunity to learn will be extinguished. Ignore problems and you will get to work around the same problem every day. Expose and welcome problems and you will have the opportunity to resolve them once and for all.
Problem solving takes time, so it must be an essential part of the work being done, not a peripheral activity that takes place when there’s some leftover time.
Where the laissez-faire, hands-off manager will content himself to set targets and delegate everything, essentially saying “I don’t care how you do it, as long as you get the results”, the Toyota manager desperately wants to know how you’ll do it, saying, “I want to hear everything about your thinking, tell me about your plans”. Only then can the manager mentor the problem solver.
The Toyota Way has two pillars: continuous improvement and respect for people. By people, we mean employees, supply partners and customers. “Customer first” is one of the company’s core tenets. We don’t mean just the end customer. On the assembly line the person at the next workstation is also your customer. That leads teamwork. If you adopt that principle, you’ll also keep analyzing what you do in order to see if you’re doing things perfectly, so you’re not troubling our customer. That nurtures your ability to identify problems, and if you closely observe things, it will lead to kaizen: continuous improvement. The root of the Toyota Way is to be dissatisfied with the status quo. You have to ask constantly “Why are we doing this?”.
Drucker believed that increasing knowledge worker productivity is the most important management challenge of the 21th century. He insisted that the only way to measure knowledge worker productivity was to measure the outcomes of the system in which they work.
even when it is easy for members of the leadership team to agree on what they want, it is often very difficult for them to agree on cause and effect. Worse, the lack of agreement is often not obvious. Leaders often assume that their colleagues think the same way they do, when in fact their views may be quite different.
Plans Are Worthless, But Planning Is Everything
February 26, 2020
You can improve the system only by dealing with its biggest constraint.
The last time I read a book on Lean was 2.5 years ago. At that time, Lean Enterprise was exactly what I needed when I needed it.
Mary Poppendieck, as an author, can be quite dogmatic. Out of her books, I've picked Leading Lean Software Development partly because I've learned this one is less dogmatic than the others. I think that's true. Overall, I enjoyed the content and wisdom within.
I've finished reading this book at the start of my 3-week vacation. I immediately put a to-do for future after-vacation self to revisit notes and highlights. There are more than a couple of things I will want to try and use in my work.
Each time I read about Lean, I learn new things. I'm sure that will also be the case a couple of years from now.
The last time I read a book on Lean was 2.5 years ago. At that time, Lean Enterprise was exactly what I needed when I needed it.
Mary Poppendieck, as an author, can be quite dogmatic. Out of her books, I've picked Leading Lean Software Development partly because I've learned this one is less dogmatic than the others. I think that's true. Overall, I enjoyed the content and wisdom within.
I've finished reading this book at the start of my 3-week vacation. I immediately put a to-do for future after-vacation self to revisit notes and highlights. There are more than a couple of things I will want to try and use in my work.
Each time I read about Lean, I learn new things. I'm sure that will also be the case a couple of years from now.
April 3, 2024
If I could recommend just one book to executives, people managers, project managers or any leaders in software companies it would probably be this one. Its remarkably succinct, and yet full of wisdom. Things that have taken me years to learn through hard won experience might be just summarized in a few short sentences somewhere in this book. And the whole book is like that, shock full of these incredible nuggets of wisdom, but it might difficult to realize and take in because its so compact. Anyhow, I re-read it every few years and still find new things to learn.
January 11, 2018
You could accuse me of some bias here: I'm a big fan of the Poppendiecks' books, and Tom wrote the forward for my book. But I assure you, my fully objective opinion is that this is excellent.
It differs greatly from their prior work primarily in that it takes more of a systems tone: in fact, the "software development" part of the title is too much of a constraint. I'd recommend this book to anyone responsible for delivering value to clients, in any industry.
It differs greatly from their prior work primarily in that it takes more of a systems tone: in fact, the "software development" part of the title is too much of a constraint. I'd recommend this book to anyone responsible for delivering value to clients, in any industry.
June 10, 2020
It was published in 2009, so there are very few new things, from today's perspective. The Poppendieks manage to include in a single book a whole variety of topics that are aligned to their way of thinking of "Lean Software Management". It surprised me to find topics like clean code, beyond budgeting, OODA Loop, kanban, Auftragstaktik, design thinking, Hostfede's culture dimensions, or systems thinking.
I enjoyed more their previous books.
I enjoyed more their previous books.
December 12, 2018
It describes lean practices with the examples. Basically it covers all trends connected to agile and lean software development. Knowledge now it is well known, but it is good to read it again to structure thoughts.
October 4, 2020
Good book! Recommend for agile or lean leaders in SW development. For me personally not a lot of new things. I liked especially the improvement frame, the the explanation of A3 reports in SE development, iterations vs Kanban and frame 23 about alignment.
February 29, 2020
Another great book from the Poppendiecks. The focus is more on the leadership of agile, but with many great examples and quotes from leaders in many different companies and industries.
February 2, 2017
What intrigued me: Dennis, the director of architecture, at my office lent me his 2 favorite Poppendieck books since we are implementing the Scaled Agile Framework.
What I liked: There is a lot of good information in this book.
Chapter 3 - Reliable Delivery/Frame 10 - Level Workflow focuses on how Kanban should work. Most of our teams are scrum, but our operations groups is Kanban. The details in this section have helped me know what the correct questions are when engaging with this group.
Chapter 4 - Relentless Improvement/Frame 15 - Expose Problems & 16 - Learn to Improve provide a lot of tools I think we can implement at our next inspect and adapt workshop. This is an area I have been struggling with so this section seemed particularly helpful.
What I didn't like: So very dry. It is basically a text book so it took me a long time to get through.
Favorite quote: TBD
What I liked: There is a lot of good information in this book.
Chapter 3 - Reliable Delivery/Frame 10 - Level Workflow focuses on how Kanban should work. Most of our teams are scrum, but our operations groups is Kanban. The details in this section have helped me know what the correct questions are when engaging with this group.
Chapter 4 - Relentless Improvement/Frame 15 - Expose Problems & 16 - Learn to Improve provide a lot of tools I think we can implement at our next inspect and adapt workshop. This is an area I have been struggling with so this section seemed particularly helpful.
What I didn't like: So very dry. It is basically a text book so it took me a long time to get through.
Favorite quote: TBD
April 14, 2011
I thought this was better than the first Lean book I read by the Poppendiecks. Their breakdown of lean methods into perspectives and frames made it easy to digest on idea at a time. The "your turn" action plans at the end of each chapter are a good jumping off point for an organization leader looking to introduce lean thinking into the company.
What I really appreciate about the Poppendieck's books is their meticulous attribution. They borrow from a lot of sources, and make sure to give them all due credit. This also makes it very easy to do your own continued research into lean. I find it especially valuable that they work from a lot of original sources, such as books by Taichi Ohno, on the topic. I have to find ways now to work "salary thief" into normal office conversation...
What I really appreciate about the Poppendieck's books is their meticulous attribution. They borrow from a lot of sources, and make sure to give them all due credit. This also makes it very easy to do your own continued research into lean. I find it especially valuable that they work from a lot of original sources, such as books by Taichi Ohno, on the topic. I have to find ways now to work "salary thief" into normal office conversation...
October 28, 2013
I have not actually finished reading this book, I am always reading it. THis is standard reference me in my professional life. Poppendiecks give a practical and rings true, advice for changing the chaos of software development to getting it to work. Valuable book indeed. synthesizes views from other places. I especially ( given my decades of experience in software!) appreciate the historical view of how software development processes have changed over the years, and most importantly, what WORKS.
April 23, 2016
Starts really strong then doesn't have much left to say. The ideas are essential for anyone involved in shipping business software and this is a clear and effective presentation, but it could be slimmed down.
November 3, 2011
Good. Lots of tools to add to your agile collection.
December 3, 2013
This is a must read book for any business leader who needs to understand key elements of a great software development process and organization.
August 7, 2019
Loved the Lean concept in this book, will read it again!
Read
February 2, 2016Great book for managers, execs. Mary and Tom did it again with a great book highlighting what's really important to creating an environment where agile and lean can thrive.
Displaying 1 - 19 of 19 reviews