Adapting agile practices to your development organization Uncovering and eradicating waste throughout the software development lifecycle Practical techniques for every development manager, project manager, and technical leader Lean software development: applying agile principles to your organization
In Lean Software Development, Mary and Tom Poppendieck identify seven fundamental lean principles, adapt them for the world of software development, and show how they can serve as the foundation for agile development approaches that work. Along the way, they introduce 22 thinking tools that can help you customize the right agile practices for any environment.
Better, cheaper, faster software development. You can have all three-if you adopt the same lean principles that have already revolutionized manufacturing, logistics and product development.
Iterating towards excellence: software development as an exercise in discovery Managing uncertainty: decide as late as possible by building change into the system. Compressing the value stream: rapid development, feedback, and improvement Empowering teams and individuals without compromising coordination Software with integrity: promoting coherence, usability, fitness, maintainability, and adaptability How to see the whole-even when your developers are scattered across multiple locations and contractors Simply put, Lean Software Development helps you refocus development on value, flow, and people-so you can achieve breakthrough quality, savings, speed, and business alignment.
What I love about the book Lean Software Development by Mary and Tom Poppendieck is that even it's subtitle is Agile Toolkit, it isn't a such a toolkit that offers ready made solutions. I've never believed this one size fits all thinking which is sometimes pushed with Scrum and Kanban literature and this is refreshing exception to that thinking. This one offers explanations why things tend to go in some ways and what are the user or organizational problems these tools are trying to solve.
I'm actually pleased that I didn't read this when I was a fresh starter with Agile and Lean. I somehow feel the book would have been bit too much on that time. This book really encourages to see the whole and understand the underlying causalities between different parts of SW development. For that reason it was good that I had experience on many different levels and layers of Agile and Lean SW development to be able to reflect the lessons in the book to real life situations.
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
Nice, concise overview of Lean in relation to software development. Lean is an agile management philosophy derived mostly from the Toyota Production System.
I didn't know anything about lean but stumbled upon it while researching scrum (another agile management philosophy). Now I know about lean and like it very much. Some lean principles overlap scrum principles and practices while others extend them. Ideal to reflect on scrum and agile from a different perspective.
Every chapter discusses one of the lean principles and provides hands on tools to get started. The lean principles are: - Eliminate waste - Amplify learning - Decide as late as possible - Deliver as fast as possible - Empower the team - Build integrity in - See the whole
What I did not like was the final chapter about the principles 'See the whole'. There is a short mention about system thinking and the rest of the chapter is basically about agile contracts. While agile approaches to contracts are worth the read, I would have liked a bit more insight in the concept of system thinking. On the other, it provides me with an opportunity to look for a nice primer on system thinking.
Highly recommended if you want to learn about lean, agile, modern project management, leading and motivating teams or reviewing and extending your scrum practices, even if you are not directly interested in the software development part of the story.
All project managers and technical leaders should memorize the principles referred in this book
The book is must for project managers, technical leaders and everyone that has any intention of influence the software development process or the interaction with the client. Main benefit for me it that it takes the discussion of project-level practices and explain the importance and the 'why's of those practices in a way that touches the mindset of high-level managers, directors, and even maybe the executive level of organizations.
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.
Lean Software Development takes inspiration from the manufacturing-oriented Lean Principles and proposes an approach to make use of them in software development. Ideas such as eliminating waste, amplifying feedback, delaying commitment, delivering fast, systems thinking, respect for people and built-in quality are the linchpins of it.
I would have read other books in the past, most notably from Don Reinertsen, so when I came across Lean Software Development I was delighted to see that many concepts that Reinertsen teaches are also explained in here, albeit at a much higher level and perhaps easier to understand.
Alas, this book was written back in 2003 and some of content is slightly out of date (like for instance, suggesting the use of source control when nowadays Git is king). It is because of that reason I'm giving it 4 stars. Otherwise, it is still probably the best introduction to Lean applied to software development I ever came across.
Solid agile fundamentals plus lot of anecdotes from other fields (other than software development).
Here are seven simple rules from this book:
Eliminate waste: Spend time only on what adds real customer value. Amplify learning: When you have tough problems, increase feedback. Decide as late as possible: Keep your options open as long as practical, but no longer. Deliver as fast as possible: Deliver value to customers as soon as they ask for it. Empower the team: Let the people who add value use their full potential. Build integrity in: Don't try to tack on integrity after the fact—build it in. See the whole: Beware of the temptation to optimise parts at the expense of the whole.
I found this book very interesting since the first few pages I read. Then I flipped through the book and I was convinced.
Book contains 22 ways to improve software development practices. Each practice is explained thoroughly and most of them are highlighted with examples. Because lean principles are widely used in other industries, continuous improvement and holistic view is explained in wider perspective. Examples from car design and manufacturing reflect nicely to software projects.
At the end of each chapter there is try this section. It offers questions and new ways to evaluate your current practices. This is a great way to reflect your current situation and a good collection of topics to raise discussion.
Final chapter in the book offers an excellent wrap up. It repeats everything explained earlier and adds few additional insights.
There is one drawback. Book was published 2002 and later edition could give better references to the most recent development in the industry. However, all lean principles explained in the book are still valid. Writers were a lot ahead of their time when they wrote this book.
This is a somewhat poorly written and badly edited book intended to provide the basic grounding in so called "agile" processes for software development. While some of the basic ideas are sound, they are poorly presented, with a lot of repeated material and laboured examples. The whole book is based on an assumed model for a software project that is only narrowly applicable to real development. There is no help in applying the principles outside of the confines of a small single customer product focused team.
An amazing survey of concepts related to agile software development. But not merely a survey - it ties it all together in a way that reveals the interconnectedness of all these different ideas. I gained a much deeper appreciation of the deepest principles of system thinking, organizational psychology, and software quality. The "Try This" sections at the end of each chapter are extremely practical. They serve as my personal coach in my efforts to improve.
This is probably the best book on management of software development that I have read so far. I appreciate that Poppendiecks propagate the principles and certain mind-set and not some specific methods for agile development. The best of all, I see from my own work that many of these principles do work if properly followed and communicated to the rest of the team and to the clients.
Examples from the lean production are not always very illuminating, yet sometimes provoke interesting analogies.
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 Lean Software Development, Mary and Tom Poppendieck identify seven fundamental "lean" principles, adapt them to the world of software development, and show how they can serve as the foundation for agile development approaches that work.
Along the way, they introduce 22 "thinking tools" that can help you customize the right agile practices for any environment.
Better, cheaper, faster software development - you can have all three if you adopt the same lean principles that have already revolutionized manufacturing, logistics, and product development.
Lean Software Development shows software professionals how to achieve breakthrough quality, savings, speed, and business value by adapting the seven lean principles that have already revolutionized manufacturing and R&D. Drawing on 25+ years of experience leading enterprise projects, the authors show how to use these principles to create agile processes that work - because they're optimized for your environment.
The development of Agile software requires innovation and responsiveness, based on generating and sharing knowledge within a development team and with the customer. Agile software developers draw on the strengths of customers, users, and developers, finding just enough processes to balance quality and agility.
People using agile processes can refer to the 22 tools that Mary and Tom describe to understand why and how the most common agile processes work or to construct their own agile process.
Some key insights and learnings from the book include:
- The importance of understanding customer value and using it as a guiding principle for all development activities.
- The importance of eliminating waste, such as overproduction, waiting, defects, over processing, over-engineering, unnecessary motion, and unused talent.
- The importance of building quality into the process from the start, through practices such as test-driven development and continuous integration.
- The importance of continuous improvement and the use of techniques such as kaizen to drive change.
- The importance of flow and how to optimize flow through techniques such as Kanban and pull systems.
- The importance of understanding and managing variability, and how to use techniques such as statistical process control to improve predictability and reduce risk.
- The importance of building a culture of experimentation and learning, where teams are empowered to experiment, learn, and make decisions based on data.
The book emphasizes that Lean principles are not only beneficial to the software development process but also improve the overall business performance by delivering more customer value, faster and with less waste.
In conclusion, Lean Software Development by Mary Poppendieck and Tom Poppendieck is a game-changing book that shows how Lean principles can be applied to the software development process to deliver more value, faster, and with less waste.
By reading this book, you'll learn how to focus on the customer, eliminate waste, build quality in, optimize flow, manage variability and create a culture of experimentation and learning.
It's a must-read for anyone looking to improve their software development process, and it's not just limited to software development, it's a valuable guide for any business looking to improve its overall performance.
An interesting book, that is not only a tool kit, but comes with many examples from the real world that help illustrate their points. Despite being almost 20 years old, the information and guidance doesn’t appear overly dated. It's overview of how the Toyota Production System influenced both the Lean Software movement, and changed the game in the automotive industry is insightful, and has inspired future reading.
The one lesson that really stuck out for me was using cost benefit analysis to help guide a project, by putting a forecasted P&L sheet directly in front of the development team so that features could be prioritised, removed, and added, based upon very tangible financial results making these decisions easy. The final chapter that discusses contracts is very useful as it shows many types, different to the traditional fixed price and time and materials variations.
A good book, that will definitely require a re read many times over, and in specific sections, to apply the principles.
I took this book in order to better understand how to be productive in my day to day activities at work - this book is not for that. Although I think after reading it, most developers would gain some additional insight on how to be more productive (or maybe just be more at peace with agile & co.), this book is for managers that strive to create the best environment for continuous delivery and costumer satisfaction. The best feature of this book is that it relates core lean values to the software development process. It gives more clarity on the `why` instead just `how`. Recommended.
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.
An amazing book from Mary Poppendieck one of Agile Alliance founders, she has led teams implementing solutions ranging from enterprise supply chain management to digital media, she built one of 3M's first Just-in-Time lean production systems. Book helps to understand JIT in manufacturing and how to map it to software industry throw agile. I really enjoy, more at least than PMBOK the other book I read this year. It talks the importance to amplify learning, eliminate waste & empower the team, this tree concept used properly are super powerful to transform and iterate success in R&D.
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.
I finally have got the chance to finish the book that altered the agile part of the IT!
Although if you are familiar with Lean from conferences, workshops and/or company, you might find many of these ideas obvious. On the other hand (like me) you might want to read the source of the Lean in software dev, which gives a nice perspective.
I enjoyed the book a lot and still got several lessons out of it.
This strenght of this book is that it is able to translate lean/agile theory in some real practical tools you can apply if you're involved in product development. The tools provided are no checklist you need to follow blindly, but they give you some direction and inspiration on how to make your product better, make your customers & team members happier. Next to that, in contains some real life examples showing one way on how the tools can be applied in practice. Recommended read !
Probably would give it 4.5 stars, but much of the teachings are in place fairly well where I work. Excellent foundational book about developing software using a lean approach. Also contains good examples of the history of lean in the Toyota Production System.
Really interesting book with a lot of new knowledge (for me) about the analogies between manufacturing and software engineering. It is more an abstract high-level set of principles than actually a structured process. It works really well with existing agile practices (Scrum, XP) and improves them.
Excellent book on agile principles and thoughts on how to implement them into your organization. The book really shows the Poppendiecks grasp on the topic. Looking forward to the other books by the authors.
A great reminder about the origins of Agile software practices and how lean fits into the big picture. Despite, or maybe because its age, it feels like a refreshing view on a more productive way to develop software.
This book expalins agile software development practices from different aspect and explain with examples. Really worth the time spent on reading it. Recommended for leaders who wanted to implement agile software development practices.
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.