Dean Leffingwell was perhaps first well known as a requirements management guru and author of Managing Software  Requirements. So how did Dean go from being a requirements management guru to being a large-scale agile guru? It's not too big of a leap if you think about it! Someone who knows requirements management has a lot of knowledge and credibility for large-scale systems and software engineering efforts. And applying that knowledge with an agile slant is exactly what he's been doing when working with Rally Software Development these days (the noted Agile consulting services and tool vendor). As part of that experience, he authored a few Agile Whitepapers, an essay on The Essence of Agile (now an excerpt from the book), and a few articles for The Agile Journal, most notably Agile at Scale: 7+7 Practices for Enterprise Agility. Now he has a Scaling Software Agility blog to go with the book.)

So while some might  {sidebar id=1} be skeptical about how a requirements management guru transformed into a large-scale agile guru, it quickly becomes apparent at the end of Part I of the book (chapter 7 "The Essence of Agile" and chapter 8 "The Challenge of Scaling Agile") that Leffingwell not only "gets it" when it comes to Agility and how to scale it, but that he has lived it, intimately, with real-world success and insight to share with the rest of us. In fact one of the best things about the book is how apparent this is, and how well he understands the many organizational barriers at the system- and corporate-levels, both in terms of organizational culture and organizational performance management.

Part I of the book leads of with an introduction to Agile methods from a business perspective, and then dives into the shortcoming of waterfall and the specifics of several agile/iterative methods (XP, Scrum, RUP, Lean, DSDM, FDD), finishing off with the two chapters mentioned previously on the essence of agility and the challenges of scaling it. Part II of the book focuses on the core practices of agile methods that already scale well with little or no effort: dual-level planning (releases and iterations), iteration management, smaller releases, concurrent testing, continuous integration, and regular reflection and adaptation.

Part III of the book is entitled "Creating the Agile Enterprise" and is really the most interesting and illuminating part of the book for those of us who have a good grasp on agility and are struggling how to scale it up to large systems and corporations. Leffingwell deftly and insightfully addresses the issues of "Lean" requirements (chapter 17) and architecture (chapter 16), introducing what he calls "intentional architecture," and criticizing those who would suggest that refactoring and "emergent" design can scale without more up-front effort early on. Chapter 18 discusses systems of systems and releases of releases, illustrating how component teams and release management scale when you are beyond the size of merely "teams of teams." Hot on its heels is chapter 19, which discusses highly distributed development and the notion of "shuttling" along with other communication-scaling lessons and pitfalls (and a case study or two).

Chapters 20-22 deal with perhaps some of the more fundamental issues of scaling agility that aren't often addressed in earlier books on the subject: impacts on not just customers, but also operations; organizational change at the enterprise-level; and measuring business performance with an "Agile" scorecard-based approach.

Throughout the book there are examples and case studies, along with planning examples and checklists, and useful tables and diagrams that distill the essence of the particular section or chapter. About the only criticisms I have are that some will want more "How To" depth and detail, particularly in the coverage of organizational issues. Others may feel the emphasis on component teams rather than feature teams to be a point of contention, and take issue with some of the approach to "intentional architecture."

But anyone trying to scale agile development beyond a single large team, to a large company or enterprise consisting of hundreds of people across multiple departments, projects, and systems, needs to run (don't walk) and get this book, and then read it cover-to-cover!

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