Customer Reviews

Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum

5 star:		(13)
4 star:		(2)
3 star:		(3)
2 star:		(0)
1 star:		(0)

 

 

This book is a classic example of the fact that it is better to teach somebody to fish than to give him fish. It emphasizes that it is important to "be agile" more than to "do agile". Approaches like Scrum or Lean are more frameworks to think about continuous improvement than tools that should be applied blindly like cooking recipes. The book will therefore tell you that "large-scale Scrum is Scrum" or that lean is not just kanban or waste reduction. The first part of the book is focused on thinking tools (systems thinking, lean thinking, queueing theory) that are presented with software project management related examples. Those who are looking for practical advice should not believe that the book remains only at the conceptual level. The authors distill many "try..." and "avoid..." recommendations that will help you implement agile and lean ideas in your organization. The second part of the book is devoted to organizational tools and the final chapter proposes frameworks to adapt Scrum to larger contexts.

This book is a must for those who believe that software development project management goes beyond the simple application of "silver bullet" recipes. It is a rich source of both thinking and practical content that is well suited for non-linear reading. A very good "Scrum primer" chapter at the end of the book will provide an introduction for those who are not familiar with this approach and a large number of "recommended readings" items will allow readers to explore more in details each concept.

Listening to Bas Vodde's speech about "the trouble with component teams" at the Stockholm Scrum Gathering 2008, I was amazed. From the participants' reactions, you could easily hear and see when someone recognized his or her own project: The troubles he described seemed too familiar. Yet most real big software development organization seems to be facing them, even on their way to getting agile, if the development teams are still organized according to architectural components. He also could explain with a really practical background why and how these problems would be solved by having agile cross-functional feature teams. These insights can be found with much more detail in the "Feature Teams" chapter of this wonderful book.

Craig Larman and Bas Vodde have put together lots of valuable background information on lean thinking applied to software projects. The book describes how agility is based in the Toyota values and principles, as well as in systems thinking and queuing theory. But it is far away from being a theoretical book, since it contains lots of practical experiences from the authors and other people introducing Scrum into large organizations. A big emphasis is on understanding that the pillars of lean are "Respect for people" and "Continuous improvement" and that the lean principles and the methods with which they are supported will not work alone, without the rest of the framework. As well as you cannot "do agile" but only "be agile". These are things frequently misunderstood, especially in large companies. Suddenly you are invited to dozens of daily "Scrum" standup meetings held by managers who have heard that daily standups make you agile.

A chapter I particularly like is the "Organization" chapter. How can you form an organization around agile development teams? How should the product development organization above the teams be? What needs to be changed in the other departments? What happens to phases and milestones? How will the HR strategies be adapted, how will budgeting work? - Very valuable also the top ten organizational impediments they and other agile development experts found, e.g. "considering learning a waste of time and money". You do not get all the answers, yet many, and the right questions.

In few words: A lot of helpful insights and tools that you estimate if you want to do a successful agile transition. Lots of thanks to Bas and Craig! - I am looking forward to the announced companion book "Practices for Scaling Lean and Agile".

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.

Read more about distributed and large scale agile on my blog: [...]

"Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum" is the first of two books co-authored by the same duo. This first volume covers the underlying theory needed for understanding the dynamics of scaling agile development to large organizations, including one of the best introductions to Systems Thinking that I remember reading.

Indeed, the first part of this book is all about thinking tools such as Systems Thinking, Lean Thinking, and Queuing Theory. Throughout the book, the authors refer back to these theories when they try to illuminate the "what" and "why" of various dynamics.

The second part focuses more concretely on how to scale a product development organization. It starts with a thorough, seminal chapter on Feature Teams and continues with more general discussion of what makes teams work. True to their style of writing, these chapters are full of references to related research. Knowing the authors, I expected nothing less. After team work, the authors move on to discussing a scaling technique called "Requirement Areas", specialization, organizational impediments, even budgeting and HR.

The third and last part of the book is essentially an appendix containing the "Scrum Primer" by Gabrielle Benefield and Pete Deemer. Personally, I think this appendix could've been left out, considering that most readers should already be familiar with Scrum.

Again, this book is perhaps the most thoroughly researched text on agile development I've read (and I've read most of them) and the authors clearly know what they're talking about. Having said that, it is also quite a heavy read considering that it's only some 300+ pages. I read it in one day, barely leaving the couch but I can imagine that others might not enjoy the theory-heavy approach as much.

With that said, while it's not full of the kind of concrete tips we'd like to see, this book does offer a strong foundation for understanding how to scale and how not to scale up organizations for agile development. I highly recommend it to leaders, change agents and agile coaches involved in large-scale transitions.

I am a big fan of Craig's books. I was looking for a book like this from some time covering all aspects of software development.This book provides a holistic view of doing software development applying Lean, Systems thinking, Queuing theory, Scrum, etc. While going through the book, it becomes pretty clear that improving productivity, reducing defect count, improving the quality cannot be done just by improving the software development process, but through the organizational change and commitment. This book also coaches on applying the right method and thinking tool at the right level in the organization. I would highly recommend this book to everyone involved in software industry.

Congratulations to Bas and Craig. They have pulled together ways of thinking about product development and lessons learned into a well-structured, intelligently presented book. When we started using Scrum, there was plenty of opportunity for floundering as we tried to think our way out of paradoxes, problems, and old habits. This book offers an insightful reader and Scrum user a way to learn from others and to prepare themselves to take on the really hard work.
Thanks to Bas and Craig,
Ken

I found this book a bit hard to read - I don't know if it is because it was written by two authors, or because I didn't know about Lean Thinking. Nevertheless, I strongly recommend it for anyone who wants to know why Scrum works and how to use it. It relates Scrum to Lean Thinking all over the book (this came as a surprise for me), includes real cases from several industries and clearly avoids dogmatism.

This book is great at illustrating just how complementary lean and agile practices are. It's particularly effective at re-iterating how to make use of lean and agile thinking...if you read this book you will remember it's key messages. Whilst the sub-title talks to large-scale organisations, this book is applicable to agile at any scale.

I loved it and openly recommend it to all.

This is a fantastic book to help with the issues of taking scrum/agile/lean/xp from a small software development team into a much larger scale product development effort. The depth of knowledge and experience of the authors demonstrated by the fact that they don't give any silver bullets, but describe tools for dealing with complexity of scaling.

The first half of the book on Thinking tools is well considered and useful. Most of it isn't a surprise to me, but the section is well written and distills the fundamentals of systems thinking, lean thinking, queuing theory, false dichotomies and being agile very well. These thinking tools are used to help the reader understand the concepts in the second part of the book on Organisational tools.

Organisational tools is fantastic, covering Feature teams, Teams, Requirement areas, Organisation, and Large-scale Scrum. Using experience and the thinking tools Larman & Vodde describe why you would adopt these tools to help scale. I regularly did the "d'oh, it's so obvious when you put it like that" forehead slap reading this section of the book.

Recommended reading and references are a great stepping off point for more specific coverage of topics in the book.

The book is a must read for anyone looking to scale agile product development.

This book contains a significant amount of useful information. I liked the idea of providing those ideas in the form of things to try, experiments. See what works for you in your context. Doesn't work? Try something else. There are also a number of things that have been tried and found to not be useful.

So why the so-so rating? It's only half the story that's being told. To often in the text we find the phrase "Explored in the companion book" or "Tips are found in the companion text". Seeing this my peers and superiors just dismissed the whole effort as incomplete. They now have gone looking for other sources. Six months on from publication and still no indication of when the rest of the story gets told.

Which is too bad. I think they've got a lot of it right.