Take a photo of a barcode or cover
4.11 AVERAGE
4.11 AVERAGE
This book explains how to apply Agile with principles, practices and advice based on facts and historical experiences. A must-read for leaders, managers and people who want to learn more about agile and empowering teams.
In the last couple of years, I have heard many times about lean manufacturing (and in particular the Toyota way of manufacturing). I have also read a couple of articles by Mary Popendieck on the web, so I thought I would get this book and find out more.
I am glad I did. It is exactly the kind of book I like to read about software engineering - it is written by somebody with lots of hands on experience, it describes new and interesting techniques for producing high quality software, and it has plenty of references for further reading.
It is written by Mary and Tom Poppendieck, but I get the feeling that most of the input comes from Mary. She has solid experience with software development in many roles and places. In addition, she also has extensive experience with manufacturing, and one of the biggest pluses with this book is how she shows how to transfer principles and practises from lean manufacturing to software development. The type of development they advocate is squarely in the agile camp (obvious from the subtitle as well).
There are seven chapters on seven lean principles, with 22 "thinking tools" with specific practices or principles. If you are familiar with Extreme Programming (for example through Kent Beck's first XP book), you will recognize a lot of the ideas in the thinking tools. Examples are: Feedback (tool 3), Iterations (tool 4), Options Thinking (tool 7), Refactoring (tool 19) and Testing (tool 20).
However, the value for me was the many ideas from manufacturing that I had not previously read about in the agile literature. Examples are: Value Stream Mapping (tool 2), Set-Based Development (tool 6), Pull Systems (tool 10) and Cost of Delay (tool 12)
There is actually so much good material in this book that I will have to concentrate on just a few examples. The first lean principal is Eliminate Waste. "Waste is anything that does not add value to a product, value as perceived by the customer". This is a great starting point, and one that has many implications. Examples of waste in software development are: extra features (that are not needed now), task switching, waiting, motion (for example document hand-offs), and of course defects. With this definition of waste, a value stream map helps you to see waste by mapping where value is added, and where there is waiting etc as a product is developed.
Another interesting part is tool 10 in chapter 4 (Deliver as Fast as Possible). Here the authors describe how pull systems work (you set things up so workers can figure out for themselves what needs to be done, instead of telling them what to do). They continue with an example of a pull system, the simple and ingenious Kanban card system used in Japan, and show how a similar system can be used for software development.
The use of pull systems goes hand in hand with the theme in chapter 5 - Empower the Team. The idea here is that the front-line workers are the ones that know best how things should be done, and they should be empowered to act on this knowledge. Most of this material is covered in regular books on business improvement, and there wasn't much new material here for me. So for me, this was the least interesting chapter, together with the parts on contract negotiation in chapter 7 (simply because I am not involved in any contract negotiations).
Another theme in the book is to not sub-optimize. There is a good example from the manufacturing world, where a video tape machine was run at full capacity. The utilization of the machine was maximized, but that did not maximize company profit. It is tempting to break up a task in smaller tasks, and then optimize each task individually. But as the authors show, that is very often a bad strategy. A good analogy from the book is when they point out that Lance Armstrong, winner of Tour de France for many years, only won 4 out of 21 daily stages, even though he was the eventual winner. Had he tried to win each daily stage, he probably would not have won the whole race.
There are also many good examples in the book. I particularly liked the one about HP printers. By waiting to do the final electrical configuration of the printer until after it was ordered, it was much easier to match the supply of printers in a certain configuration with the demand. It cost a bit more to do the configuration so late, but that was more than off-set by the savings of not having to forecast exactly how many printers in a certain configuration that were needed at different locations.
I also found many interesting nuggets of information about software development sprinkled through the book. The diagram on page 18 for example shows how experienced designers work out a solution to an ill-defined design problem by repeatedly moving between high level and low level design activities. I had never seen this described before, but immediately recognized that that is how I work too (as opposed to a straight top-down approach). This too explains why I think you should also keep coding even if you are an architect - because to find the best solution you must alternate between high and low levels of design.
Another good part was their diagnosis of the problems with CMM and ISO9000. They write that both programs have a bias towards documenting and thus standardizing existing process, rather than improving the process, even though it is not the intent of either. I agree completely.
This is a practical book, and there are lots of good (and well described) ideas that can be used in software development. It is well worth getting, both for developers, managers and project leaders. Recommended.
I am glad I did. It is exactly the kind of book I like to read about software engineering - it is written by somebody with lots of hands on experience, it describes new and interesting techniques for producing high quality software, and it has plenty of references for further reading.
It is written by Mary and Tom Poppendieck, but I get the feeling that most of the input comes from Mary. She has solid experience with software development in many roles and places. In addition, she also has extensive experience with manufacturing, and one of the biggest pluses with this book is how she shows how to transfer principles and practises from lean manufacturing to software development. The type of development they advocate is squarely in the agile camp (obvious from the subtitle as well).
There are seven chapters on seven lean principles, with 22 "thinking tools" with specific practices or principles. If you are familiar with Extreme Programming (for example through Kent Beck's first XP book), you will recognize a lot of the ideas in the thinking tools. Examples are: Feedback (tool 3), Iterations (tool 4), Options Thinking (tool 7), Refactoring (tool 19) and Testing (tool 20).
However, the value for me was the many ideas from manufacturing that I had not previously read about in the agile literature. Examples are: Value Stream Mapping (tool 2), Set-Based Development (tool 6), Pull Systems (tool 10) and Cost of Delay (tool 12)
There is actually so much good material in this book that I will have to concentrate on just a few examples. The first lean principal is Eliminate Waste. "Waste is anything that does not add value to a product, value as perceived by the customer". This is a great starting point, and one that has many implications. Examples of waste in software development are: extra features (that are not needed now), task switching, waiting, motion (for example document hand-offs), and of course defects. With this definition of waste, a value stream map helps you to see waste by mapping where value is added, and where there is waiting etc as a product is developed.
Another interesting part is tool 10 in chapter 4 (Deliver as Fast as Possible). Here the authors describe how pull systems work (you set things up so workers can figure out for themselves what needs to be done, instead of telling them what to do). They continue with an example of a pull system, the simple and ingenious Kanban card system used in Japan, and show how a similar system can be used for software development.
The use of pull systems goes hand in hand with the theme in chapter 5 - Empower the Team. The idea here is that the front-line workers are the ones that know best how things should be done, and they should be empowered to act on this knowledge. Most of this material is covered in regular books on business improvement, and there wasn't much new material here for me. So for me, this was the least interesting chapter, together with the parts on contract negotiation in chapter 7 (simply because I am not involved in any contract negotiations).
Another theme in the book is to not sub-optimize. There is a good example from the manufacturing world, where a video tape machine was run at full capacity. The utilization of the machine was maximized, but that did not maximize company profit. It is tempting to break up a task in smaller tasks, and then optimize each task individually. But as the authors show, that is very often a bad strategy. A good analogy from the book is when they point out that Lance Armstrong, winner of Tour de France for many years, only won 4 out of 21 daily stages, even though he was the eventual winner. Had he tried to win each daily stage, he probably would not have won the whole race.
There are also many good examples in the book. I particularly liked the one about HP printers. By waiting to do the final electrical configuration of the printer until after it was ordered, it was much easier to match the supply of printers in a certain configuration with the demand. It cost a bit more to do the configuration so late, but that was more than off-set by the savings of not having to forecast exactly how many printers in a certain configuration that were needed at different locations.
I also found many interesting nuggets of information about software development sprinkled through the book. The diagram on page 18 for example shows how experienced designers work out a solution to an ill-defined design problem by repeatedly moving between high level and low level design activities. I had never seen this described before, but immediately recognized that that is how I work too (as opposed to a straight top-down approach). This too explains why I think you should also keep coding even if you are an architect - because to find the best solution you must alternate between high and low levels of design.
Another good part was their diagnosis of the problems with CMM and ISO9000. They write that both programs have a bias towards documenting and thus standardizing existing process, rather than improving the process, even though it is not the intent of either. I agree completely.
This is a practical book, and there are lots of good (and well described) ideas that can be used in software development. It is well worth getting, both for developers, managers and project leaders. Recommended.
I'm working my way through the classics on Lean and Agile methods, I have met the great Tom and Mary and was extremely impressed and since this was selected for my book club, then here we are - another classic ticked off. This book is definitely essential reading for anyone involved in software development.
The premise of the book is that software development can learn allot from general product development principles. Much has been learned in Toyota about how to streamline product development and in all the cases presented it's clear the lessons and philosophy can be applied to software product development.
The principles of lean are:
1. Eliminate waste
2.Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team - people with the knowledge make the decisions
6. Build integrity in - integrity is not just quality, it's also adaptability to change
7. See the whole - don't optimise pieces at the expense of the whole (put all metrics one level above the area you want to optimise)
If you haven't done much reading on Toyota you will soon find your to-read list expanding to include lots of Toyota books. I was not really aware at all of all the ground breaking work done in Toyota and how it can be applied in lots of different industries and settings.
The book is presented as a series of tools which are each explained in quite specific ways. What I really like about the Poppendeicks is that they are not about buzz words or silver bullets. Everything needs to be adapted and applied as it fits your environment, and you won't hear or read 'scrum master' and similar trendy buzz words from them. They are about understanding the principles behind any particular buzz word, going back and working up from how to apply that principle to your environment. This is not a bunch of template techniques to pick up and stick on your organisation, it's about understanding the meaning behind them. Along those lines I'm not going to try to summarise these, just list them to give you a flavour of it. Go read the book - more than once!
The tools presented are:
Seeing Waste if someone is hassling you to complete that document it is probably waste -question its value
Value Stream Mapping
Feedback
Iterations
Syncronisation - multiple teams, interfaces, organisational structures
Set Based Development (developing multiple solutions and choosing the best one)
The Last Responsible Moment
Making Decisions (don't delay just because deciding late is good - make the decision when it needs to be made)
Pull Systems - question the need for elaborate systems to manage future workload, what value are they really giving the business - is there another way - yes - Kanban
Queuing Theory - understand the bottlenecks in your process and optimise them
Cost of Delay - this also comes up heavily as a tool in Stage Gate Development, the Poppendeicks actually suggest a finance / accountant person on every development effort to crunch numbers and come up with figures like cost of delay. This allows the team to make the right trade offs in all sorts of ways. If there is a strong cost benefit or payback analysis the team can understand the extra profit that can be made from extra features and make the right decision whether to include them.
Self- Determination - let the team make their own improvements, measure their own outcomes and treat people like volunteers
Motivation - hard to summarise briefly, so many ideas in here about motivation and how to achieve it
Leadership - master developers, project managers - given all the team decisions exactly what is the project manager left to do? Lots - let's start with: identifying waste, sketching a value stream and working on bottlenecks, run iteration planning meetings and daily meetings, provide information radars, syncronise multiple teams, ensure use of standard tools for development, that refactoring is being done, work with accounting to develop financial models, support the team and motivate. They don't build Gantt charts, they create a release plan with milestones, ensure design is change tolerant, ensure testing and integration are done during development not after and engage with outside team members such as service and support.
Expertise - particularly the importance of maintaining matrix structures that ensure there are communities of excellence. Functional managers are the experts in their function and ensure they building the skills of their practioners.
Perceived Integrity - chief engineers / master developers and models for design integrity
Conceptual Integrity
Refactoring
Measurement - as said above, always measure one layer higher - not the individual the team, not the team the group, not the group the company. This avoids sub-optimisations locally at the expense of the whole.
Contracts - the relationship between supplier and developer that best fits lean product development - share the risk and share the reward
The premise of the book is that software development can learn allot from general product development principles. Much has been learned in Toyota about how to streamline product development and in all the cases presented it's clear the lessons and philosophy can be applied to software product development.
The principles of lean are:
1. Eliminate waste
2.Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team - people with the knowledge make the decisions
6. Build integrity in - integrity is not just quality, it's also adaptability to change
7. See the whole - don't optimise pieces at the expense of the whole (put all metrics one level above the area you want to optimise)
If you haven't done much reading on Toyota you will soon find your to-read list expanding to include lots of Toyota books. I was not really aware at all of all the ground breaking work done in Toyota and how it can be applied in lots of different industries and settings.
The book is presented as a series of tools which are each explained in quite specific ways. What I really like about the Poppendeicks is that they are not about buzz words or silver bullets. Everything needs to be adapted and applied as it fits your environment, and you won't hear or read 'scrum master' and similar trendy buzz words from them. They are about understanding the principles behind any particular buzz word, going back and working up from how to apply that principle to your environment. This is not a bunch of template techniques to pick up and stick on your organisation, it's about understanding the meaning behind them. Along those lines I'm not going to try to summarise these, just list them to give you a flavour of it. Go read the book - more than once!
The tools presented are:
Seeing Waste if someone is hassling you to complete that document it is probably waste -question its value
Value Stream Mapping
Feedback
Iterations
Syncronisation - multiple teams, interfaces, organisational structures
Set Based Development (developing multiple solutions and choosing the best one)
The Last Responsible Moment
Making Decisions (don't delay just because deciding late is good - make the decision when it needs to be made)
Pull Systems - question the need for elaborate systems to manage future workload, what value are they really giving the business - is there another way - yes - Kanban
Queuing Theory - understand the bottlenecks in your process and optimise them
Cost of Delay - this also comes up heavily as a tool in Stage Gate Development, the Poppendeicks actually suggest a finance / accountant person on every development effort to crunch numbers and come up with figures like cost of delay. This allows the team to make the right trade offs in all sorts of ways. If there is a strong cost benefit or payback analysis the team can understand the extra profit that can be made from extra features and make the right decision whether to include them.
Self- Determination - let the team make their own improvements, measure their own outcomes and treat people like volunteers
Motivation - hard to summarise briefly, so many ideas in here about motivation and how to achieve it
Leadership - master developers, project managers - given all the team decisions exactly what is the project manager left to do? Lots - let's start with: identifying waste, sketching a value stream and working on bottlenecks, run iteration planning meetings and daily meetings, provide information radars, syncronise multiple teams, ensure use of standard tools for development, that refactoring is being done, work with accounting to develop financial models, support the team and motivate. They don't build Gantt charts, they create a release plan with milestones, ensure design is change tolerant, ensure testing and integration are done during development not after and engage with outside team members such as service and support.
Expertise - particularly the importance of maintaining matrix structures that ensure there are communities of excellence. Functional managers are the experts in their function and ensure they building the skills of their practioners.
Perceived Integrity - chief engineers / master developers and models for design integrity
Conceptual Integrity
Refactoring
Measurement - as said above, always measure one layer higher - not the individual the team, not the team the group, not the group the company. This avoids sub-optimisations locally at the expense of the whole.
Contracts - the relationship between supplier and developer that best fits lean product development - share the risk and share the reward
Classic book on apply lean principles to software development. Focuses on problems and practices rather than spoon feeding solutions. Seems as relevant today as when it came out too. Definitely worth a read.
I should have read this when my former company implemented "lean". I'm probably going to carry this around as a reference manual. Mary explains concepts clearly and it's obvious that she's had tons of real world experience. I had several light bulb moments where things just started making sense. This book reinforced the things I intuitively do right and highlighted the areas where I need to improve. If you've read Toyota Kata and are looking for a link to bridge the gap between manufacturing and software development, this is the book.
informative
inspiring
medium-paced
In the last couple of years, I have heard many times about lean manufacturing (and in particular the Toyota way of manufacturing). I have also read a couple of articles by Mary Popendieck on the web, so I thought I would get this book and find out more.
I am glad I did. It is exactly the kind of book I like to read about software engineering - it is written by somebody with lots of hands on experience, it describes new and interesting techniques for producing high quality software, and it has plenty of references for further reading.
It is written by Mary and Tom Poppendieck, but I get the feeling that most of the input comes from Mary. She has solid experience with software development in many roles and places. In addition, she also has extensive experience with manufacturing, and one of the biggest pluses with this book is how she shows how to transfer principles and practises from lean manufacturing to software development. The type of development they advocate is squarely in the agile camp (obvious from the subtitle as well).
There are seven chapters on seven lean principles, with 22 "thinking tools" with specific practices or principles. If you are familiar with Extreme Programming (for example through Kent Beck's first XP book), you will recognize a lot of the ideas in the thinking tools. Examples are: Feedback (tool 3), Iterations (tool 4), Options Thinking (tool 7), Refactoring (tool 19) and Testing (tool 20).
However, the value for me was the many ideas from manufacturing that I had not previously read about in the agile literature. Examples are: Value Stream Mapping (tool 2), Set-Based Development (tool 6), Pull Systems (tool 10) and Cost of Delay (tool 12)
There is actually so much good material in this book that I will have to concentrate on just a few examples. The first lean principal is Eliminate Waste. "Waste is anything that does not add value to a product, value as perceived by the customer". This is a great starting point, and one that has many implications. Examples of waste in software development are: extra features (that are not needed now), task switching, waiting, motion (for example document hand-offs), and of course defects. With this definition of waste, a value stream map helps you to see waste by mapping where value is added, and where there is waiting etc as a product is developed.
Another interesting part is tool 10 in chapter 4 (Deliver as Fast as Possible). Here the authors describe how pull systems work (you set things up so workers can figure out for themselves what needs to be done, instead of telling them what to do). They continue with an example of a pull system, the simple and ingenious Kanban card system used in Japan, and show how a similar system can be used for software development.
The use of pull systems goes hand in hand with the theme in chapter 5 - Empower the Team. The idea here is that the front-line workers are the ones that know best how things should be done, and they should be empowered to act on this knowledge. Most of this material is covered in regular books on business improvement, and there wasn't much new material here for me. So for me, this was the least interesting chapter, together with the parts on contract negotiation in chapter 7 (simply because I am not involved in any contract negotiations).
Another theme in the book is to not sub-optimize. There is a good example from the manufacturing world, where a video tape machine was run at full capacity. The utilization of the machine was maximized, but that did not maximize company profit. It is tempting to break up a task in smaller tasks, and then optimize each task individually. But as the authors show, that is very often a bad strategy. A good analogy from the book is when they point out that Lance Armstrong, winner of Tour de France for many years, only won 4 out of 21 daily stages, even though he was the eventual winner. Had he tried to win each daily stage, he probably would not have won the whole race.
There are also many good examples in the book. I particularly liked the one about HP printers. By waiting to do the final electrical configuration of the printer until after it was ordered, it was much easier to match the supply of printers in a certain configuration with the demand. It cost a bit more to do the configuration so late, but that was more than off-set by the savings of not having to forecast exactly how many printers in a certain configuration that were needed at different locations.
I also found many interesting nuggets of information about software development sprinkled through the book. The diagram on page 18 for example shows how experienced designers work out a solution to an ill-defined design problem by repeatedly moving between high level and low level design activities. I had never seen this described before, but immediately recognized that that is how I work too (as opposed to a straight top-down approach). This too explains why I think you should also keep coding even if you are an architect - because to find the best solution you must alternate between high and low levels of design.
Another good part was their diagnosis of the problems with CMM and ISO9000. They write that both programs have a bias towards documenting and thus standardizing existing process, rather than improving the process, even though it is not the intent of either. I agree completely.
This is a practical book, and there are lots of good (and well described) ideas that can be used in software development. It is well worth getting, both for developers, managers and project leaders. Recommended.
I am glad I did. It is exactly the kind of book I like to read about software engineering - it is written by somebody with lots of hands on experience, it describes new and interesting techniques for producing high quality software, and it has plenty of references for further reading.
It is written by Mary and Tom Poppendieck, but I get the feeling that most of the input comes from Mary. She has solid experience with software development in many roles and places. In addition, she also has extensive experience with manufacturing, and one of the biggest pluses with this book is how she shows how to transfer principles and practises from lean manufacturing to software development. The type of development they advocate is squarely in the agile camp (obvious from the subtitle as well).
There are seven chapters on seven lean principles, with 22 "thinking tools" with specific practices or principles. If you are familiar with Extreme Programming (for example through Kent Beck's first XP book), you will recognize a lot of the ideas in the thinking tools. Examples are: Feedback (tool 3), Iterations (tool 4), Options Thinking (tool 7), Refactoring (tool 19) and Testing (tool 20).
However, the value for me was the many ideas from manufacturing that I had not previously read about in the agile literature. Examples are: Value Stream Mapping (tool 2), Set-Based Development (tool 6), Pull Systems (tool 10) and Cost of Delay (tool 12)
There is actually so much good material in this book that I will have to concentrate on just a few examples. The first lean principal is Eliminate Waste. "Waste is anything that does not add value to a product, value as perceived by the customer". This is a great starting point, and one that has many implications. Examples of waste in software development are: extra features (that are not needed now), task switching, waiting, motion (for example document hand-offs), and of course defects. With this definition of waste, a value stream map helps you to see waste by mapping where value is added, and where there is waiting etc as a product is developed.
Another interesting part is tool 10 in chapter 4 (Deliver as Fast as Possible). Here the authors describe how pull systems work (you set things up so workers can figure out for themselves what needs to be done, instead of telling them what to do). They continue with an example of a pull system, the simple and ingenious Kanban card system used in Japan, and show how a similar system can be used for software development.
The use of pull systems goes hand in hand with the theme in chapter 5 - Empower the Team. The idea here is that the front-line workers are the ones that know best how things should be done, and they should be empowered to act on this knowledge. Most of this material is covered in regular books on business improvement, and there wasn't much new material here for me. So for me, this was the least interesting chapter, together with the parts on contract negotiation in chapter 7 (simply because I am not involved in any contract negotiations).
Another theme in the book is to not sub-optimize. There is a good example from the manufacturing world, where a video tape machine was run at full capacity. The utilization of the machine was maximized, but that did not maximize company profit. It is tempting to break up a task in smaller tasks, and then optimize each task individually. But as the authors show, that is very often a bad strategy. A good analogy from the book is when they point out that Lance Armstrong, winner of Tour de France for many years, only won 4 out of 21 daily stages, even though he was the eventual winner. Had he tried to win each daily stage, he probably would not have won the whole race.
There are also many good examples in the book. I particularly liked the one about HP printers. By waiting to do the final electrical configuration of the printer until after it was ordered, it was much easier to match the supply of printers in a certain configuration with the demand. It cost a bit more to do the configuration so late, but that was more than off-set by the savings of not having to forecast exactly how many printers in a certain configuration that were needed at different locations.
I also found many interesting nuggets of information about software development sprinkled through the book. The diagram on page 18 for example shows how experienced designers work out a solution to an ill-defined design problem by repeatedly moving between high level and low level design activities. I had never seen this described before, but immediately recognized that that is how I work too (as opposed to a straight top-down approach). This too explains why I think you should also keep coding even if you are an architect - because to find the best solution you must alternate between high and low levels of design.
Another good part was their diagnosis of the problems with CMM and ISO9000. They write that both programs have a bias towards documenting and thus standardizing existing process, rather than improving the process, even though it is not the intent of either. I agree completely.
This is a practical book, and there are lots of good (and well described) ideas that can be used in software development. It is well worth getting, both for developers, managers and project leaders. Recommended.
An overly simple book.
The author(s) seem to think that the client should know all about the system they want designing and the designers should be allowed to not know how to do their work! And because of this, the designers should be able to muddle through, make stuff up and then show it to the client to see if it sparks any applause.
How about asking the client what the problem is they want solved, help them (and the designers) to understand it more, consider the other stakeholders (like maintenance and installers), and then move to design.
The author(s) seem to think that the client should know all about the system they want designing and the designers should be allowed to not know how to do their work! And because of this, the designers should be able to muddle through, make stuff up and then show it to the client to see if it sparks any applause.
How about asking the client what the problem is they want solved, help them (and the designers) to understand it more, consider the other stakeholders (like maintenance and installers), and then move to design.
informative
medium-paced
This was good and I’m glad I read it. About halfway through I started to lose interest and just wanted to finish.
challenging
informative
inspiring
medium-paced