Book Notes #114: Large-Scale Scrum: More with LeSS by Craig Larman and Bas Vodde

Title: Large-Scale Scrum: More with LeSS
Author: Craig Larman and Bas Vodde
Year: 2016
Pages: 368

Large-Scale Scrum by Craig Larman and Bas Vodde is a great book for organizations that want to scale their agile practices beyond just one team, especially if they’ve never done it before.

The book offers a practical guide to implementing LeSS (Large-Scale Scrum), a framework designed to help organizations become more agile, deliver faster, and improve quality.

What I really like about it is the focus on keeping things simple, transparent, and always improving. More with LeSS makes a strong case for applying agile principles across multiple teams and even more complex systems. It’s perfect if you’re looking to scale agile in a way that actually works.

As a result, I gave this book a rating of 7.5/10.

For me, a book with a note 10 is one I consider reading again every year. Among the books I rank with 10, for example, is Dale Carnegie’s How to Win Friends and Influence People.

3 Reasons to Read Large-Scale Scrum

Book Overview

Large-Scale Scrum is a solid guide for scaling agile practices across multiple teams and complex systems.

Written by Craig Larman and Bas Vodde, two big names in the agile world, the book introduces LeSS (Large-Scale Scrum)—a framework that focuses on simplicity, transparency, and continuous improvement.

What I love about this book is that it’s packed with real-world examples and case studies, making the concepts easier to grasp and apply. The authors really dive into systems thinking, helping you see how teams are connected and how their work impacts the whole organization.

One of the key lessons for me was how important it is to simplify and decentralize decision-making. Giving teams the power to make decisions about their work is a game-changer.

The book also emphasizes staying focused on customer value, ensuring teams are aligned with what customers need. It encourages creating a learning culture, where teams are always adapting and improving.

The whole-product mindset is another important takeaway. Instead of working on isolated parts, teams should focus on the entire product. By adopting a systems thinking approach, organizations can better understand how their teams are interlinked and how those connections influence the larger system. This book is a great resource for anyone looking to scale agile in a meaningful way.

Scrum is a popular framework for building complex solutions, emphasizing iterative development, teamwork, and customer-centricity. However, applying Scrum principles to large projects presents unique challenges. Larman and Vodde address these challenges in their book by introducing the concept of Large-Scale Scrum (LeSS).

LeSS offers a framework for scaling Scrum beyond small teams to entire organizations. It focuses on simplifying processes, reducing dependencies, and fostering collaboration across teams. Larman and Vodde advocate for a “less is more” approach, favouring simplicity over complexity in large-scale agile implementations.

From the official LeSS website: LeSS is Scrum applied to many teams working together on one product.

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 something different layered on top. Rather, it’s about figuring out how to apply the principles, purpose, elements, and elegance of Scrum in a large-scale context, as simply as possible. Like Scrum and other truly agile frameworks, LeSS is “barely sufficient methodology” for high-impact reasons.

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

…working together – The teams are working together because they have a common goal to deliver one common shippable product at the end of a common Sprint, and each team cares about this because they are a feature team responsible for the whole, not a part.

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

Chapter by Chapter

Chapter 1 – More with LeSS

The authors start with a simple yet powerful idea: the best components are the ones that don’t exist—because complexity slows us down. This idea of “more with less” is at the heart of Large-Scale Scrum (LeSS), which builds on Scrum’s success while maintaining simplicity.

One of the first questions they explore is: Why did Scrum become so popular? Was it certification? The training courses? Simplicity? None of these alone explain it.

Instead, they argue that Scrum strikes the perfect balance between abstract principles and concrete practices. It provides just enough structure to get started but leaves room for teams to experiment and improve.

Scrum operates on empirical process control—meaning you don’t lock down scope or a rigid process. Instead, you work in short cycles, delivering a small, shippable part of the product, inspecting the results, and adjusting both the product and the way you build it. Transparency is key. Without it, you can’t inspect and adapt effectively.

But here’s the challenge: Scrum was designed for small teams. What happens when you need to scale? That’s where LeSS comes in.

LeSS is not Scrum plus extra layers. It applies the same principles at scale, keeping things as simple as possible. It deliberately avoids extra roles, processes, or artifacts, because adding more structure often kills ownership and learning. Instead, LeSS keeps the focus on empirical process control, transparency, and continuous improvement.

One of the book’s key messages is: The more rules, roles, and artifacts you add, the less responsibility and ownership teams feel. LeSS strips things down to maximize learning, team ownership, and customer focus. It’s about making Scrum work at scale without bloating it.

Chapter 2 – LeSS

This chapter dives deeper into how LeSS works. It starts by revisiting Scrum fundamentals: a single cross-functional team working in short cycles to deliver a potentially shippable product increment. But what happens when you have multiple teams working on the same product?

LeSS is Scrum applied to many teams working on one product. It’s not a different framework—it’s Scrum, just bigger. And that’s an important distinction.

The core idea remains the same:
– One Product Owner
– One Product Backlog
– One common Sprint across all teams
– One integrated, shippable product increment

The book makes it clear: LeSS is not a typical “scaling framework” that adds layers on top of Scrum. Instead, it’s about applying Scrum’s principles at scale while keeping things as simple as possible.

Background of LeSS

Craig Larman and Bas Vodde have been experimenting with scaling Scrum since 2005, working with companies like Ericsson, Nokia, UBS, Cisco, and bwin.party. Their early research showed that many teams struggled to apply Scrum in large organizations, leading to rigid, process-heavy implementations that killed agility. So, they designed LeSS to stay true to Scrum’s lean, lightweight nature.

How LeSS is structured

LeSS follows a learning model inspired by Shu-Ha-Ri (a Japanese concept of learning mastery):

1. Shu (Follow): Start with some basic rules to establish Scrum principles.
2. Ha (Adapt): Once you understand the basics, adapt the process to your needs.
3. Ri (Mastery): Eventually, create your own best ways of working based on experience.

To help teams at different learning levels, LeSS provides Rules, Guides, Experiments, and Principles.

• Rules: The absolute minimum requirements to make LeSS work (e.g., “One Product Backlog for all teams”).
• Guides: Best practices to help teams adopt LeSS more effectively.
• Experiments: Ideas tested in real-world organizations to improve agility.
• Principles: The core mindset behind LeSS, including whole-product focus, customer-centricity, lean thinking, and empirical process control.

The Two LeSS Frameworks:

1. LeSS (2–8 teams) → Works well for smaller large-scale setups.
2. LeSS Huge (8+ teams) → Introduces Requirement Areas and Area Product Owners to manage bigger product groups while still keeping a whole-product focus.

The Magic of “Less” in LeSS

A key takeaway from this chapter is that LeSS intentionally avoids adding complexity. Instead of introducing new roles and processes, it focuses on reducing dependencies, increasing learning, and making teams responsible for their work. The goal is always more learning, more ownership, and better products—with fewer rules, fewer handovers, and fewer delays.

In short: If traditional scaling frameworks focus on adding, LeSS focuses on removing. And that’s where its power comes from.

Chapter 3 – Adoption

Adopting Scrum is simple, right? Just follow the rules and everything magically improves. Well… not exactly. Scrum isn’t a process—it’s a framework that shines a light on everything that’s wrong with your current system. It forces transparency, and that can be uncomfortable. That’s why adoption is hard.

The chapter begins with an important reminder: Scrum doesn’t fix your problems. It just makes them visible. When companies try to adopt Scrum (or LeSS), they often resist what they see in the mirror. Instead of fixing the problems, they create workarounds, add layers of complexity, or water down the framework. But real transformation only happens when you confront these issues head-on.

A key principle in LeSS adoption is continuous improvement. Many organizations treat change like a one-time project: they roll out a transformation, declare victory, and settle into a new status quo—until the next change initiative undoes it all. LeSS takes a different approach: change isn’t a separate initiative; it’s the status quo. There’s no big change program, no army of change managers—just teams continuously improving their way of working.

Another critical lesson is how to adopt LeSS effectively. The authors outline three guiding principles:

1. Deep and narrow over broad and shallow – It’s better to get LeSS working well in one product group than to apply it poorly across many teams.
2. Top-down and bottom-up – Adoption works best when leadership supports it, but teams must also take ownership. A purely top-down mandate creates resistance, while a bottom-up movement lacks the power to remove obstacles.
3. Use volunteering – Instead of forcing teams into LeSS, let people opt in. When teams choose change, they’re more engaged, more motivated, and more likely to succeed.

One particularly interesting part of the chapter is the idea that culture follows structure. Many companies think they need to change culture first, but the authors argue the opposite: if you want to change culture, start by changing the structure. If teams are still stuck in functional silos, no amount of Agile training will make them truly cross-functional. But if you redesign teams around delivering customer value, collaboration and agility will naturally emerge.

The chapter also emphasizes job safety but not role safety. Structural change often means certain roles (like project managers or functional specialists) become unnecessary. But that doesn’t mean people should lose their jobs. Instead, organizations should help them transition into new roles that create value in a LeSS environment.

The final takeaway is that adoption is never done. Even after a successful LeSS transformation, there will always be new challenges to tackle and better ways of working to explore. The best organizations treat improvement as a never-ending journey.

This chapter is a reality check for anyone thinking about adopting LeSS. It’s not a plug-and-play framework—it’s a mindset shift. And that means challenging assumptions, breaking old habits, and continuously experimenting to find what works.

Chapter 4 – Organize by Customer Value

One of the biggest challenges in scaling Scrum is ensuring that teams stay focused on delivering customer value instead of getting lost in internal processes and technical silos. This chapter argues that large organizations often lose sight of the customer, turning teams into isolated cogs in a massive machine. LeSS aims to prevent that by structuring teams around delivering value, not just completing tasks.

The chapter starts by reinforcing a core idea: Scrum is about customer-centricity. In a single-team Scrum environment, this is easy—one team works on delivering a valuable product increment every Sprint. But as organizations scale, they tend to shift focus to internal concerns like technical components, roles, and governance layers.

This creates a disconnect between teams and the customer. The authors give an example of a company that, when it was small, had a strong customer focus but lost it as they added layers of management and processes. Their message is clear: more structure does not mean more agility.

LeSS avoids this by using feature teams—cross-functional, self-managing teams that work on end-to-end customer features rather than individual technical components. Unlike traditional organizations where teams specialize in backend, frontend, or databases, feature teams work across all parts of the system to deliver a fully functional feature. This eliminates handovers, reduces dependencies, and ensures that teams are always delivering something meaningful to users.

To make this work, teams in a LeSS organization follow a team-based structure with a few key principles:

• Dedicated teams: Every team member is fully committed to one team.
• Cross-functional teams: Teams have all the skills needed to deliver a working product.
• Co-located teams: Whenever possible, teams should sit together to maximize collaboration.
• Long-lived teams: Stability leads to stronger team dynamics and better performance over time.

A particularly interesting insight from this chapter is that organizations should see people as learners, not just resources. Many companies treat employees like specialized machines that can only do one thing well, but LeSS encourages team members to develop new skills, making them more adaptable and increasing overall flexibility. Instead of asking, “Which individuals do we need?” LeSS organizations ask, “Which teams do we need?”

The authors contrast feature teams with component teams to highlight the benefits of organizing by customer value. In a traditional setup, component teams specialize in different parts of the technology—one team owns the database, another handles UI, and so on.

This might seem efficient, but it creates bottlenecks, dependencies, and delays because no team can deliver a complete feature on its own. Feature teams, on the other hand, own the entire feature from start to finish. They speak the language of the customer, make faster decisions, and avoid coordination nightmares.

That said, transitioning to feature teams isn’t always easy. It requires breaking down traditional roles, expanding the scope of work for teams, and changing how teams are structured. The chapter introduces Feature-Team Adoption Maps to help organizations visualize their transition from component teams to feature teams. This is a gradual process, often taking months or even years in large enterprises.

The chapter ends with a discussion on LeSS Huge, the variation of LeSS designed for very large organizations. Since scaling often requires some additional structure, LeSS Huge introduces Requirement Areas—logical groupings of related customer needs.

Each Requirement Area has its own Area Product Owner who focuses on specific parts of the product while maintaining alignment with the overall Product Owner. This keeps teams focused on delivering customer value while ensuring that large-scale coordination remains manageable.

The key takeaway from this chapter is clear: Organizing teams around customer value is the only way to scale Scrum effectively.

Traditional structures often prioritize internal efficiency at the cost of customer impact, but LeSS challenges organizations to rethink how they structure teams.

Instead of adding more layers, LeSS encourages reducing complexity, increasing team responsibility, and keeping the focus on what truly matters—delivering value to the customer.

Chapter 5 – Management

When people think of Scrum, they often assume that managers become obsolete. After all, Scrum teams are self-managing, Product Owners decide what to build, and Scrum Masters help teams improve and remove obstacles. So, where does that leave traditional managers? The answer is: they’re still needed, but their role must change—a lot.

This chapter is all about redefining management in a LeSS organization. It challenges long-standing ideas about hierarchy, control, and decision-making, showing why traditional management often creates bottlenecks instead of enabling success.

Instead of overseeing daily tasks and making decisions from the top down, managers in LeSS focus on improving the system, fostering learning, and developing the organization’s capability.

A big part of this shift comes from a crucial insight: most management practices today are based on outdated ideas from the early 1900s. The authors introduce two key figures in management history—Frederick Taylor and Henri Fayol—who laid the foundation for modern corporate structures.

Taylor’s “scientific management” argued that there was one best way to do every job, which should be planned by managers and executed by workers. Fayol expanded on this with principles like hierarchical authority, division of labor, and centralized control.

The problem? These ideas were designed for factory work in the industrial age, not for knowledge work in today’s fast-moving world. Software development is complex, creative, and constantly changing. It requires adaptability, problem-solving, and collaboration—not rigid command-and-control structures.

The authors contrast this outdated Theory X mindset (which assumes workers are lazy and need to be controlled) with Theory Y, a much more human-centric view developed by Douglas McGregor in 1960. Theory Y assumes that people are naturally motivated, seek responsibility, and do their best when given autonomy and purpose.

LeSS is built entirely on this mindset, which is why self-managing teams, transparency, and decentralized decision-making are so important.

So what happens to managers in a LeSS organization? Instead of making all the decisions, they shift to roles that support continuous improvement. The authors outline three key areas where managers still play a critical role:

1. Go See – Managers must be deeply connected to the real work, not just sitting in meetings. They should regularly visit teams, observe how work is done, and listen to the challenges people face. This isn’t micromanagement—it’s about understanding reality so they can help improve the system.
2. Managers as Teachers and Learners – In LeSS, managers are not just decision-makers—they’re educators. They should be learning continuously, staying updated on both technical skills and business needs, and helping teams develop their capabilities. A great LeSS manager doesn’t just “manage” people—they coach, mentor, and facilitate learning.
3. Improving the System – Instead of focusing on individual performance, LeSS managers work on systemic improvements. They identify bottlenecks, remove unnecessary bureaucracy, and create an environment where teams can thrive. Their goal is to increase the overall capability of the organization, not just track tasks.

A particularly interesting part of the chapter is the discussion on “optional managers” in LeSS. The idea is simple: LeSS organizations don’t require managers, but they can exist if they provide value.

This is a major contrast to traditional companies, where adding more managers is often the default response to any problem. The book criticizes the common corporate habit of creating new roles (like “release manager” or “feature manager”) instead of fixing the root problem.

The chapter also tackles metrics and targets, warning against the dangers of measuring for control instead of improvement. One example is test coverage—if management sets a mandatory coverage percentage, teams might game the system by writing meaningless tests just to hit the number.

But if teams themselves use coverage metrics to learn and improve, it becomes a valuable tool. The takeaway? Focus on purpose, not just numbers.

In summary, this chapter delivers a wake-up call to traditional management. It challenges leaders to step back from command-and-control practices and embrace a new role as enablers of learning, problem-solving, and system-wide improvements. The best managers in a LeSS organization aren’t the ones making all the decisions—they’re the ones helping teams make better decisions themselves.

Chapter 6 – Scrum Masters

The role of a Scrum Master is often misunderstood. Many organizations try to fit it into traditional management structures, treating Scrum Masters as project coordinators, team leads, or “agile” project managers. But in reality, a Scrum Master is not a manager, nor do they control the team. Instead, their role is about coaching, facilitating, and enabling change—not just within teams but across the entire organization.

In LeSS, the Scrum Master is a full-time role, responsible for guiding multiple teams, the Product Owner, and the broader organization toward better agility and continuous improvement. A common misconception is that a good Scrum Master can handle multiple teams at once, but the book makes a bold statement: “A good Scrum Master can handle multiple teams; a great Scrum Master just one.” This reinforces the idea that deep change requires deep focus.

One of the key principles for Scrum Masters in LeSS is systems thinking—helping people see beyond their immediate tasks and understand the bigger picture of product development. When scaling, organizations tend to introduce complexity, but a great Scrum Master challenges this by asking: “How can we make this simpler?”

A critical aspect of a LeSS Scrum Master’s job is ensuring transparency. Large organizations tend to hide problems under layers of process, reports, and bureaucracy. Scrum Masters clear the haze, exposing inefficiencies and encouraging teams to tackle real issues instead of working around them. This often puts them in conflict with traditional management, but it’s a necessary part of transformation.

The Four Focus Areas of a Scrum Master

1. Teams – Initially, a Scrum Master spends a lot of time coaching teams in self-management, improving collaboration, and helping them take ownership of their work. Over time, the teams should become more independent, reducing the need for direct support.
2. Product Owner – The Scrum Master helps the Product Owner connect with customers, prioritize effectively, and collaborate with teams. They also ensure the Product Owner isn’t just handing down requirements but actively working with teams to shape the product.
3. Organization – Many Scrum Masters focus only on teams, but in LeSS, they must engage with the entire organization to drive systemic change. This means working with leadership to improve structures, policies, and ways of working that impact agility.
4. Development Practices – LeSS emphasizes technical excellence, so a Scrum Master also plays a role in encouraging practices like test-driven development, continuous integration, and automated testing. Teams can’t be truly agile if their technical foundation is weak.

One of the more surprising points in this chapter is the idea that Scrum Masters should “actively do nothing.” This doesn’t mean being passive—it means resisting the urge to step in and solve problems for teams. Instead, they create space for teams to figure things out themselves.

Five Essential Tools for Scrum Masters

1. Questioning – Instead of giving answers, a great Scrum Master asks open-ended questions to help teams reflect and improve.
2. Educating – They deeply understand Scrum and help others see why certain practices exist.
3. Facilitating – They guide discussions, ensure transparency, and help resolve conflicts without controlling the outcome.
4. Doing Nothing (Strategically) – They avoid stepping in unless absolutely necessary, allowing teams to develop self-reliance.
5. Interrupting When Necessary – When a situation is spiraling out of control, a Scrum Master knows when to step in to prevent harm.

The Danger of “Anti-Scrum Masters”

One of the biggest risks in a LeSS adoption is misinterpreting the Scrum Master role. Many organizations assign the title to people who lack Scrum knowledge or motivation. This leads to “Anti-Scrum Masters”—people who unintentionally (or even intentionally) undermine agility by reinforcing old habits.

The book warns against common Scrum Master pitfalls, such as:

• Acting as a team assistant (scheduling meetings, fetching coffee) instead of driving change.
• Becoming an intermediary between teams instead of encouraging direct collaboration.
• Trying to coordinate work instead of letting teams organize themselves.
• Making decisions for the team instead of empowering them.

Scrum Masters as Change Agents

Scrum Masters don’t just work with teams—they also partner with managers to drive organizational change. In a LeSS organization, managers and Scrum Masters share a similar goal: creating an environment where teams can thrive. However, their focus is different—managers typically handle structural and policy changes, while Scrum Masters work on culture, mindset, and team dynamics.

To survive in this challenging role, a Scrum Master must develop five key traits:

1. Patience – Change takes time. Expect resistance.
2. Persistence – Change also requires repetition. Expect to explain things multiple times.
3. Courage – Standing up to old habits and traditional structures isn’t easy.
4. Humor – Change is frustrating, but laughing at the absurdity of corporate bureaucracy helps.
5. Humility – No one has all the answers. Scrum Masters must be willing to learn and adapt.

Scrum Master Communities

Scrum Masters should never work in isolation. The book encourages forming communities within organizations where Scrum Masters can support each other, share experiences, and learn together. These communities serve as a backbone for change in large-scale Scrum adoptions.

LeSS Huge and the Scrum Master Role

For very large organizations, LeSS Huge introduces Requirement Areas—subsections of the product with dedicated teams. A major challenge in LeSS Huge is preventing silos between these areas. Scrum Masters play a key role in ensuring collaboration across Requirement Areas instead of allowing them to operate like mini-independent teams.

This chapter reinforces that Scrum Masters are not project managers, team leaders, or coordinators—they are change agents. They challenge old ways of working, create transparency, and help teams and organizations continuously improve.

The biggest takeaway? A great Scrum Master doesn’t just “do” Scrum—they cultivate an environment where teams, Product Owners, and the entire organization can thrive. And that’s why, in LeSS, a Scrum Master’s work is never truly “done.”

Chapter 7 – Product

One of the biggest shifts in thinking when moving to LeSS is how organizations define what their product actually is. Most companies still operate with a project mindset, where development is structured around temporary initiatives with clear start and end dates.

But Scrum—and LeSS—are product-focused, not project-focused. This difference is huge because how a company defines its product affects everything: the Product Owner’s responsibilities, how teams are structured, how priorities are set, and even how dependencies are managed.

The chapter starts with a bit of history: early Scrum mistakenly described itself as a project management framework, which led to confusion. But Scrum has never been about managing projects—it’s about developing and sustaining complex products. This change in perspective matters because projects end, but products evolve.

One of the most important decisions in LeSS is defining what the product actually is. This isn’t as obvious as it sounds. In large organizations, different teams, departments, or even business units might have their own definitions of the product, often narrowing it down to the specific component they work on.

But in LeSS, a product should be defined as broadly and customer-centric as possible—because broader definitions lead to better prioritization, more collaboration, and fewer dependencies.

Why Broader Product Definitions Are Better

A narrow product definition usually means teams focus on internal technical components rather than delivering customer value. This creates silos, handoffs, and dependencies between teams, which slows everything down. For example, a platform team might see their “product” as just the backend infrastructure, while another team sees theirs as just the UI. This disconnect means the teams are not aligned on what truly delivers value to the customer.

LeSS encourages defining the product in a way that reflects the actual experience of end-users. Instead of thinking about separate components, teams should think in terms of the entire product or service that customers interact with. This has several advantages:

• Customer-centric prioritization – When all work is visible in one Product Backlog, prioritization becomes clearer. Instead of internal politics deciding which team gets resources, priorities are based on customer impact.
• Reducing dependencies – When multiple teams work on a shared backlog for the entire product, they can take ownership of complete features rather than waiting on other teams to deliver parts of a solution.
• Encouraging collaboration – A broader product definition means teams are working towards the same goal, rather than optimizing only for their small component.
• Avoiding duplication – When similar functionality is needed across different teams, a broader product definition helps prevent teams from building the same feature multiple times in different ways.

How to Define the Product in LeSS

The authors provide a practical way to define a product, using a two-step approach:

1. Start by expanding the definition as broadly as possible – What would end customers say if we asked them what the product is? Are there overlapping teams working on different but related parts of the system? Could combining them remove dependencies?
2. Then, narrow it down only as much as needed – Does the definition still make sense for prioritization? Are there structural constraints that make a broader definition impractical? Could those constraints change over time?

The best product definitions are broad but practical—meaning they are as customer-centric as possible while still being manageable for teams and Product Owners.

The Problem With Projects and Programs

A major theme in this chapter is that companies should stop managing product development like a series of projects. Projects have fixed budgets, deadlines, and scope, and they create artificial constraints that don’t align with how great products are actually built. Instead, LeSS encourages thinking about continuous product development, where teams are always improving and delivering value rather than starting and stopping based on project funding cycles.

Managing products as projects creates several problems:

• Short-term decision-making – When success is measured by project completion rather than product improvement, teams focus on delivering scope rather than solving real customer problems.
• Unnecessary bureaucracy – Since projects are temporary, they require constant planning, funding approvals, and resource allocation, which adds layers of complexity.
• Temporary teams – Projects often rely on assembling teams temporarily, which disrupts long-term learning and team stability.

Instead of managing by projects, LeSS encourages companies to fund and manage long-term product development efforts. This means:

• One Product Owner overseeing the entire product, rather than separate POs for different projects.
• A single, evolving Product Backlog instead of fragmented project backlogs.
• Stable, long-term teams that continuously improve instead of forming and disbanding based on funding cycles.

Examples of Product Definitions in Large Companies

The chapter provides several real-world examples of how different organizations struggled with defining their products correctly. One example is a bank that originally treated “online banking” as a separate product from their core banking services. This led to duplication, synchronization issues, and extra management overhead. When they redefined their product to include both core banking and online services, they removed complexity and improved how teams worked together.

Another example comes from the telecom industry, where companies often treat different hardware and software components as separate products. But when they step back and think about the customer experience, they realize that these components are just parts of one integrated product.

LeSS Huge: When a Product Really Is Too Big

The book acknowledges that in very large organizations, defining a single product can become impractical. This is where LeSS Huge comes in, breaking a massive product into Requirement Areas—sections of the product that teams specialize in while still contributing to the overall goal. However, even in LeSS Huge, the idea is to keep things as broad as possible to avoid unnecessary complexity.

This chapter makes a compelling argument that defining the product correctly is one of the most important decisions in a LeSS adoption. A too-narrow definition leads to silos, dependencies, and inefficiencies. A broader definition enables better prioritization, greater team collaboration, and a more customer-focused approach.

The key message? Stop thinking in projects, start thinking in products. The best organizations are the ones that continuously improve their products over time, rather than treating development as a series of isolated initiatives. In LeSS, the goal is to deliver real value—not just complete tasks.

Chapter 8 – Product Owner

The Product Owner (PO) plays a central role in LeSS, but this role is often misunderstood, especially in large organizations trying to scale Scrum. Many companies mistakenly see the PO as a proxy between teams and stakeholders or as a project manager in disguise. But in LeSS, the Product Owner is much more than that—they are responsible for maximizing the value of the product while ensuring that teams remain closely connected to real customers and users.

In traditional Scrum, a single team has one Product Owner who manages the Product Backlog, prioritizes work, and ensures transparency. However, when multiple teams are working on a single product, the role of the PO must evolve. A key LeSS principle is that there is still only one Product Owner and one Product Backlog, no matter how many teams are involved. This ensures that everyone is working toward a common goal and that prioritization remains customer-driven rather than dictated by internal silos.

A major challenge in scaling Scrum is preventing product fragmentation. In many large companies, teams work on separate components, leading to sandboxes where teams focus only on their small piece rather than the whole product. LeSS avoids this by reinforcing a whole-product focus, where the PO prioritizes based on overall product goals, not just team-specific concerns.

The Real Responsibilities of a Product Owner

In LeSS, the Product Owner is not a bottleneck who clarifies every small detail before teams can work. Instead, they focus on big-picture prioritization, business strategy, and customer engagement. While they own the ordering of the backlog, teams are responsible for clarifying details with users and customers directly. This is a significant departure from traditional setups, where teams rely on the PO for every requirement clarification.

One of the most counterintuitive ideas in LeSS is that the Product Owner should do less, not more. Many organizations overload their POs with administrative work, dependency management, or even acting as a go-between for teams. But the authors argue that a good Product Owner delegates as much as possible to teams and focuses on strategic decision-making, product vision, and external relationships. The more a PO gets involved in the details, the less effective they become at their real job.

To make this work, LeSS encourages teams to interact directly with customers and stakeholders instead of filtering everything through the PO. The PO acts as a connector rather than a gatekeeper, ensuring that teams are exposed to real customer needs and business priorities.

Avoiding the “Fake Product Owner” Trap

One of the common mistakes companies make when adopting LeSS is assigning the PO role to a project manager or program manager. This often leads to a situation where the PO is expected to manage scope, deadlines, and budgets like a traditional project lead. But in LeSS, the PO is not responsible for delivering projects—they are responsible for delivering a great product.

To avoid this, the book suggests a surprising strategy: it’s okay to start with a temporary, “fake” Product Owner while the organization adjusts. This means having someone fill the role early on, even if they don’t have the perfect skills, while the company learns and adapts. However, this person must eventually be replaced by someone with real product ownership, business insight, and decision-making authority.

Product Owners in LeSS Huge

When LeSS scales beyond eight teams, it introduces Requirement Areas, each with an Area Product Owner (APO). While the overall Product Owner still owns the full product vision, APOs help manage prioritization within specific customer-focused areas. However, even in LeSS Huge, there is still only one real Product Backlog, and the APOs do not act as mini-POs managing separate backlogs.

A common anti-pattern in large companies is creating too many layers of Product Owners, Business Analysts, and Managers, which results in slow decision-making and a diluted product vision. LeSS Huge ensures that decision-making remains centralized at the product level while allowing decentralization of detailed backlog refinement to teams.

The Five Key Relationships of a Product Owner

The book emphasizes that to be successful, a Product Owner must manage five critical relationships:

1. With Teams – The PO should not be seen as a superior or decision-maker for teams, but as a peer who guides prioritization and business goals. The best POs encourage teams to take ownership of their work rather than waiting for direction.
2. With Customers & Users – The PO must stay close to real users and actively seek feedback. If the PO spends more time in meetings than engaging with customers, they are missing the point of the role.
3. With Higher Management – Many executives expect traditional reports, milestones, and roadmaps. A great PO helps educate management about agile planning, iterative delivery, and the importance of adaptability rather than committing to fixed scope contracts.
4. With Other Stakeholders – The PO must balance input from marketing, sales, support, and other departments while ensuring that customer value remains the top priority.
5. With Scrum Masters – The best POs actively learn from Scrum Masters, using them as partners in improving organizational agility and fostering self-managing teams.

The Power of Shipping Every Sprint

One of the strongest recommendations in this chapter is that teams should ship at least once per Sprint—not just complete work internally, but actually deliver value to customers. This eliminates the traditional “big release” mindset, increases transparency, and helps teams get real feedback from real users faster.

Shipping frequently also exposes organizational bottlenecks. If shipping every Sprint seems impossible due to dependencies, testing delays, or approval processes, then those issues must be tackled as a priority. The best way to force improvements in development speed, quality, and customer feedback loops is to commit to frequent releases and remove obstacles as they appear.

This chapter reinforces that a Product Owner’s role in LeSS is fundamentally different from what many organizations expect. Instead of acting as a requirement manager, project lead, or backlog administrator, the PO is a strategic leader who maximizes product value and fosters direct connections between teams and customers.

A strong PO in LeSS prioritizes customer impact over internal complexity, trusts teams to manage their own work, and ensures that the organization moves toward continuous, incremental delivery. The biggest takeaway? Let go of control, empower teams, and focus on delivering real value—every Sprint.

Chapter 9 – Product Backlog

The Product Backlog is the backbone of any Scrum-based development process, but in LeSS, it takes on an even greater role. Unlike traditional large-scale setups where each team might have its own backlog, LeSS insists on a single Product Backlog for the entire product, no matter how many teams are involved. This ensures that prioritization remains aligned with the customer, transparency is maximized, and the organization avoids the inefficiencies of fragmented workstreams.

A well-managed Product Backlog helps teams focus on delivering real customer value instead of getting lost in internal complexity. It’s an evolving list—items are constantly added, refined, split, or removed based on learning from each Sprint. The closer an item is to the top, the more detailed it becomes, while lower-priority items remain rough until needed.

Why One Product Backlog?

Many companies, when scaling Scrum, create per-team backlogs. This might seem logical at first, but it quickly leads to problems. Separate backlogs make it harder to prioritize across teams, reduce transparency, and encourage local optimizations rather than whole-product thinking. LeSS avoids this by reinforcing a whole-product focus, where all teams pull from the same backlog, aligning work with the broader product vision rather than individual components.

Minimizing Dependencies Instead of Managing Them

A common issue in large organizations is the obsession with dependency management. Traditional teams create detailed plans to track dependencies, schedule synchronization points, and coordinate across groups. But LeSS challenges this thinking: instead of managing dependencies, why not eliminate them?

For example, LeSS uses feature teams instead of component teams, meaning any team can work across the codebase instead of being limited to a small piece of it. This reduces the need for coordination and allows teams to work autonomously. When external dependencies exist—such as needing a change from another department or vendor—LeSS encourages treating them as constraints to be broken rather than fixed timelines to work around.

A few ways to reduce constraints include:

• Negotiating to get direct access to make necessary changes in other teams’ code.
• Pairing with another team to co-develop the needed feature instead of waiting for handoffs.
• Splitting work into smaller increments that can be implemented without waiting for external changes.

Taking a Bite Instead of Over-Planning

Traditional organizations tend to overanalyze requirements before development begins. They invest months breaking down giant requirements, writing specifications, and creating architectural plans. The irony? No matter how much is planned upfront, surprises always come later. LeSS takes the opposite approach: start small, build something, learn, and adapt.

Rather than waiting for every detail to be understood, teams should “take a bite”—identify a small, meaningful slice of functionality, refine it, and implement it immediately. This approach accelerates learning, reduces waste, and prevents teams from getting stuck in endless analysis paralysis.

How to Handle Large Requirements in the Backlog

When dealing with large items in the backlog, LeSS provides two main options:

• Remove the ancestor item after splitting – This keeps the backlog clean and allows the newly split items to be prioritized independently.
• Keep the ancestor for reference – In complex environments, keeping the original item can help track relationships between new backlog items.

The best approach depends on the size of the backlog and the complexity of the domain. For simple environments, removing the ancestor keeps things clean. For larger, more intricate products, keeping the reference can aid decision-making.

Handling Defects and Improvements in the Backlog

LeSS takes a pragmatic approach to handling defects. In a small-scale setup, defects can be treated like any other backlog item. But in a large organization with hundreds or thousands of defects, putting them all in the backlog would overwhelm prioritization. Instead, teams should:

• Keep critical defects visible at the top of the backlog.
• Use a dedicated team (rotating each Sprint) to fix urgent production issues.
• Work aggressively to reduce defects over time rather than just tracking them.

Similarly, process and technical improvements should be treated like regular backlog items if they require significant investment. However, smaller improvements should be left to the teams to manage autonomously without cluttering the backlog.

More Outcome, Less Output

Many organizations focus on how much work gets done, measuring success by the number of backlog items completed. But this is a vanity metric—what matters isn’t the number of features shipped but the impact those features have on the customer.

LeSS encourages writing backlog items as outcomes instead of tasks. Instead of defining a feature as “Add advanced search filters,” a better backlog item would be “Users can find relevant search results in under two seconds.” This ensures that teams focus on solving problems, not just completing tasks.

LeSS Huge: Managing Backlogs at Scale

In LeSS Huge, where products involve dozens or even hundreds of teams, the single Product Backlog is divided into Requirement Areas. Each area has its own Area Backlog and an Area Product Owner (APO), but there is still only one overall Product Backlog to maintain transparency and alignment.

A few principles for handling backlogs at this scale:

• Keep the number of backlog levels to a maximum of three to avoid excessive complexity.
• When a new massive requirement arrives, consider creating a dedicated Requirement Area rather than forcing it into an existing one.
• Gradually bring more teams into an area rather than flooding it with new people at once.

The Product Backlog in LeSS isn’t just a list of tasks—it’s a strategic tool for managing priorities, reducing complexity, and ensuring that teams deliver real customer value. The key lessons? Keep the backlog simple, avoid unnecessary planning, minimize dependencies, and always prioritize outcomes over outputs. In the end, a well-managed backlog isn’t just about what gets built—it’s about making sure the right things get built in the most effective way possible.

Chapter 10 – Definition of Done

Scrum thrives on transparency, and one of the most effective ways to achieve this is through the Definition of Done (DoD). Without a clear definition, teams often fall into the “I’m almost done” trap—where work feels close to completion but lingers unfinished due to testing, integration, or deployment delays. In LeSS, the Definition of Done provides a clear, binary understanding of whether a backlog item is truly complete. Either it’s done, or it isn’t—there’s no in-between.

The perfect Definition of Done means that by the end of each Sprint, the product is fully shippable to customers, with all necessary work—coding, testing, documentation, and deployment—completed. Achieving this perfect state may not be realistic from the start, especially in large-scale organizations, but the goal is continuous improvement towards this ideal.

The Difference Between Acceptance Criteria and Definition of Done

A common mistake is confusing the Definition of Done with acceptance criteria. Acceptance criteria apply to individual backlog items and define what a specific feature should do. In contrast, the Definition of Done applies universally to all backlog items and ensures that each one meets the required quality, testing, and integration standards. In short, acceptance criteria define “what” a feature must achieve, while the Definition of Done ensures it meets all quality standards.

LeSS Done: Definition of Done at Scale

For a single Scrum team, achieving a strong Definition of Done is easier since the team controls its own scope and workflow. But for large product groups, this becomes more difficult—especially when organizations have long stabilization periods before releases. The authors share a personal example: receiving a bonus for code written two years earlier because the product had finally shipped. This kind of delay is exactly what LeSS aims to eliminate.

A key LeSS rule is that there should be one Definition of Done for the entire product, shared across all teams. However, individual teams can expand their own Definition of Done, adding stricter criteria to improve quality further. This approach ensures alignment across the organization while allowing teams to push themselves towards higher standards.

Creating the Definition of Done

The initial Definition of Done should be established before the first Sprint, typically in the initial Product Backlog Refinement workshop. The authors suggest a four-step approach:

1. Identify all activities required to ship the product – This includes development, testing, documentation, deployment, legal reviews, and anything else needed to release the product to customers.
2. Determine which activities can currently be done within each Sprint – These activities become the initial Definition of Done. If some steps (e.g., regulatory approval or performance testing) cannot yet be completed in a Sprint, they are categorized as Undone Work.
3. Decide how to handle Undone Work – Organizations must determine when and how remaining work will be completed.
4. Plan improvements to expand the Definition of Done – The goal is to gradually eliminate Undone Work by automating tests, improving team skills, and optimizing workflows.

The Problem with Undone Work

If the Definition of Done is weak, Undone Work accumulates, creating a dangerous backlog of tasks that must be completed before release. This leads to false progress—teams believe they are making progress, but the product remains unshippable. The more Undone Work piles up, the greater the risk of delays, last-minute defects, and painful stabilization efforts.

Organizations that fail to tackle Undone Work often resort to release Sprints, where teams stop working on new features to finalize remaining tasks. While sometimes necessary in the short term, release Sprints are a bad idea—they introduce delays, disrupt team momentum, and indicate a weak Definition of Done. The best long-term solution is to continuously expand the Definition of Done until Undone Work is eliminated entirely.

Strategies for Expanding the Definition of Done

Improving the Definition of Done requires systematic change. Some of the most effective strategies include:

• Automation – Manual testing, deployments, and documentation updates should be automated wherever possible.
• Cross-functional teams – Teams should develop skills beyond coding, incorporating testing, security, and documentation into their workflow.
• Eliminating dependencies – If teams rely on external groups for validation, approvals, or testing, they should find ways to bring these capabilities in-house.
• Parallelization – Many organizations assume tasks must be done sequentially (e.g., coding before testing), but in reality, many activities can be done in parallel with the right mindset and tools.

How Different Roles Contribute to the Definition of Done

• Managers must support improvements by removing obstacles, investing in automation, and ensuring teams have the necessary tools.
• Teams should actively push for improvements, using the Retrospective to identify ways to expand their Definition of Done.
• Product Owners must recognize that a weak Definition of Done creates risks and delays, impacting their ability to deliver value to customers.
• Scrum Masters play a crucial role in driving continuous improvement, ensuring that teams don’t become complacent and always strive for better ways of working.

The Definition of Done is one of the most powerful tools in LeSS. A strong DoD leads to faster releases, fewer defects, and greater transparency, while a weak DoD results in delays, hidden risks, and painful stabilization periods. The ultimate goal? A Definition of Done that allows teams to release working software every Sprint—or even more frequently.

Chapter 11 – Product Backlog Refinement

In traditional Scrum, Product Backlog Refinement (PBR) is an ongoing activity that helps ensure that work is well understood and ready for upcoming Sprints.

In LeSS, the concept expands to include a broader focus on multi-team collaboration, learning, and ensuring a shared understanding of the product. This chapter explains how refining the backlog should be an interactive, team-driven effort rather than a separate task owned by the Product Owner or business analysts.

Why PBR is Essential

One of the most important points in this chapter is that refinement isn’t just about breaking work down into smaller pieces—it’s about creating a shared understanding between the teams and the people who will use the product. Without proper refinement, Sprint Planning becomes chaotic, teams make assumptions about what needs to be built, and inefficiencies pile up.

Interestingly, the book challenges the common assumption that the Product Owner should do all the refinement work alone. Instead, it argues that refinement should be a collaborative effort, involving teams working directly with customers and stakeholders. This creates better alignment and reduces miscommunication.

Types of Product Backlog Refinement in LeSS

In a single-team Scrum, refinement is typically handled by the team alone. But in a scaled environment, multiple teams working together require different approaches. The book introduces four key types of refinement sessions in LeSS:

• Overall PBR – A high-level discussion that helps align all teams on the bigger picture and decide which teams should refine which items.
• Multi-Team PBR – Two or more teams refine a set of items together before deciding which team will implement what, promoting shared knowledge and coordination.
• Single-Team PBR – Traditional backlog refinement where one team prepares backlog items they expect to work on.
• Initial PBR – A one-time event when LeSS is first adopted, helping teams create their initial Product Backlog and refine enough items to begin working effectively.

The chapter emphasizes that multi-team PBR is often preferable to single-team refinement because it broadens the teams’ understanding and improves flexibility in implementation.

Splitting and Estimating Work
A core part of PBR is breaking down large backlog items into smaller, more manageable pieces. The book offers insights into how teams can effectively split backlog items while maintaining a customer-centric approach. Instead of breaking down work into technical steps (which often leads to inefficiencies), teams should aim to split features in a way that delivers tangible value to users.

Estimation also plays a role, but the book warns against overcomplicating it. Instead of striving for perfect estimates, teams should focus on relative effort and use simple techniques to align their understanding. The goal is to refine work just enough to be actionable—without getting bogged down in unnecessary details.

LeSS and the Challenge of Multi-Site PBR

For organizations with distributed teams, backlog refinement presents additional challenges. The book suggests several techniques, such as using shared digital whiteboards for splitting work, employing Specification by Example to ensure clarity, and using video conferencing to maintain engagement. The key takeaway is that remote teams should still prioritize direct collaboration rather than relying on documents and tools alone.

The essence of LeSS Product Backlog Refinement is ensuring that teams don’t just “take orders” from a central figure but are actively engaged in understanding what needs to be built and why. By involving the entire team in refinement, organizations can reduce handoffs, increase shared learning, and ultimately build better products with less waste. The chapter reinforces the idea that backlog refinement is not just a preparatory step but a continuous learning process that shapes how teams work together.

Chapter 12 – Sprint Planning

Sprint Planning in LeSS is all about simplicity, collaboration, and maintaining a whole-product focus. In many large-scale organizations, planning tends to become overly complex, filled with dependency management meetings, rigid allocations, and excessive forecasting. LeSS challenges this traditional approach by keeping planning lightweight and empowering teams to take ownership of their work.

Sprint Planning in LeSS follows the same fundamental principles as in single-team Scrum: deciding what to work on and how to do it. However, with multiple teams working on the same product, coordination becomes critical. The book introduces a two-part Sprint Planning structure to balance alignment with autonomy:

Sprint Planning One (SP1) is a shared session involving the Product Owner and all teams (or their representatives). Here, teams select backlog items to work on, discuss dependencies, and identify opportunities for collaboration. The key principle is deciding as late as possible, allowing teams to make informed decisions based on the most up-to-date information.

Sprint Planning Two (SP2) happens separately for each team. This is where they discuss the technical details of implementation, create their Sprint Backlogs, and plan their work in more depth. Some teams may choose to conduct SP2 together in a multi-team Sprint Planning session if their work is strongly related, promoting instant coordination.

Flexibility

One of the most important takeaways from this chapter is that Sprint Planning should be simple and flexible. Traditional project management approaches treat planning as a rigid process, but LeSS emphasizes empirical process control and continuous improvement. Each Sprint provides an opportunity to refine the planning process and adapt it to the needs of the teams.

A major point of discussion is who decides which teams work on which backlog items. Instead of the Product Owner assigning work, LeSS encourages teams to self-organize and make these decisions themselves. This fosters ownership, promotes cross-team collaboration, and reduces bottlenecks. The Product Owner’s role in planning is to clarify priorities, not to dictate how teams should distribute work.

Dependency Management

The chapter also challenges the conventional wisdom around dependency management. In traditional scaling approaches, entire meetings are dedicated to identifying and mitigating dependencies. In LeSS, teams focus on reducing dependencies rather than managing them. This is achieved by having feature teams that can work across the system, breaking down barriers that would otherwise create handoffs and delays.

Avoiding Software Tools

Another interesting point in this chapter is the recommendation to avoid software tools for Sprint Backlogs. The authors argue that physical visual management—using sticky notes or whiteboards—encourages more collaboration and discussion than tracking Sprint Backlogs in Jira or other digital tools. When teams rely on software tools, the risk of micromanagement and tracking increases, which can stifle agility.

Sprint Planning on LeSS Huhe

For LeSS Huge, Sprint Planning happens per Requirement Area rather than for the entire product at once. However, to maintain whole-product alignment, the book suggests a Product Owner Team Meeting before Sprint Planning. This ensures that Area Product Owners stay aligned on the bigger picture and aren’t making decisions in isolation.

In essence, this chapter reinforces that planning should be lightweight, flexible, and team-driven. The best way to ensure smooth Sprint execution isn’t to overanalyze dependencies or micromanage teams—it’s to create an environment where teams can self-organize, communicate freely, and focus on delivering real value.

Chapter 13 – Coordination & Integration

One of the biggest challenges in large-scale development is making sure multiple teams are aligned, collaborating effectively, and integrating their work smoothly.

In a single Scrum team, this happens naturally—team members talk, share knowledge, and continuously integrate their work. But when multiple teams are involved, coordination often becomes formalized, with scheduled meetings, dependency tracking, and rigid communication structures.

LeSS takes a different approach: instead of adding more processes, it encourages teams to self-organize and coordinate in the simplest way possible—by just talking.

The book highlights that in a well-functioning Scrum team, you can actually hear the collaboration. There’s constant discussion, problem-solving, and knowledge-sharing happening throughout the Sprint. The challenge in LeSS is how to create this same spontaneous coordination across multiple teams.

Why Coordination & Integration Matter

At scale, coordination and integration are closely connected. Integration requires coordination, and coordination results in integration. Without it, teams work in silos, leading to fragmented codebases, misaligned priorities, and painful last-minute integration problems. In traditional organizations, this is often handled by centralized coordination teams or project managers, but LeSS prefers decentralized, team-driven coordination to avoid bottlenecks and delays.

The Best Coordination Method: Just Talk

One of the boldest ideas in this chapter is that the best coordination method is simply talking to each other. Instead of relying on formal meetings or structured processes, LeSS encourages teams to notice when they need to coordinate, stand up, and go talk to the other team. This might sound overly simplistic, but the book argues that the more formal coordination methods in place, the less actual coordination happens. Why? Because people feel like they must wait for the “correct” channel (like a Scrum of Scrums meeting) instead of just solving the issue immediately.

This shift in mindset reframes the real problem: instead of asking, “What coordination methods should we use?” the better question is, “How do teams realize they need to coordinate?” LeSS focuses on creating an environment where teams naturally notice when coordination is needed, instead of relying on pre-planned synchronization meetings.

Creating a Coordination-Friendly Environment

For decentralized coordination to work, organizations need to create an environment where informal communication thrives. This includes:

• Teams owning coordination: Instead of a project management office or integration team handling coordination, each team is responsible for ensuring smooth collaboration and integration.
• Feature teams with a common goal: When teams work on separate components, they naturally become disconnected. In contrast, feature teams that share a goal have built-in reasons to coordinate.
• A whole-product focus: If teams are only concerned with their piece of the system, they won’t prioritize cross-team collaboration. A shared Sprint, Product Backlog, and integrated product increment keep everyone aligned.
• A supportive physical and technical environment: Open spaces that encourage face-to-face discussions, shared digital communication tools, and social coding spaces like GitHub all help teams stay connected.

Preferred Coordination Methods in LeSS

To promote decentralized coordination, the book introduces several simple but powerful techniques:

• Communicate in code: Instead of waiting for formal meetings to discuss dependencies, teams integrate their code frequently and discover coordination needs through version control notifications.
• Cross-team meetings: While LeSS prefers informal coordination, occasional structured multi-team design workshops and discussions can help align efforts.
• Open Space events: A regular gathering where teams bring up challenges and discuss solutions, fostering shared learning.
• Component mentors: Experienced developers act as informal coaches, helping teams understand critical areas of the codebase.
• Travelers: Some team members rotate between teams each Sprint, spreading knowledge and strengthening informal relationships.

Why Centralized Coordination Fails

The book argues that traditional Scrum of Scrums meetings and other centralized coordination techniques often create more problems than they solve. These meetings can slow down decision-making, create bottlenecks, and reinforce the idea that coordination is someone else’s responsibility. Instead, LeSS recommends letting teams handle coordination themselves in real time.

However, it acknowledges that some structured coordination is sometimes necessary, especially in very large groups. The key is finding the right balance between structured and emergent coordination, without letting processes take over.

This chapter makes a strong case for trusting teams to self-organize and take responsibility for coordination and integration. Instead of adding layers of processes, organizations should focus on removing barriers to direct communication, encouraging informal collaboration, and fostering a whole-product mindset. The main takeaway? Great coordination isn’t about meetings and reports—it’s about making it easy for teams to just talk.

Chapter 14 – Review & Retrospective

At the core of Scrum is empirical process control—the ability to inspect, adapt, and continuously improve. This principle is deeply embedded in Sprint Reviews and Retrospectives, which help teams and organizations learn, refine their approach, and deliver better results over time. In LeSS, these practices are scaled to ensure that learning happens across multiple teams, not just within them.

The Sprint Review in LeSS

The Sprint Review isn’t just about showcasing work—it’s about learning together. In many large organizations, reviews become status reporting meetings, where teams present what they did, executives nod, and nothing really changes. LeSS challenges this mindset by making Sprint Reviews customer-centric, transparent, and interactive.

In LeSS, there is one product Sprint Review for all teams. This ensures that stakeholders, customers, and teams come together to discuss what’s been built, explore the market situation, and decide what to do next. The book stresses that many teams fear real transparency, as it exposes messy realities—unfinished work, unexpected challenges, and shifting priorities. But true agility requires radical transparency, and the Sprint Review is a critical moment for embracing it.

A unique approach in LeSS is the Sprint Review Bazaar, which transforms the review into something like a science fair. Instead of a passive presentation, teams set up different areas where stakeholders can interact with the new product increment, ask questions, and provide hands-on feedback. This encourages real engagement rather than superficial approval. The bazaar-style format works particularly well for large-scale product development, where multiple teams contribute to a single product.

The book provides a structured approach for running an effective Sprint Review Bazaar:

1. Create different exploration areas where stakeholders can interact with specific features.
2. Encourage active participation—no passive demos; users should get hands-on experience.
3. Record feedback and questions using physical cards or digital tools.
4. Facilitate a discussion led by the Product Owner to analyze feedback and decide next steps.

This approach shifts the focus from “Did we complete the backlog items?” to “What did we learn, and what should we do next?”

The Overall Retrospective in LeSS

While each team has its own Sprint Retrospective, LeSS introduces an Overall Retrospective that focuses on cross-team and system-wide issues. This meeting is attended by Product Owners, Scrum Masters, team representatives, and managers (if applicable). The goal is not just to improve individual teams, but to improve the system as a whole.

The book highlights that many organizations struggle with systemic issues—rigid deployment processes, slow decision-making, or structural bottlenecks. The Overall Retrospective provides a dedicated space to address these problems and experiment with solutions. Instead of treating improvement as a once-a-year initiative, LeSS encourages continuous improvement towards perfection.

One of the most fascinating points in this chapter is the importance of system thinking. Many teams focus on local optimizations—trying to improve within their own bubble. However, LeSS emphasizes that the system is not just the sum of its parts. A great Overall Retrospective doesn’t just collect feedback from teams—it actively challenges assumptions, maps dependencies, and looks at the bigger picture.

To improve system-wide agility, the book suggests using systems modeling techniques such as causal loop diagrams. These help organizations visualize how different factors influence each other, making it easier to identify hidden constraints and unintended consequences.

The Sprint Review and Overall Retrospective in LeSS aren’t just meetings—they are powerful mechanisms for driving organizational change. The book argues that many companies hold these events but fail to use them effectively. They turn reviews into status meetings and retrospectives into complaint sessions. LeSS pushes organizations to rethink these practices, making them deeply interactive, brutally transparent, and relentlessly focused on learning.

The key takeaway? Inspect, adapt, and repeat—forever. The moment a company stops improving, it stops being agile.

Overall, Large-Scale Scrum book is a valuable resource for professionals in the software development and project management fields, particularly those interested in scaling agile practices, organizational design, and leadership and a practical framework for implementing LeSS, a framework that helps organizations achieve greater agility, faster delivery, and higher quality.

4 Key Ideas From Large-Scale Scrum

6 Main Lessons From Large-Scale Scrum

My Book Highlights & Quotes

Crucially, these Teams are feature teams—true cross- functional and cross-component full-stack teams that work together in a shared code environment, each doing everything to create done items.

LeSS shows how to handle large and complex development. Self-managed teams are not just tiny curiosities. They can manage vast international operations of great technical complexity. The practices are not only scalable, unlike bureaucracy, they are scalable without sclerosis.

LeSS continues the process of fundamentally reinventing management by incorporating the hard-won lessons of experience over more than a decade in scaling the management methods of Agile and Scrum. It shows how to cope with immense complexity by creating simplicity.

And like Scrum, LeSS is not a process or a technique for building products. Rather, it is a framework within which processes and techniques can be adapted to meet the needs of the particular situation. It aims to make clear how product management and development practices can enable continuous improvement that adds value to customers.

Rather than providing fixed answers, LeSS provides the starting point for understanding and adopting its deeper principles. Instead of asking, “How can we do Agile at scale in our complex hierarchical bureaucracy?” it asks a different and deeper question is, “How can we simplify the organization, and be Agile?”

Conclusion

To wrap it up, Large-Scale Scrum by Craig Larman and Bas Vodde is a fantastic guide for scaling Scrum in large organizations.

With practical insights, real-world case studies, and actionable strategies, it gives you everything you need to navigate the challenges of adopting agile on a larger scale.

Whether you’re already experienced with agile or just starting with Scrum, this book offers priceless guidance on boosting organizational agility and driving business success.

I am incredibly grateful that you have taken the time to read this post.

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support and appreciation tangibly?

Creating these posts takes time, effort, and lots of coffee—but it’s totally worth it!

If you’d like to show some support and help keep me stay energized for the next one, buying me a virtual coffee is a simple (and friendly!) way to do it.

Do you want to explore more?

Check my main categories of content below:

• Book Notes
• Career Development
• Essays
• Explaining
• Leadership
• Lean and Agile
• Management
• Personal Development
• Project Management
• Reading Insights
• Technology

Navigate between the many topics covered in this website:

Agile Art Artificial Intelligence Blockchain Books Business Business Tales C-Suite Career Coaching Communication Creativity Culture Cybersecurity Decision Making Design DevOps Digital Transformation Economy Emotional Intelligence ESG Feedback Finance Flow Focus Gaming Generative AI Goals GPT Habits Harvard Health History Innovation Kanban Large Language Models Leadership Lean Learning LeSS Machine Learning Magazine Management Marketing McKinsey Mentorship Metaverse Metrics Mindset Minimalism MIT Motivation Negotiation Networking Neuroscience NFT Ownership Paper Parenting Planning PMBOK PMI PMO Politics Portfolio Management Productivity Products Program Management Project Management Readings Remote Work Risk Management Routines Scrum Self-Improvement Self-Management Sleep Social Media Startups Strategy Team Building Technology Time Management Volunteering Web3 Work

Do you want to check previous Book Notes? Check these from the last couple of weeks:

• Book Notes #125: Revenge of the Tipping Point by Malcolm Gladwell2025-03-21
• Book Notes #124: Radical Candor by Kim Scott2024-09-04
• Book Notes #123: The Personal MBA by Josh Kaufman2024-05-09
• Book Notes #122: The First 20 Hours by Josh Kaufman2024-05-02
• Book Notes #121: A World Without Email by Cal Newport2024-04-24

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support tangibly? A virtual coffee is a small but nice way to show your appreciation and give me the extra energy to keep crafting valuable content! Pay me a coffee: