Mary and Tom Poppendieck summarize the objective of the “Lean Mindset” book in the introduction: “we present a mental model of how to design and deliver amazing products that delight customers”. Following the same idea that you should “be Agile” and not only “do Agile”, the book explains how to build the mental model to act in a lean way, discussing the creation of a favorable environment and process to deliver value to the customer.
You should not however think that the book presents only conceptual content that has little practical value. It is full of case studies and presentations that illustrate the lean concepts in practice. My favorite presentation is the nine pages’ description of the Spotify product building process written by Henrik Kniberg. The innovation checklist presented in the book is also very interesting. This book is well written an easy to read. The content of Lean Mindset provides a great combination of conceptual and practical material to help you think about your software development process, and not only if you are following an Agile or Scrum approach. This book is valuable for every software developer that want to shift from a “building the things right” to a “building the right things” way of working.
Reference: “The Lean Mindset: Ask the Right Questions”, Mary and Tom Poppendieck, Addison-Wesley, 180 pages, IBSN 978-0321896902
Quotes
Great problem solvers start by developing a deep understanding of the situation through direct experience. They collaborate with people who have different perspectives and knowledge. They are creative, efficient, and highly disciplined in uncovering the essential problems and designing possible solutions. They test multiple ideas and focus on learning as much as they can. They ask a lot of questions and challenge assumptions, even their own assumptions. They regularly step back and reframe the situation to be sure they are solving the right problem.
Product development isn’t easy. In fact, most product development efforts fail, and the most common reason for failure is building the wrong product.
Asking software developers to write more code is like asking authors to put more words in their books or teachers to put more children in their classrooms. When creativity and learning are important, focusing on quantity makes no sense. And yet in one of the most creative, learning-focused professions we know of -software development – the question we get most often is How will lean or agile methods increase productivity? Quite frankly, that is the wrong question.
The path to effective software development is not increasing productivity; it is developing the essential features that customers will love – and only those features. The more features you add to a code base, the more complexity you add with it. The more complexity you add, the more difficult and expensive the code base is to change. In more cases than you can imagine, the features and the complexity are not really necessary. So the best attitude to adopt is that lines of code are bad. Function points are bad. Even stories and features are bad. Instead of worrying about how to develop stuff faster, it is far better to learn how to stop developing the things that are not important and focus on the things that will have real impact.
Delivery teams operate under a significant handicap. They are chartered to implement someone else’s solutions to problems that team members are not expected to understand. They deliver these solutions without assuming responsibility – or receiving credit – for the resulting business improvements. Even when agile practices speed up delivery, feedback loops are lengthy and plagued with handovers. Therefore, it is a challenge for delivery teams to find a purpose, generate enthusiasm, or spark innovation. So it should not be a surprise when these teams deliver mediocre business results.