As Agile and Scrum are adopted by an increasing number of companies, “Thinking Tools for Large-Scale Scrum” from Craig Larman and Bas Vodde provides important thinking tools to remind us that it is more important to “be agile” than to “do agile”. Scrum or Lean are frameworks that we can use for continuous improvement of our software development process and not tools that should be applied blindly like cooking recipes.
The first part of the book discusses Systems and Lean Thinking, along with the concept of false dichotomies. A false dichotomy is an artificial argument that considers a situation with only two alternatives. They explain that Scrum and XP requires a high level of discipline or agility will not be attained or maintained. If you are looking for practical advice, you should not think that this book remains only at the conceptual level. It contains many “try…” and “avoid…” recommendations that will help you implement agile and lean ideas in your organization, if you remember that best practices are only valid in certain contexts. The second part of the book is dedicated to organizational tools and the final chapter proposes frameworks to adapt Scrum to larger contexts.
If you believe that software development project management goes beyond the simple application of “silver bullet” recipes, then you should absolutely read this book. It is a rich source of both thinking and practical content for scaling Agile and Scrum that is well suited for non-linear reading. A very good “Scrum primer” chapter at the end of the book will provide an introduction for those who are not familiar with this approach, and a large number of “recommended readings” items will allow readers to explore more in details each concept.
Reference: “Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum”, Craig Larman & Bas Vodde, Addison -Wesley
Quote
“After working for some years in the domains of large, multisite, and offshore development, we have distilled our experience and advice down to the following: Don’t’ do it. There are better ways to build large systems than with many developers in many places. Rather, build a small group of great developers and other talents that can work well together in teams, pay them well, and keep them together in one place with product management or whoever acts as the voice of the customer”.”