Take a photo of a barcode or cover
A review by redcover99
Lean Software Development: An Agile Toolkit by Tom Poppendieck, Mary Poppendieck, Jim Highsmith, Ken Schwaber
5.0
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