#2782

Book Review of Scaling Lean & Agile Development

While supposedly on vacation and sitting on a beach in Jamaica I finally got around to reading a couple of books that haven’t quite made it to the top of the stack. This is largely thanks to the lack of slack and impending annual performance reviews. More on that later…

In the meantime what of Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum?

It turns out this wasn’t quite what I was expecting. Which, in this case, is a good thing. Much of the nuts and bolts of large-scale development will be covered in an—as yet unpublished—companion volume; “Practices for Scaling Lean & Agile Development: Large, Multisite and Offshore Product Development with Large-Scale Scrum”.

Why is this a good thing? Well, the second volume will focus on the nuts and bolts and the temptation would for many potential readers—myself included—to skip the theory and go straight to the applied. A bad idea when the central theme of the first volume is that large-scale agile adoption has effects throughout the organization. The development team and day-to-day development activities are just the tip of the iceberg.

The first section of the book focuses on thinking tools; Systems Thinking, Lean Thinking, Queueing Theory. Which is typical of the book’s approach of giving the readers the tools to “Be agile rather than do agile”. This makes a lot of sense. Large organizations are complex and unique, attempting to author a one size fits all recipe for agile adoption would seem unwise. But if you’re expecting a book containing a prescriptive set of recipes then you’ll be disappointed.

The second section covers the organizational tools starting off with Feature Teams and the inherent problems with component teams. The discussion expands to cover many other topics; building teams in place of managing resource pools, rewarding teams as opposed to individuals, a Beyond Budgets approach rather than a conventional annual budgeting approach. All these come into play when managing large scale organizational change to a more agile approach.

It’s only in the last chapter that the authors put it all together and discuss two example Scrum Frameworks for large organizations. They also go to great lengths not to be prescriptive with “Try…” and “Avoid…” sections replacing “Do…” and “Don’t…”. Much of the details will be covered in the companion book.

There’s a lot of material presented here and it leaves the reader with the somewhat daunting task of figuring out how to turn their organization inside out. Especially when considering something the size of Microsoft’s Developer Division (of which p&p is part).  There are some possible reasons for this:

• There’s an inflection point at some size/complexity scale where this approach breaks down.
• Visual Studio’s huge legacy, architecture, code base and long established engineering culture needs more change than I can imagine in order to map it onto the full Feature Team approach they describe (I’m not very imaginative).
• The road from were we are today and the approach Bas and Craig describe is longer than I’m prepared to accept.

In some respects much of what we tried to do in Visual Studio Tools for Office 2008 maps onto their Product, Product Area and Feature Teams approach and we had moderate successes. I’ll be giving my well-thumbed to various people in the Division’s engineering team and see what they think. It’s full of good ideas and definitely worth reading I’m waiting for volume 2.

As an aside, an immediate takeaway was that learning organizations need slack and suffer without it and annual performance reviews have more negative impacts than positive ones. I held both of these things to be true already but the authors back them up with extensive discussion and references. Something to think about on the beach.

Disclaimer: I spoke with Bas at Agile 2008 and gave the authors feedback on the Feature Teams chapter. They were kind enough to send me a copy of the book. Which I finally got around to reading.