Q&A on Large-Scale Scrum: More with LeSS

The book More with LeSS by Craig Larman and Bas Vodde provides practices to create simpler and more flexible organizations, applying Scrum with many teams working on one product. More with LeSS is the third book on LeSS (see books on LeSS); it’s the most concrete and fundamental book to start learning about LeSS. The book also contains insights in experiences with LeSS adoptions.

Chapter 2 of More with LeSS is available online.

InfoQ interviewed Craig Larman and Bas Vodde about what LeSS is, how this third book on LeSS fits in with the books on Large-Scale Scrum that were previously published, how organizations adopt LeSS, working with feature teams and what teams can do to smoothen coordination and integration, how LeSS view the role of managers, and asked for advice for adopting LeSS in multi-site organizations.

InfoQ: For those not familiar with LeSS, can you describe it?

Craig Larman and Bas Vodde: What is LeSS?  In short, LeSS is the principles of Scrum applied to many teams creating together one product.

Let’s break that down:

LeSS is Scrum—Large-Scale Scrum (LeSS) isn’t new and improved Scrum. And it’s not Scrum at the bottom for each team, and additional layers on top. Rather, it’s about figuring out how to apply the values, principles, purpose, elements, and elegance of Scrum in a multi-team context. Like Scrum and other true-to-agile frameworks, LeSS is “barely sufficient methodology” for high-impact reasons.

Scaled Scrum is not a special scaling framework that happens to include Scrum only at the team level. Truly scaled Scrum is Scrum scaled.

…applied to many teams—Cross-functional, cross-component, feature teams of 3–9 learning-focused people that do it all to create done items and a shippable product.

…creating together—The teams are creating and working together as they have a common goal to deliver (at least once and perhaps continuously) one shippable product in their common Sprint, and each team cares about this because they are a feature team responsible for the whole, not a part.

…one product—What product? A broad complete end-to-end customer-centric solution that real customers use. It’s not a component, platform, layer, or library.

LeSS consists of:

Rules—A few rules that form the foundation. They define the essence of the LeSS frameworks that is the minimum that should be in place to support empirical process control and whole-product focus. e.g. Hold an Overall Retrospective each Sprint.

Guides—A moderate set of guides to clarify the effects on organization when adopting the rules to an organization; worth trying based on years of experience with LeSS; e.g. Three Adoption Principles.

Experiments—Many experiments that are very situational and may not even be worth trying; e.g. Try… Translator on Team.

Principles—At the heart, a set of principles—extracted from experience with LeSS adoptions—that inform the rules, guides, and experiments; e.g. whole-product focus.

InfoQ: What are some big differentiating ideas behind LeSS that you’re attempting to convey in this new — third — book on LeSS?

Larman & Vodde: Two of the differentiating ideas we want to convey are (1) Own and not rent, and (2) More with LeSS by descaling organizational complexity.

Own and not rent

Back in the early days of Agile development, a key big idea that the early Agile thought-leaders were trying to convey was… barely sufficient methodology. Keep the set of required elements in the framework super simple and barely sufficient, so that people in an organization own and not rent their ideas. Owning, caring and improving over renting, using, and following. The teams will learn and creatively solve problems and  invent and evolve situationally appropriate processes and practices. This is very much in the Toyota/Lean spirit of challenge-everything mindset and culture, where the workers themselves experiment to shape and continually improve their organizational system.

Of course, this doesn’t mean teams shouldn’t learn from other teams, they should! The key difference is between (A) the traditional process-focus of having consultants train the “best practices” the teams ought to follow, versus (B) the continuous improvement focus where the teams share earlier noteworthy ideas through guides and they’ll also create experiments to evolve their own practices.

That’s why LeSS is called LeSS (in addition to being an acronym for Large-Scale Scrum): it’s less. In other words, it’s simple and barely sufficient for many teams working together on one product.

More with LeSS

Many people ask us, “How can we apply agile at scale in our big complex organization?”

We suggest this is the wrong question. Why?

Because traditional large groups are complicated — though not because they need to be, but because their organizational designs create an illusion of unnecessary complexity.

This is critical to see! Most large groups are composed of single-function groups and component teams that lead to the coordination chaos problem. And then people ask, how do we overlay “an agile method” onto this existing organizational design.

How did these large groups become so complex? One major reason is that they traditionally solve problems by adding roles, processes, and artifacts. Whenever a new idea emerges or the there is a problem to be solved, new things get added. Adding roles, process, and artifacts traditionally is seen as not harmful. But they are! More roles leads to narrower responsibilities (and then more need for coordination), processes leads to less ownership and improvement, and artifacts lead to greater distances between teams and customers.

Therefore in LeSS we ask a different question. It is, “How can we simplify the unnecessarily big and complex organizational design, and be agile rather than do agile?” And so LeSS descales organizational complexity, dissolving unnecessary complex organizational solutions, and solving in simpler ways. More with LeSS.

In a way, one could say that LeSS is for descaling, not for scaling.

If someone studies LeSS and concludes, “Well, there’s not enough roles, processes, and practices here. We need a bigger framework with more best practices defined in it.” … then they’ve quite missed the point!

InfoQ: What made you decide to write this book?

Larman and Vodde: While reflecting on the feedback that our previous two books (LeSS book-1, and LeSS book- 2) on LeSS presented too many ideas with too few starting points, we decided to write LeSS book-3, “Large-Scale Scrum: More with LeSS” with the initial intent to write a primer for the previous two LeSS books, to help novice-level groups. But we ended up with a very different and more interesting book than just a primer, though it is indeed the most concrete and fundamental book to start learning about LeSS.

InfoQ: For whom is this book intended?

Larman and Vodde: This book is for everyone in product development who wish to create an organization that is being agile, rather than doing agile. The implications of adopting LeSS are changes in the existing organizational design, including structures and groups, roles, processes, and policies, and so the book is relevant to senior management that have the remit and authority to change the organization… but it is also relevant for team members, coaches, Scrum Masters, and Product Owners, and whomever wants to understand Scrum, LeSS, and organizations, all better.

InfoQ: How does this book fit in with the books on Large-Scale Scrum that were previously published?

Larman and Vodde: Our initial intent was to write a primer for the previous two LeSS books.

We ended up with a very different book as our exploration in concrete starting points led to a pursuit for the minimum essentials for scaling. The result? The LeSS rules, the LeSS guides, and this book. It also includes some key insights from about 10 years of experience with LeSS adoptions; it synthesizes, clarifies, and highlights what’s most important. For example, we came to realize (or at least clarify) the importance of the scope of product definition on scaling and system optimization, and the book includes an important set of guides about product scope, that are not even hinted at in the prior books.

Though the book ended up very different than our intention (and much better!), it is still the first book we’d recommend for LeSS. The others might, one day, need to be updated to put them in the context of this book.

InfoQ: How do organizations adopt LeSS?

Larman and Vodde: To start with principles, one adoption guide in LeSS is the Three Adoption Principles, which are (1) deep and narrow over broad and shallow, (2) top-down and bottom-up, and (3) use volunteering. Deep and narrow over broad and shallow means to focus with lots of coaching, management support, and so forth. And then to learn from that experience to inform future change. Top-down and bottom-up means that, since LeSS is a deep change in organizational design (groups, roles, policies, etc.) it must include engagement from top management that will enact these organizational changes. And since making people prisoners of a top-down commanded change doesn’t work, it needs to include deep learning and energy from the teams. The use volunteering approach in which the people who participate in the change volunteer to do so creates energy and ownership by the teams.

The actual adoption approach depends on the size of the product group. There are 2 frameworks in LeSS: the simpler LeSS framework that works for product groups of between 2-8 teams (e.g. max 50-ish people), and the LeSS Huge framework, for product groups of hundreds or even thousands of people working together on one product.

Why bring that up? Because, to reiterate, the adoption approach is different depending on which framework is being adopted. In fact, it is the opposite!

2-8 Teams LeSS Adoption

For smaller groups adopting the simpler LeSS framework, the rule is to establish the complete LeSS structure “at the start” in an “all-at-once” change.

Why is it all-at-once for the smaller LeSS framework? There’s several reasons, but perhaps the simplest summary is that the organizational model of LeSS — in terms of structure, roles, responsibilities, processes, policies, and practices — is very different than the traditional (existing) model. Not changing the structure creates  myriad deep conflicts that most often results in adopting new names without changing anything. We’ve described this behavior in the Larman’s Laws of Organizational Behavior.

Because it’s “only” 50-ish people and can be combined with a few months of preparation before the all-at-once change, this can be realistically done successfully. The preparation involves understanding why LeSS is structured the way it is, then deeply understanding their current problems using systems thinking, and getting the environment and teams prepared for the first Sprint in LeSS. The typical LeSS adoption steps are described in the Getting Started guide (in the new LeSS book):

0. educate everyone

1. define “product”

2. define “done”

3. have appropriately structured teams

4. only the Product Owner provides work for the teams

5. keep project managers away from the teams

Explaining these in detail is not the place in this brief introduction, so we’ll only highlight the key point that step one is define product. Many things flow from an appropriate product definition, and in LeSS the basic rule is that the definition of product should be as broad and end-user/customer-centric as is practical. In practice, most companies discover that their product isn’t what they thought their product was.

LeSS Huge Adoption

In a LeSS Huge adoption of perhaps 500 people in many sites, the all-at-once approach doesn’t work, because you drown the organization in too much change impact that it isn’t able to absorb or learn and adapt from. It would actually be nice if one could do it all at once because of the conflicting models problem, but it just isn’t feasible. Or if it is, we’d like someone to let us know how!

The most common (but not only) recommended approach for LeSS Huge is to create a parallel organization as this avoids most of the problems of the conflicting models and it also follows the deep-and-narrow adoption principles. It requires to get the Product Backlog in a good shape, and then chose one customer-centric area to start a LeSS adoption. That customer-centric area (called a Requirement Area in LeSS Huge) is then basically a 2-8 teams “smaller framework” LeSS adoption within that Requirement Area, while the rest of the organization continues to operate mostly as they did before, although of course also ideally cultivating continuous improvement, especially on the technical side

The last adoption guide we’d like to mention is Job Safety but not Role Safety. We think it’s just terribly disrespectful of people and unfair if people could lose their job as a result of a change idea. And practically in terms of change management, you can’t have fear and successful change; the reasons should be self-evident. LeSS does implies a deep change in structure, roles, and responsibilities, one cannot of course maintain role safety.

InfoQ: When working with feature teams, teams may need to update many components when a new feature is implemented. Does this mean that developers need to know the complete system?

Larman and Vodde: In a 2-8 team LeSS adoption, perhaps. In a LeSS Huge adoption, unlikely.

But let’s first define the term: a feature team (in LeSS, and in general usage) is a cross-functional and “cross-component” team that does everything to understand and deliver customer-centric features. This might include UX investigation, analysis, design, architecting, programming across all components, videos, art, audio, etc. Dialing in to the question, that includes coding across any and all components (micro-services, applications, layers, modules, classes, …) needed to deliver a feature.

Does that mean that each product developer on a feature team needs to know everything? Of course not. That kind of either/or thinking seems a common pattern in the software world; for some reason, computer people are very binary ;)  So we wrote a chapter in the first LeSS book years ago called False Dichotomies precisely because of this.

Moving beyond the false dichotomy of a person or a team knowing one thing or knowing everything, it’s likely that different people on a team know different components with varying levels of expertise. So to complete a feature the team as a whole may have the required knowledge across the necessary components, but not any one individual. And if nobody knows a component, it’s time for learning — a key and dominant behavior in a LeSS organization. This shouldn’t be a surprise as already the original roots-of-Scrum 1986 HBR paper defined ‘multilearning’ as a key characteristic, which was defined as learning on multiple levels and functions.

As a minor aside, the idea of working on unfamiliar code seems scary or daunting to people who aren’t programmers, and to programmers who have mostly been confronted with mountains of crappy code. But if the group is developing clean code with TDD, which are critical practices within the Technical Excellence suggestions of LeSS, it’s not a big deal. Both of us (Bas and Craig) continue to work hands-on as professional programmers with other developers, in addition to working as organizational-design consultants for LeSS with senior managers — we try to work practically across the “organizational stack” — and so we can say “it’s not a big deal” from years of direct experience in clean code and TDD development. And for the common case of adopting LeSS into a legacy-code situation with lots of crappy code, there are a set of compensating guides and experiments in LeSS, including component mentors, current-architecture learning workshops, and more.

For small 2-5 team LeSS adoptions, it relatively common that some people understand the majority or all of the codebase. The larger the product gets, the less likely it is. Bas has been working with a thousands-of-people LeSS Huge adoption and it is probably impossible for a single person to understand every aspect of the code. But at such scale, it is not needed. Why? LeSS Huge is structured into customer-centric areas which contain closely related features, such as “trade processing” and “regulatory reporting.” These are called Requirement Areas. Teams tend to work in one area for a longer period of time. Note that these are customer areas, not architectural components. And even though these areas are not based on architectural components, it’s likely that by focusing in one area (e.g. regulatory reporting) the four-to-eight features teams in that one area will also be focusing on a semi-predictable subset of the total code base. Thus the code they need to know really well will be less than the entire code base.

InfoQ: What are things that teams can do to smoothen coordination and integration?

Larman and Vodde: Coordination and integration is really important in LeSS, but the LeSS perspective often catches people by surprise as they expect coordination events (big room planning), meetings (Scrum of Scrum) or roles (Project Manager, Integration Team). But LeSS does not include any of these and in fact recommends against them. Why? Two reasons: (1) having coordination roles leads to teams taking less responsibility in coordination, and (2) we noticed that formal coordination channels often cause less of the emergent, self-organizing, decentralized team-initiated coordination that we experienced as most effective.

How can decentralized information coordination between teams be encouraged? The foundation of this is:

> teams owning coordination

> feature teams with common aim

> whole-product focus

> friendly physical and technical environments

We’d like to highlight the common aim. In a traditional organizational set-up, coordination is often seen as a nuisance and an interruption. The test team interrupts the development team when they find a bug. The back-end team requires changes to the front-end which is an interruption as they are working on different things. If coordination should be informal and emergent, then it shouldn’t be a nuisance; it should feel useful and timely. Or, as Yves Morieux states it in his excellent TED talk on simplifying organizations, “We need to create organizations where it is individually useful to cooperate.” LeSS facilitates such organization by re-structuring into true feature teams that do everything, in a shared code context and with a common aim to ship one product at the end of the common Sprint. This results in no dependencies between teams and with most coordination related to shared tasks in the code that multiple teams care about, all happening at the same time, and thus beneficial and immediately relevant to the teams involved.

Zooming in on integration: LeSS expects modern development practices, such as continuous integration of all changes into the mainline while keeping the product shippable at any stage or even continuously delivering the product all the time. Investing in test automation, fast builds, and automated deployment is usually one of the first things to do in LeSS Huge adoptions.

Zooming out to a bigger idea: Coordination and integration are closely related, as traditionally most coordination is related to integration. When two teams need to integrate their work, they’ll need to coordinate to integrate. But when applying continuous integration, we can turn that around. By continuously integrating, we can easily determine who is working on the same part of the system at the same time. Coordinating with them is beneficial for both as you can use each other's work. Thus instead of coordination supporting integration, we now have integration supporting coordination! We refer to this practice as “communicate in code.” As, of course, branching just became even more evil than it was before.

There are a lot more LeSS guides that facilitate the informal, decentralized coordination, such as communities, multi-team events, open space, travelers, component mentors, and scouts. But this interview is probably not the right place to go into detail of all of these.

InfoQ: How does LeSS view the role of managers?

Larman and Vodde: Most organizations have a large variety of managers, so we’ll just focus on two: project/program managers, and development/line managers.

Project/Program Management

In LeSS organizations, the project/program manager role is likely to disappear in product development. This is partly the result of having self-managing teams who take over much of the responsibility, and partly the result of avoiding product development using projects.

LeSS follows traditional organizational theory. If you want to increase organizational flexibility (agility), you do so by delegating responsibility so decision making doesn’t slow down responses. This leads to flatter organizations and less managers.

Of course, we don’t suggest to fire all project managers as that would be against the LeSS guide of job safety, but not role safety. Instead, these are usually smart people who are able to find a different role in the organization or join one of the teams.

In LeSS Huge product groups, especially when hardware manufacturing is involved, there is still likely to be a last-step product-release project and then also project management roles for product-release-related activities such as manufacturing logistics. These existing project roles won’t change immediately when LeSS is adopted, though the more organizations move to continuous delivery, the less project-based management is needed.

Development/Line Management

These managers traditionally are involved in both the what and the how. In Scrum — and thus too in Large-Scale Scrum — the what is shifted to the teams and especially to the Product Owner (from a business area; they are not a development or project/program manager), and the how is shifted completely to the self-managing teams. And with a self-managing team the responsibility of the team is extended to include “managing and monitoring process and progress”, to quote the late Richard Hackman from Harvard, the preeminent team researcher.

Is there a role for managers in a LeSS organization? If managers never existed (yes, these companies exist), then adopting LeSS wouldn’t require adding them. But when managers exist, they can be very valuable, but their role is likely to change. They won’t focus on the day-to-day product work but on improving the value-delivering capability of the product development system. The managers’ role is to improve the product development system by practicing Go See, encouraging Stop & Fix, and “experiments over conformance.”

InfoQ: What's your advice for adopting LeSS in multi-site organizations?

Larman and Vodde: Most of our experience with clients adopting LeSS are in quite large and multi-site product groups (often including sites in Asia, Europe, and the Americas), so this is somewhat familiar territory for us. Our initial advice is to avoid it. Often people argue that that isn’t possible in today’s world, but it is a choice. There is a reason why many of the greatest products were developed co-located.

That said, you can apply LeSS to a multi-site product group. The single most important practice is for each feature team to be co-located. Why? When we reflect on distributed teams we worked with, with rare exceptions, these weren’t real teams. They were a group of individuals doing their own thing. That’s not how good teams work; good teams are a highly cohesive social unit with a shared goal, teaching each other, working closely together minute-by-minute with practices such as team design workshops at a whiteboard, mob programming, promiscuous pairing, and so forth. For that co-location is a big enabler.

Now if the entire development group is seven people dispersed in seven cities, we can accept the fact that dispersion is a fact. But consider a typical large-scale multi-site context, when there are for example 200 people working on one product, with 50 people in site-1, 50 people in site-2, and so forth. In that case, there is no good reason that any one team of seven-ish people can’t be co-located, since each site has far more than seven people in it.

So that’s a foundation of multi-site development in LeSS: each feature team is co-located. But it’s perfectly okay if there are three teams at site-1, five teams at site-2, and so on. And in that case, the key remaining questions revolve around how do teams at different sites coordinate. Unfortunately, there are no magic solutions that will remove the pain of distribution and the practices that reduce the pain are commonly known, including video conference, shared digital spaces, tools like Slack, frequent travel.

InfoQ: How does LeSS support continuous improvement in organizations?

Larman and Vodde: Who should do the continuous improvement? Traditionally, the improvement activities are separate from the teams and done by the special improvement people. The quality people, the belt people, the program consultants, the transformation people, or however they are called. This rarely leads to real improvements as they tend not to Go See enough and don’t feel the true pain of the work.

The obvious alternative answer would be “everyone!” But how can we get everyone in the organization to continuously improve? They need to care about how they work, they need to own how they work. So we’re back to the owning vs renting topic that was discussed earlier. We can create continuous improvement when people own the way they work, get quick feedback on how they do, and are empowered and encouraged to do something about it.

To achieve that, frameworks should avoid giving all answers in all context so that product groups just follow them. Instead product groups need to experiment to improve. So frameworks need to only give a minimum structure that allows for transparency, feedback, and experimentations. Hence…

More with LeSS.

About the Book Authors

After a failed career as a street musician, Craig Larman (craig@less.works) attempted to study computer science, specializing in AI (having little of his own). He’s the co-creator of LeSS with his friend and colleague Bas Vodde, and together they have co-authored 3 books on LeSS: "Large-Scale Scrum: More with LeSS", "Scaling Lean & Agile Development: Thinking & Organizational Tools for Large-Scale Scrum", "Practices for Scaling Lean & Agile Development: Successful Large, Multisite & Offshore Product Development with Large-Scale Scrum".

After realizing he didn’t like either wet or cold, Bas Vodde (basv@less.works) travelled by canoe from the Netherlands to Singapore, to practice the Dutch art of uitbuiken, and to help as a coach, programmer, trainer, and author related to modern agile and lean product development. He is the co-creator of LeSS and coaches organizations on three levels: organizational,  team,  individual/technical practices. He has trained thousands of people in software development, Scrum, and modern agile practices for over a decade.