
Scaling Scrum is one of the biggest challenges organisations face when moving beyond small, single-team product development. Large-Scale Scrum: More with LeSS by Craig Larman and Bas Vodde tackles this challenge head-on. Rather than layering management structures or adding complexity, it focuses on extending the principles of Scrum while keeping things as simple as possible. The book’s title itself – “More with LeSS” – captures this philosophy perfectly. It is not about doing more work with fewer people but about creating more value by simplifying systems, empowering teams, and reducing waste.
LeSS provides a framework for applying Scrum at scale, supporting multiple teams working together on one product. It is a direct extension of Scrum, not a new methodology, and it retains the core values of empiricism, self-management, and transparency. The book draws from decades of real-world experience in large product organisations, providing clear principles, structures, and experiments that have been proven in practice.
The Core of LeSS
At its heart, LeSS is about taking Scrum’s simplicity and scaling it up without losing its spirit. The authors emphasise that most organisations, when scaling, instinctively add layers of management, coordination roles, or process complexity. This often slows things down, disconnects teams from the customer, and reduces ownership. LeSS does the opposite. It asks, “What can we remove?” rather than “What can we add?”
LeSS is built around the same principles as Scrum: empiricism, transparency, and continuous improvement. It extends these across multiple teams working on the same product, maintaining a single Product Backlog, one Product Owner, and one Definition of Done. Each team delivers a potentially shippable increment every Sprint, just as in standard Scrum.
The idea of “more with less” is rooted in lean thinking. It means removing waste, optimising the whole system rather than local parts, and focusing relentlessly on delivering customer value. This approach keeps the organisation agile and adaptive, even at scale.
Two Frameworks for Scaling
The authors describe two frameworks under the LeSS umbrella.
The first is LeSS, designed for two to eight teams working on a single product. It is intentionally minimal, keeping the rules and roles light while encouraging experimentation and adaptation.
The second is LeSS Huge, which supports products involving hundreds or even thousands of people. It builds on LeSS but adds just enough structure to coordinate larger systems. LeSS Huge introduces an additional role called the Area Product Owner, who manages a specific area of the product within the overall Product Backlog. Even in this larger framework, simplicity and learning remain the guiding principles.
Both frameworks rely heavily on cross-functional, feature-focused teams that are capable of delivering end-to-end customer value. These teams are stable and long-lived, avoiding the inefficiency of constantly reorganising around projects.
Organising Around Customer Value
Traditional organisations often structure teams around components, technologies, or functions. This leads to silos, handoffs, and long feedback cycles. LeSS flips this model. It organises teams around features that deliver direct customer value. Each team is capable of developing, testing, and delivering complete features, without depending on other teams to finish the work.
The benefit of this structure is immediate. Teams are closer to the customer, understand the product as a whole, and can make decisions quickly. This reduces coordination overhead and improves quality.
A key idea in the book is the concept of “whole-product focus.” All teams share responsibility for the same product and work from one Product Backlog. This keeps everyone aligned around a common goal and prevents sub-optimisation where teams optimise for their own part rather than the customer’s outcome.
The authors caution that this approach requires courage. It often means dismantling existing hierarchies, merging teams, and removing middle management layers. But the reward is a more empowered organisation where decisions are made where the knowledge is – in the teams.
The Role of the Product Owner
LeSS maintains the same Product Owner role as in Scrum but expands its scope. The Product Owner in LeSS represents the product as a whole, not individual teams. They prioritise the single Product Backlog, ensuring that all teams are aligned with the most valuable work.
To handle this effectively, the Product Owner focuses on vision, strategy, and maximising value, not micromanaging team-level work. In larger setups, they may rely on Area Product Owners to manage parts of the backlog in LeSS Huge, but they still own the overall product direction.
This approach simplifies decision-making and maintains product coherence. It also demands a strong Product Owner who can say no, make trade-offs, and work closely with customers and teams.
The authors stress that the Product Owner is not a requirements manager. They are a value maximiser who helps teams understand customer needs, experiment, and learn. They collaborate directly with teams rather than operating through layers of intermediaries.
The Role of Management
LeSS redefines management. In traditional structures, managers coordinate, plan, and direct teams. In LeSS, their role shifts towards enabling, teaching, and improving systems. Managers focus on developing people, nurturing a learning environment, and removing organisational impediments.
This is a significant cultural change. Managers become servant leaders, helping teams grow their capabilities and encouraging continuous improvement. Their job is to make themselves less essential over time by creating self-managing teams that can inspect and adapt independently.
The book emphasises that management is not removed but transformed. Instead of directing work, managers work on the system. They support organisational design, help align structures with principles, and coach others in lean and agile thinking.
Coordination Without Command
A common fear when scaling Scrum is that coordination will collapse without traditional control mechanisms. LeSS addresses this through transparency and shared learning rather than hierarchy.
Teams coordinate naturally through shared events, artefacts, and communication. They attend the same Sprint Planning, work from the same backlog, and share the same Definition of Done. Daily coordination happens informally between teams, while structured meetings like Overall Retrospectives ensure that improvements are applied system-wide.
LeSS encourages what it calls “just enough coordination.” Too little leads to chaos, but too much stifles autonomy. By making work visible and fostering direct communication between teams, coordination emerges naturally.
The authors argue that the best coordination happens through people talking to each other, not through reports or dashboards. When teams are close to each other physically or virtually, and share a common understanding of the product, dependencies become manageable.
Continuous Improvement and Learning
LeSS places learning at the centre of scaling. Each Sprint is an opportunity to inspect and adapt not only the product but the entire system. This learning mindset extends beyond the team level to the whole organisation.
Retrospectives are vital. Teams hold their own Retrospectives, and representatives gather in an Overall Retrospective to discuss systemic issues. These discussions often lead to changes in structure, policies, or even leadership behaviour.
The authors introduce the concept of “Go See,” borrowed from lean manufacturing. Leaders and managers are encouraged to spend time with teams to understand the real work and the real problems. Decisions should be based on direct observation, not reports or assumptions.
This approach helps maintain transparency and keeps improvement grounded in reality. Over time, the organisation becomes more resilient, capable of adapting quickly to change, and continuously improving.
Experiments Over Prescriptions
A defining feature of LeSS is its emphasis on experiments rather than rigid rules. The authors provide a set of experiments – practical techniques and patterns – that organisations can try, learn from, and adapt. These range from changing team structures to redesigning office spaces.
For example, one experiment encourages eliminating individual performance appraisals, as they often damage collaboration. Another suggests rotating team members occasionally to spread knowledge and avoid silos. Each experiment is grounded in lean thinking and empirical evidence.
This experimental approach reinforces the idea that scaling is a learning journey, not a checklist. What works in one context may not work in another. By treating changes as experiments, organisations reduce fear and increase engagement.
LeSS and Organisational Design
Perhaps the most radical part of LeSS is its view of organisational design. The authors argue that many scaling problems stem not from processes or tools but from structure. If teams are built around components or functions, coordination becomes a nightmare. If performance is measured individually, collaboration suffers.
LeSS recommends redesigning organisations around products and customers. Cross-functional teams take ownership of end-to-end delivery, and roles that do not add value – such as project managers or coordinators – are reduced or repurposed.
This can be uncomfortable, as it challenges long-standing structures. But the outcome is a more flexible organisation aligned around value delivery.
The authors summarise this idea through the principle “structure influences behaviour.” If the structure encourages silos, people will act in siloed ways. If it encourages collaboration, people will collaborate.
Technical Excellence and Quality
Scaling agility requires more than process changes. It also demands technical excellence. LeSS emphasises strong engineering practices such as automated testing, continuous integration, refactoring, and collective code ownership. Without these, scaling leads to integration pain and fragile systems.
Each team must be capable of delivering a shippable increment at the end of every Sprint. This enforces discipline and drives better design decisions. The shared Definition of Done ensures that all teams deliver to the same quality standard, avoiding hidden technical debt.
The authors point out that quality cannot be “added later.” It must be built in from the start. High-quality systems are easier to adapt and scale, enabling faster learning and innovation.
The Essence of LeSS
The essence of LeSS can be summarised in its guiding principles:
- Large-Scale Scrum is Scrum.
- Empirical process control is key.
- Less process enables more learning.
- The organisation must be designed for transparency and collaboration.
- Continuous improvement is a shared responsibility.
LeSS challenges organisations to remove unnecessary complexity, trust teams, and focus relentlessly on customer value. It is both simple and hard. Simple because the framework itself is lightweight. Hard because it demands deep organisational change, humility, and patience.
Why LeSS Matters
In a world where many companies are adding layers of process and bureaucracy in the name of “Agile transformation,” LeSS offers a refreshing reminder of what Agile was meant to be. It is not about scaling control but scaling learning.
By keeping the principles of Scrum intact and extending them thoughtfully, LeSS allows large organisations to remain fast, adaptive, and customer-focused. It helps restore the connection between teams and the people they serve, fostering an environment where innovation can thrive.
For organisations serious about agility, Large-Scale Scrum: More with LeSS provides both a framework and a philosophy – a way to grow without losing simplicity, humanity, and focus on value.










