Practices for Scaling Lean & Agile Development
Increasingly, large product-development organizations are turning to lean thinking, agile principles and practices, and large-scale Scrum to sustainably and quickly deliver value and innovation. Drawing on their long experience leading and guiding lean and agile adoptions for large, multisite, and offshore product development, internationally recognized consultant and best-selling author Craig Larman and former leader of the agile transformation at Nokia Networks Bas Vodde share the key action tools needed for success.
Coverage includes:
- Frameworks for large-scale Scrum for multihundred-person product groups
- Testing and building quality in
- Product management and the end of the “contract game” between business and R&D
- Envisioning a large release, and planning for multiteam development
- Low-quality legacy code: why it’s created, and how to stop it
- Continuous integration in a large multisite context
- Agile architecting
- Multisite or offshore development
- Contracts and outsourced development
In a competitive environment that demands ever-faster cycle times and greater innovation, the practices inspired by lean thinking and agile principles are ever-more relevant. Practices for Scaling Lean & Agile Development will help people realize a lean enterprise—and deliver on the significant benefits of agility.

Review By: Harry Acosta
12/27/2010This is the best practical agile and Scrum book I have read. The agile and Scrum methodologies are written about in a clear, concise, and instructive manner so that anybody working in any project role,
regardless of methodology being used, can understand and apply its principles in some way. All agile- and Scrum-specific speak is explained in very simple terms and supported throughout the book
with a lot of figures and tables. I absolutely love the way that the book is written in practical terms, without having to dig into long, small letter paragraphs to get practical suggestions on what to do or warnings on what not to do. These suggestions or warnings appear throughout the book as paragraph headers labeled "Try … or Avoid …." This presentation format of the subject matter alone is an excellent time saver when looking for advice through six hundred page book.
One thing I missed in this book is end-of-chapter practice exercises or questions. Maybe I'm just used to these sections being in textbooks or maybe because of the book’s focus on development, where agile and Scrum provide the best value. End-chapter practice questions could add value to the reader especially if the reader is planning to take the ScrumMaster certification exam. Another thing I missed from this book, at least for us PMPs or who are planning to take the PMP exam, was discussion on similarities or differences between agile and the PMI’s Project Management Body of Knowledge.
I work in the highly-regulated and waterfall-structured pharmaceutical, biotech, and medical device industry where software implementation projects have rigid documentation and testing requirements. Therefore, I have not yet had the opportunity to apply agile methodologies to my everyday projects. However, after reading this book, I found that there are more than a just a few ideas that I can easily adapt to my current process.
My typical work focus is usually on the testing and the requirements processes, so my favorite chapters were related to these topics. Chapter three, titled “Test,” the book clearly demonstrates the added value of NOT following some of the usual processes such as avoiding commercial testing tools, using defect tracking systems during the iteration, avoiding a separate test team, or doing workshops without computers or projectors. The authors make a lot of sense. His ideas are worth trying out in a non-agile methodology process.
In chapter seven, "Requirements & PBIs" (product backlog items), the authors provide excellent advice to business analysts and project managers so that the final project deliverables are more closely aligned with the actual customer requirements, even if agile is not the methodology being used in a project. Chapter twelve, "Multisite," and chapter thirteen, "Offshore," the authors provide sound advice when dealing with virtual teams located in remote locations or different countries.
Finally, chapter fourteen, "Contracts," the authors delve into establishing the legal foundation of a project contract, which should benefit all parties as well as the project timelines. Hardcore waterfall project managers and quality team members will cringe at the idea of avoiding a quality management plan and deliverables list, but the rationale explained by the authors does make sense.
It certainly will take a while for the waterfall mindset to switch to agile but this book is an excellent first step.