Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
If you are looking for a book that discusses why it is more important to be agile than to do agile, this book is for you! Scaling Lean & Agile Development covers both the theory that supports Lean and Agile thinking along with practical advice on what to “try…” and “avoid…”
It is difficult to justice to a comprehensive book in a short review, but Larman and Vodde did an excellent job of combining their experience with extensive research to provide a comprehensive look at why Lean and Agile works and what it takes to change.
For example, thinking that Lean and Agile is only for developers, “…leads to no real change and no real result, and the eventual predictable abandonment of lean principles or agile development because ‘that doesn’t work.’” In fact, “it is vital to appreciate that organizational agility cannot be achieved by a development team in isolation—it is a system challenge for organizational redesign.”
Larman and Vodde go on to explain: “If an engineering team has the technical capacity to adapt or change quickly, but requirements management, legal practices, product management, HR policies, site strategies, and deployment processes all emphasize rigidity, conformance to original plans, conformance to the status quo, and slow practices, then how can there be real agility?”
Agile teams surrounded by a non-agile organization are going to face challenges, without a doubt. I really took a liking to one observation that Larman and Vodde made: “’Agile’ is not a practice. It is a 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.”
This means that Lean and agile thinking goes deeper that tools or techniques, or the elimination of waste; “As can been seen at Toyota, it is an enterprise system resting on the foundation of manager-teachers in lean thinking, with the pillars of respect for people and continuous improvement. Its successful introduction will take years and requires widespread education and coaching.”
And it will take years. We have a variety of deep-rooted behaviors and expectations to change. For example, consider the expectations many companies have around tools and reports, with managers and executives running companies from conference rooms. Larman and Vodde address how this needs to change in a Lean and agile culture:
“In a lean-thinking culture, all people, but especially managers—including senior managers—should not spend all their time in separate offices or meeting rooms, receiving information via reports, computers, management reporting tools, and status meetings. Rather, to know what is going on and help improve (by eliminating the distortion that comes from indirect information), management should frequently go to the place of real work and see and understand for themselves.”
And what about some of those agile tools that are out there? Larman and Vodde have this to say: “Tools—including most ‘agile tools’—are optimized for reporting rather than for real value work. Developers or POs find the tool awkward and report that it slows them down, but senior management see the reports they want—and obvious sub-optimization. Notice that such tools may inhibit the lean Go See practice.” – Enough said!
Moving on, another excellent piece of advice Scaling Lean & Agile Development offers concerns how to respond when dealing with the complexities and challenges of software development in a Lean and agile way: “Do not increase multitasking, or utilization rates to create the illusion that queues have been reduced and the system has improved; rather, improve the system so that the bottlenecks and other forces that create queues are removed.”
Increasing utilization is a common management tactic, but as Larman and Vodde point out, ”As utilization goes up in a system with lots of variability, average cycle time gets worse, not better.” This is because, “Resource management strategies that focus on high utilization of workers—a focus on watch the runners rather than watch the baton—create an environment in which people will create a large inventory of things (requirements, designs, code) in a push model.” Definitely NOT the way to go when applying Lean and agile thinking!
Other challenges – as the name of the book implies – deals with scaling Lean and agile development. One approach Larman and Vodde recommend is to, “Structure the product group primarily by requirement areas and related Scrum feature teams—a Requirement Area unit. Each unit has a requirement area manager whom the feature teams “report to.” His (or her) prime role is to support the new feature teams that join the area. He will probably also have work stemming from organizational policies such as budgeting, performance appraisals, and so forth.”
Granted, there are trade-offs associated with this approach, and the book discusses those as well. Another interesting challenge Scaling Lean & Agile Development tackles is with product portfolio management. The challenge is that, “Coarse-grained product prioritization leads to local optimization in which the low-priority items of a high-priority product are implemented instead of the essential items of a lower-priority product.”
“Merge the Product Backlogs of different products into one Product Backlog for the whole company. The CEO acted as the Product Owner. When the organization has one Product Backlog and one Product Owner for the whole company, then the prioritization aspect of portfolio management and prioritizing the Scrum Product Backlog are the same activity. However, it is now done on the feature level—avoiding the previous local optimization.”
In closing, I found this book to be well-written, full of insight, advice and research that makes Scaling Lean & Agile Development something that every Lean and agile practitioner should have on their bookshelf (or Kindle library).