Craig Larman and Bas Vodde's new book Scaling Lean & Agile Development is actually the companion book to their forthcoming Practices for Scaling Lean and Agile Development due out later this year. Their first book on this subject focuses less on technical and management practices and far more on key thinking and organizational tools for Scaling Scrum using Lean thinking principles and techniques as the underlying framework.

• First was Ron Crocker's "Grizzly" method which was to be published in Large Scale Agile Development in 2004, but was never completed.
• Then came Jutta Eckstein's Agile in the Large, which dealt with large-projects and teams, but many critics felt it didn't quite scale up to large systems (and systems of systems) or address more enterprise-scale issues
• My favorite thus far has been Dean Leffingwell's Scaling Software Agility, which I felt was the must-read book on the subject when I reviewed it in the May 2007 Agile Journal
• Shortly after came Ken Schwaber's The Enterprise and Scrum, which Liz Barnett reviewed in the October 2007 Agile Journal. It was very Scrum-centric (of course) with enterprise-scale practices for large projects, programs, and portfolio-level management, but had mixed reviews when it came to scaling technical/engineering practices.

Now we have Scaling Lean & Agile Development and following soon after will be not only the follow-up book from Larman and Vodde, but also forthcoming books on leading and scaling Agile development by Mike Cohn (Succeeding with Agile), Alan Shalloway (Scaling Lean and Agile to the Enterprise) and Mary Poppendieck (Leading Lean Software Development).

From the introduction, Larman and Bodde are very clear about what they mean by large-scale:

"We define a large product group as one whose members' names you could not remember if they were all together in a room.  We work typically with single-product groups in the range of 100-500 people that are adopting Scrum, lean principles, and agile development practices, usually on software-intensive embedded systems. So by this definition - at least with our limited memories - this is the realm of ‘large.' "

They then quickly proceed to their first key recommendation regarding large, multi-site, distributed and offshore development: Don't do it! Having said that, they acknowledge the reality that organizations are still going to do this, largely because it is what they are already undertaking, hence the need for this book.

The book is meticulously indexed and replete with comprehensive references and citations (much like Larman's earlier work on Agile/Iterative Development for Managers). The margins are very wide with lots of notes and pointers, and there is typically at least one picture or diagram for every 3-4 pages. The chapters and sections don't just describe something at a high-level and then tell a story. They delve into the nuances and details of the different competing factors at play, and explain how to use their "thinking tools" to come up with viable solutions.  When more than one alternative is conceivable they give insights as to which would be preferable under which conditions. And they typically include a "Things to Try" section near the end of each chapter, with solid nuggets of advice and insight.

The book is structured in to three main parts: Thinking Tools, Organizational Tools, and what amount to an appendix of recommended readings/resources and background material (including a Scrum primer that is also available online at www.scrumprimer.com).

Part 1 (Thinking Tools) is separated into Systems Thinking, Lean Thinking, Queuing Theory, False Dichotomies, and Be Agile (as opposed to just "doing" Agile). Each of these chapters is an outstanding introduction to the corresponding topic, with plenty of details and plenty of references. I found the chapter "Be Agile" particularly insightful for acknowledging that Agile is not merely a particular practice or set of practices to "do", but is more importantly a corresponding set of values and principles to embody in the attempt to "be" Agile:

"Be Agile rather than do agile. ‘Agile' is not a practice.  It is the quality of the organization and its people to be adaptive, responsive, continually learning and evolving - to be agile, with the goal of competitive business success and rapid delivery of economically valuable products and knowledge. One cannot do agile, although it is a common misconception that one can.

... A product group can do Scrum or XP - concrete methods. And they can doagile practices. But they can really only be agile or not. practices that encourage agility -

... Agile does not mean delivering faster. Agile does not mean fewer defects or higher quality. Agile does not mean higher productivity. Agile means agile - the ability to move with quick easy grace, to be nimble and adaptable. To embrace change and become masters of change - to compete through adaptability by being able to change faster than your competition can.

... from a business perspective, the ability to compete and make money with the potential power of lean and agile principles has been squandered by doing agilebeing agile. We encourage those that want to realize enterprise agility to rather than take the time to learn the implications of values such as responding to change over following a plan, and to take the time to discuss and share these insights with others."

Part 2 (Organizational tools) is divided into Feature Teams, Teams, Requirement Areas, Organization, and Large-Scale Scrum. Again, each chapter includes very thorough and comprehensive coverage of its subject matter, complete with meaningful visuals. Those wanting a first-hand look should note that the chapter on Feature Teams is available online, and includes material from the Agile2008 presentation the trouble with components teams and the alternative: feature teams.

There was very little that I didn't like in the book: I thought the discussion of Kanban was perhaps a bit misrepresented (something which was addressed by one of the co-authors publicly on a thread in the kanbandev YahooGroup), and I admit there were a few places where I thought something was either too harshly criticized or too simplistically discussed, but even those were "splitting hairs" is most cases, and not overtly false inaccurate.

My only dilemma here is a reviewer isn't whether or not I highly and enthusiastically recommend this book (I definitely do), but rather whether it is my new "favorite", bumping Leffingwell's Scaling Agility from the top of my current list. I can't do that here because there is enough that is different in the coverage of both books that I would honestly recommend them both as "must-reads" for anyone trying to scale Lean/Agile development.

• Leffingwell's book focuses a bit more on technical practices and how to help adapt Agile into a large organization and project and its structures and overall systems lifecycle;
• whereas I think Larman and Vodde (in this book at least), focus more on the conceptual and organizational transformation rather than adaptation of the practices.

So whereas Leffingwell's book is more about how to adapt Agile to a large-organization (and the mindset change involved), I would say Larman and Vodde focus more on how to adapt the organization to Lean/Agile. Once the companion book from Larman and Vodde hits the shelves, the battle for the "top spot" on my list will begin again in earnest, and will have to include new entries from other Lean/Agile "master heavyweights" like Mike Cohn, Alan Shalloway and Mary Poppendieck.

Until then, Scaling/Lean Agile development is the only game in town when it comes to covering both Lean and Agile for large projects and organizations, and is absolutely a must-read for its coverage of organizational and thinking tools, even though Leffingwell is still my favorite when it comes to introducing the change-in-mindset and adaptation of practices for Agility at scale.

About the Reviewer
Brad Appleton is an enterprise SCM/ALM solution architect for a Fortune 100 technology company. Currently he helps projects and teams adopt and apply agile development & SCM practices. Brad also author's the Agile CM Environments blog, and is co-author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, the "Agile SCM" column in CMCrossroads.com's CM Journal, and is a former section editor for The C++ Report. Since 1987, Brad has extensive experience using, developing, and supporting SCM environments for teams of all shapes and sizes. He holds an M.S. in Software Engineering and a B.S. in Computer Science and Mathematics.

Comments (0)

Write comment

Show/hide comment form