Start reading Scaling Lean & Agile Development on the free Kindle Reading App or on your Kindle in under a minute. Don't have a Kindle? Get your Kindle here.
Programming Books C Java PHP Python Learn more Browse Programming Books

Deliver to your Kindle or other device

Enter a promotion code
or gift card

Try it free

Sample the beginning of this book for free

Deliver to your Kindle or other device

Sorry, this item is not available in
Image not available for
Image not available

To view this video download Flash Player


Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum [Kindle Edition]

Craig Larman , Bas Vodde
4.5 out of 5 stars  See all reviews (24 customer reviews)

Digital List Price: $47.99 What's this?
Print List Price: $59.99
Kindle Price: $27.49
You Save: $32.50 (54%)

Free Kindle Reading App Anybody can read Kindle books—even without a Kindle device—with the FREE Kindle app for smartphones, tablets and computers.

To get the free app, enter your email address or mobile phone number.


Amazon Price New from Used from
Kindle Edition $27.49  
Paperback $44.18  
Shop the new
New! Introducing the, a hub for Software Developers and Architects, Networking Administrators, TPMs, and other technology professionals to find highly-rated and highly-relevant career resources. Shop books on programming and big data, or read this week's blog posts by authors and thought-leaders in the tech industry. > Shop now

Book Description

Lean Development and Agile Methods for Large-Scale Products: Key Thinking and Organizational Tools for Sustainable Competitive Success


Increasingly, large product-development organizations are turning to lean thinking, agile principles and practices, and large-scale Scrum to sustainably and quickly deliver value and innovation. However, many groups have floundered in their practice-oriented adoptions. Why? Because without a deeper understanding of the thinking tools and profound organizational redesign needed, it is as though casting seeds on to an infertile field. Now, drawing on their long experience leading and guiding large-scale lean and agile adoptions for large, multisite, and offshore product development, and drawing on the best research for great team-based agile organizations, internationally recognized consultant and best-selling author Craig Larman and former leader of the agile transformation at Nokia Networks Bas Vodde share the key thinking and organizational tools needed to plant the seeds of product development success in a fertile lean and agile enterprise.


Coverage includes  

  • Lean thinking and development combined with agile practices and methods
  • Systems thinking
  • Queuing theory and large-scale development processes
  • Moving from single-function and component teams to stable cross-functional cross-component Scrum feature teams with end-to-end responsibility for features
  • Organizational redesign to a lean and agile enterprise that delivers value fast
  • Large-scale Scrum for multi-hundred-person product groups

In a competitive environment that demands ever-faster cycle times and greater innovation, applied lean thinking and agile principles are becoming an urgent priority. Scaling Lean & Agile Development will help leaders create the foundation for their lean enterprise—and deliver on the significant benefits of agility.


In addition to the foundation tools in this text, see the companion book Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum for complementary action tools.

Editorial Reviews

About the Author

Craig Larman is a management and product development consultant in enterprise-level adoption and use of lean development, agile principles and practices, and large-scale Scrum in large, multisite, and offshore development. He is chief scientist at Valtech, an international consulting and offshore outsourcing company. His books include the best-sellers Agile & Iterative Development: A Manager’s Guide (Addison-Wesley, 2004) and Applying UML and Patterns, Third Edition (Prentice Hall, 2005).


Bas Vodde works as an independent product-development consultant and large-scale Scrum coach. For several years he led the agile and Scrum enterprise-wide adoption initiative at Nokia Networks. He is passionate about improving product development, an avid student of organizational, team management, and product development research, and remains an active developer.

Excerpt. © Reprinted by permission. All rights reserved.



The future ain’t what it used to be.
—Yogi Berra

We sat down in the meeting room with our hot coffee. Outside was a bitter-cold north European winter morning. In came our new client and we shook hands. “Thanks for visiting,” he said. “First, you should know that our product group is not large, maybe only eighty developers.”

We once met a group adopting agile development that was not sure if they could grow to very large-scale development: 12 people.

People have different scales in mind regarding ‘large.’ To some it means only 50 people or even less. To others, much more. We define a large product 1 group as one whose members’ names you could not remember if you 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.’

On to our key recommendation: After working for some years in the domains of large, multisite, and offshore development, we have distilled our experience and advice down to the following: Don’t do it.

There are better ways to build large systems than with many developers in many places. Rather, build a small group of great developers and other talents that can work together in teams, pay them well, and keep them together in one place with product management or whoever acts as the voice of the customer.

But of course you are still going to do large, multisite, or offshore development. This is because your existing system is already structured that way, or because—in the case of large groups—there is the mindset that “big systems need lots of people.” We regularly coach groups that ask, “How can we calculate how many people we will need?” Our suggestion is, “Start with a small group of great people, and only grow when it really starts to hurt.” That rarely happens.

Since large, multisite, and offshore development is going to happen, we would like to share what we have tried or seen at the intersection of these domains with lean and agile product development principles and practices. 2

Thinking and Organizational Tools

When Bas was a member of the leadership team of a large product group, he frequently (in meetings) asked, “Why do we have this policy? ... What will happen to the organizational system if we do that?” Months later a member of the team told Craig, “It drove me nuts to keep hearing those questions. But later, I appreciated it.” Bas wasn’t trying to be annoying; he was trying to suggest and encourage systems thinking—a thinking tool (1) to consider the deeper dynamics of the development system as a whole, (2) to understand how a system became the way it is, and (3) to reconsider assumptions underlying the existing organization.

When people are introduced to Scrum with its short timeboxed development iterations, they first see it as a localized practice to incrementally grow a product in small manageable steps, with learning and corrective actions toward a goal. Consequently, people will say, “Oh, ‘agile’ doesn’t affect me; that’s a development practice.” But there is a bigger picture and a potential higher-level learning loop beyond the lower-level development learning cycle: a learning organization of people that repeatedly re-examine the structures and policies that define and surround agile product development. The result of adopting Scrum or lean principles in very large product groups inevitably leads to this higher-level organizational learning challenge.

Example: Consider an enterprise whose R&D division tries to be more adaptive by adopting Scrum. The Sales division continues in their old mode: Maximize personal commissions and quarterly sales by promising the moon and the stars to customers, combined with almost boundless optimism for what “our great people in R&D can do.” Faced with unattainable ‘commitments’ R&D did not themselves design or make, R&D is then blamed for not meeting “our promises,” and it is concluded that “Scrum doesn’t really help.”

If this were a book about adopting Scrum only in one small 20-person single-product group within a large enterprise, systems thinking and organizational tools would be interesting but non-vital topics. But they are vital to a successful adoption when Scrum is being scaled to a 400-person single-product group, probably within a larger R&D organization in the thousands that is also making the transition, with deep connections to the Sales and Delivery groups, and constrained by traditional Human Resource and Enterprise Governance policies on team structures, reporting, measurement, milestones, contracts, and rewards.

Consequently, this book suggests that one cornerstone for large-scale Scrum and agile development is people who learn and apply various thinking tools, including (but not limited to) systems thinking, mental-model awareness, lean thinking, queueing theory, and recognition of false dichotomies. 3

With those thinking tools in place, it will become increasingly clear that the existing organizational design inhibits flow of value, leading to pressure for redesign. Hence, this book suggests a second cornerstone of organizational tools, including feature teams, requirement areas, and many other changes in structure, process, task, people, and rewards.


In parallel with adopting thinking and organizational tools, many action tools—specific development practices—help the product group get going on large, multisite, and offshore agile development. The effective use of these action tools—shared in the companion Practices book—is somewhat dependent on organization redesign. Many practices can be tried without deeper structural change, but constraints on benefit will be felt.

So the tools in this book could be seen as prerequisites for the actions tools of the companion book. Yet in reality, practices will be adopted first—because that is where people want to start. And that will eventually invite a look back at thinking and organizational tools.

We suggest that coaches and other change agents involved in the adoption of large-scale Scrum or lean development acquaint themselves early with thinking and organizational tools, while in parallel helping to introduce action tools. At some point the situation will be ripe—people will be ready—for a turn in the discussion from “How do we do large-scale continuous integration?” to “Do existing HR policies prevent real teams?” and “What is flow of value and what inhibits it in our organizational design?


Scrum emphasizes empirical process control; there is too much complexity and variability for a cookbook approach to processes for development. Therefore, the tools in both books are presented as a series of tips that start with Try... or Avoid... to suggest experiments, nothing more. They certainly may not work in your circumstance. The approach both in Scrum and in the lean thinking practice of kaizen is to first inspect and grasp the existing situation. Then, second, to adapt with new improvement experiments. The attitude of endless experimentation is vigorously encouraged in lean thinking; perhaps the only bad process-improvement experiment is the one not tried. At Toyota, Taiichi Ohno—arguably the key contributor to lean thinking—would visit an area and inspect any written standards document. If it was covered with dust or otherwise not recently changed, he would grow quite impassioned and urge people to always evolve their ‘standards.’

In Scrum this inspect-and-adapt (experiment) cycle repeats every two- or four-week timeboxed iteration as long as the product exists. And in lean thinking, this continuous experimentation and improvement cycle applies both to individual products and to the enterprise as a whole.


There is still much for us to learn about these domains. What we have written here and in the companion book reflects our current (limited) experience and understanding, which we hope will evolve in the coming years. For example, although we have lived for some years in China and India, we feel we have barely scratched the surface in terms of our multicultural experience and insight in relation to offshore and multisite agile development. Nevertheless, our sincere wish is that these tips are of some value to you. We welcome further insights and stories from our readers.

Large-scale Scrum can influence almost all aspects of a product-centric enterprise. To keep the scope of this material manageable and because of our limited experience in some of these areas, we bounded or deferred subjects that are worthy of more discussion. These include:

  • budgeting and finance
  • sales
  • product development not involving any software
  • marketing
  • deployment/delivery
  • hardware development
  • field support

Essentially, this book is relevant to general-purpose product development. Scrum and lean product development are not limited to software systems NT86. However, the bias is toward software-intensive systems (usually embedded) because of our background and because of the ever-growing ubiquity of software in everyday devices, from washing machines to shoes.

Especially in this book we dissect some assumptions and policies in traditional organizations that inhibit flow of value and effective teams. This analysis may come across as startling or challenging at times. We do not mean to give offense, but organizational redesign to support lean and agile development will not happen without increased scrutiny of traditional assumptions and increased transparency. Organizational change can also lead to displacement of talented people from old roles. As in Toyota, we encourage finding new areas of contribution for people within a company—both because skilled people deserve this, and because otherwise it inhibits change.

With both books combined pushing over 700 pages, we regret that we could not write or think better to make the subject of large...smaller.

On to thinking tools...


  1. Scrum (and this book) applies both to product development for an external market, and to internal applications (internal products).
  2. The companion book is Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. It covers detailed practice tips related to scaling and planning, product management, multisite, offshore development, contracts, requirements, design and architecture, coordination, legacy code, testing, and more.
  3. The term thinking tools was popularized in Reinertsen97.

© Copyright Pearson Education. All rights reserved.

Product Details

  • File Size: 3238 KB
  • Print Length: 368 pages
  • Simultaneous Device Usage: Up to 5 simultaneous devices, per publisher limits
  • Publisher: Addison-Wesley Professional; 1 edition (December 8, 2008)
  • Sold by: Amazon Digital Services, Inc.
  • Language: English
  • Text-to-Speech: Enabled
  • X-Ray:
  • Word Wise: Not Enabled
  • Lending: Not Enabled
  • Amazon Best Sellers Rank: #345,314 Paid in Kindle Store (See Top 100 Paid in Kindle Store)
  •  Would you like to give feedback on images?

Customer Reviews

Most Helpful Customer Reviews
18 of 18 people found the following review helpful
5.0 out of 5 stars Be Agile/Lean Rather Than Do Agile/Lean February 25, 2009
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.
Comment | 
Was this review helpful to you?
8 of 8 people found the following review helpful
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?
Read more ›
Comment | 
Was this review helpful to you?
5 of 5 people found the following review helpful
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.
Read more ›
Comment | 
Was this review helpful to you?
Most Recent Customer Reviews
5.0 out of 5 stars Recommended reading
Great principles-based exploration of Lean and Scrum. Covers a broad set of topics and is thus quite "light" but will serve as a jumping off point for other more focused... Read more
Published 6 months ago by J. Osborn
5.0 out of 5 stars Tough questions addressed openly
Agile and Lean Development practices are a favorite among software developers, but they are not just software developer strategies. Read more
Published 6 months ago by Russell Johnson
4.0 out of 5 stars So far, the best book on Agile scaling
Far better than either Ambler or Leffingwell.
Larman knows what he's talking about.
State of the art Agile understanding? Larman's got it. Read more
Published 7 months ago by Aretae
5.0 out of 5 stars Fantastic for larger groups/organizations
This book is fantastic. The organizational context is well explained and many times suggested approaches are included that often come from the authors' direct experiences. Read more
Published 11 months ago by Mark W Rice
5.0 out of 5 stars Very thorough in its content
"Watch the baton, not the runner" gave me a greater insight for some questions I was looking for answers many years. This is a great book.
Published 21 months ago by Indrajith
1.0 out of 5 stars Preaching without Practice?
I am a fan of Craig Larman's book on "Applying UML and Patterns' and I still consider it one of the best introductions to OOA/D and patterns. Read more
Published on April 26, 2012 by Raja Valiveti
5.0 out of 5 stars Best process book I read in many years
The title sugegsts like it was about scrum or about scaling. Those are really just a tiny chapter.

Most content describes lean THINKING, how to see the world, the... Read more
Published on September 7, 2011 by B. Pl
5.0 out of 5 stars Great overview with tons of practical tips
I found this book after listening to Bas on a podcast and have really enjoyed it. Having done a lot of research and read many books across Agile, Scrum and Lean SW over the past... Read more
Published on July 9, 2011 by Peter DeRosa
5.0 out of 5 stars Be Agile for Competitive advantage in Business
This book is one of the best books available for Large Scale Agile Adoption and Development. I had read this book about a year ago. Read more
Published on July 18, 2010 by Shanmugam Annapoorani
5.0 out of 5 stars A bit hard to read but packed with information
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. Read more
Published on February 16, 2010 by Carlos Moran
Search Customer Reviews
Search these reviews only

More About the Authors

Discover books, learn about writers, read author blogs, and more.


There are no discussions about this product yet.
Be the first to discuss this product with the community.
Start a new discussion
First post:
Prompts for sign-in

Look for Similar Items by Category