Large Scale Scrum: Comprehensive Overview Of LeSS

Large Scail Scrum 1

Agile 101

Introduction to Large Scale Scrum (LeSS)

Large Scale Scrum, LeSS for short, has caught your attention. Maybe you’ve just started with Scrum but are already thinking about the next steps.

Maybe you’re a veteran of single-team Scrum, looking to expand it to other teams.

Less Structure Overview 1
Or maybe you already have multiple teams following Scrum and are experiencing some of the challenges coordinating multiple teams working on a single product. Either way, you want to know more about Large Scale Scrum to see whether it’s a fit for you. Well, you’re in the right place. In this article, you’ll get a comprehensive but succinct overview of LeSS so you can make an informed decision without getting lost in all the details.

Let’s Start:

  • Brief Overview
  • Brief History
  • LeSS Rules
  • LeSS Principles
  • LeSS Practices
  • LeSS versus single-team Scrum
  • Planning and Budgeting
  • Coordination
  • Queueing Theory
  • Roles and Responsibilities
  • LeSS Huge
  • Organizational Structure
  • Key Meetings
  • Sprint Planning
  • Product Backlog Refinement
  • Retrospective
  • Common Pitfalls
  • Getting Started

Brief Overview

Large Scale Scrum, LeSS for short, is a scaled agile framework that guides you in adopting and applying agile at scale.

LeSS keeps Scrum’s core intact: exposing organizational design weaknesses through a minimal framework and letting you solve the complex problems inherent in development, through empirical process control and continuous improvement.

LeSS seeks to apply the “principles, purpose, elements, and elegance of Scrum in a large-scale context, as simply as possible.” Among other principles and practices, it uses Lean Thinking and Systems thinking to keep the framework and your overhead as light as possible and still guide you in important decisions.

In fact, Large Scale Scrum defines two frameworks:

  • LeSS lets you scale Scrum to up to eight teams of up to eight people each.
  • LeSS Huge helps you scale Scrum up to a few thousand people on a single product.

By picking the one that fits your size, you won’t burden yourself with unnecessary ballast.

To clear up any confusion: the word LeSS means both Large Scale Scrum in general and the framework for smaller organizations.

Brief History

Back in 2005, Craig Larman and Bas Vodde created Large Scale Scrum working together at Nokia Siemens Networks applying Agile and Scrum to very large and multisite product development.

Since then, product groups applying LeSS run the gamut in size, from as small as two teams to as large as 2500 people.

Principles, and Practices

LeSS, more than any other scaled agile framework, is about following Scrum and getting you to make your own decisions guided by the principles and practices that also guided Craig Larman and Bas Vodde during its creation.

Applying LeSS means:

  • Getting clear on the few rules it considers a must.
  • Following the guidance of its 10 Principles in making your decisions.
  • Structuring your product group according to its description of how to organize.
  • Following its description of Scrum Sprints in a large-scale context.
  • Applying the practices it defines for Technical Excellence.
  • Taking to heart what it has to say about adopting LeSS successfully.
  • Heeding what it has to say about coordination and management in a new reality.

Rules

LeSS has only a few rules but they are crucial. They specify what LeSS considers a must for your organizational structure, product management, and how to work with multiple teams in a single product-level Sprint.
Less Overview Diagram 1

For everything else you’re free to make your own decisions guided by the same principles that guided LeSS’ authors in its creation.

I won’t repeat the LeSS rules here, but I do advocate keeping them front and center at all times so they can be referred to often (they’re only two pages!).

Principles

LeSS can be lean in rules because of its ten principles to guide your decisions for everything it doesn’t consider essential (a must).

Principles
  • Large-Scale Scrum is Scrum
  • More with LeSS
  • Systems Thinking
  • Lean Thinking
  • Empirical Process Control
  • Transparency
  • Continuous Improvement Towards Perfection
  • Customer-Centric
  • Whole Product Focus
  • Queueing Theory

Principle 1: Large-Scale Scrum is Scrum

LeSS scales Scrum itself without adding different scaling processes, artifacts or events.

Principle 3: Systems Thinking

Systems thinking helps everyone across your organization (not just product development) think about what’s happening and helps decision makers avoid mistakes from “common sense” and “quick-fixes.”

Principle 4: Lean Thinking

A good analogy for Lean Thinking is “Watch the baton, not the runners” [in a relay race]. It means productivity improvements are not sought in resource utilization (busy-ness) but in removing waste (material and work/idle time) from the production process. In other words: speeding up the baton.

Principle 5: Empirical Process Control

Feedback Loop
Empirical process control helps you “fail forward” by getting you to produce working increments of your product in short cycles, and to adapt the product and the way you create it by inspecting them every cycle.

Principle 6: Transparency

Transparency helps you to address the weaknesses in processes, tools, techniques, environments, sites, policies, people, groups, reward systems, etc. up and down your entire organization.

Principle 7: Continuous Improvement Towards Perfection

Continuous improvement toward perfection says three things:

  • “It’s okay not to be perfect right now.”
  • “Yet you want and need to continually strive to get there.”
  • “You need to be okay with never getting there because there’ll always be something else to improve.”

Principle 8: Customer Centric

In LeSS the aim is to scale and still keep customer focus throughout the organization so teams at the ground floor don’t end up divorced from the value their work delivers to the customers.

Principle 9: Whole Product Focus

LeSS advocates to keep all teams focused on the whole product, not just their tiny part of it.

Principle 10: Queueing Theory

Queueing theory helps improve work flow through your development and portfolio processes with guidance on eliminating queues and managing the ones that can’t be eliminated. Queues and inventory don’t just exist in physical manufacturing, they’re present in product development too.

For example:

  • The portfolio of projects and products is a queue.
  • The product backlog is a queue.
  • The Sprint backlog is a queue.
  • Every status in a workflow is a queue where work waits to be picked up for the next step.
  • An overworked integration server is a queue.
  • Shared test environments are queues.

And there’s also a lot of inventory in those queues.

  • Finished design documents waiting to be implemented.
  • Any code not yet released, or kept from customers by feature flags, at varying stages of completion.
  • Feature branches are both inventory and a queue of sorts.

Practices

Technical Excellence Overview
True flexibility (i.e. agility) only happens when you can make changes to your product quickly, easily, and flexibly. That means technical excellence for which LeSS names 10 engineering and design practices:
  • Continuous integration
  • Continuous delivery
  • Architecture & Design
  • Clean code
  • Unit testing
  • Test-Driven Development (TDD)
  • Thinking about testing
  • Test automation
  • Acceptance testing
  • Specification by example
These practices are all interrelated, they depend on and amplify each other.
You can read more about continuous integration, delivery, and deployment and their relationship with unit testing, test automation and automated acceptance testing in What is CI/ CD? How it Helps Teams Deliver Better Software, Faster. Rather than big up-front architecture and design, Agile and LeSS take an evolutionary approach, this requires all the other practices to keep code easy to change and the teams confident in changing the code’s architecture and design without affecting function. Specification by example, as used in user stories or through Behavior Driven Development, facilitates specifications a computer can execute which make test automation feasible at all levels, including acceptance testing.

Similarities and Differences

LeSS versus single-team Scrum

Instead of using Scrum at the team level and applying different methods to plan for, coordinate, and learn with multiple teams, LeSS scales Scrum itself and keeps its core intact.

But there are differences.

Tdd Bdd Difference1

The ones that LeSS itself reports:

  • LeSS Teams are what Scrum sees as the development team. Scrum’s Scrum team is not a concept in LeSS.
  • LeSS talks about self-managing rather than self-organizing teams.
  • LeSS sees the Scrum Master role as a dedicated full-time job. However, a Scrum Master can guide and coach up to three teams to see the larger product and production system.
  • LeSS doesn’t require the Product Owner to participate in every team’s Daily Scrum or Retrospective.
  • LeSS splits Sprint Planning in two parts.
  • LeSS expects Backlog Refinement to be a formal event (it’s an activity in Scrum).
  • LeSS doesn’t require Sprints to have a Sprint Goal, though it considers it a useful practice.

In addition:

  • The Product Owner is not required to attend each teams’ Product Backlog Refinement. Teams conduct the refinement with customers and users, freeing the Product Owner to do more forward looking work.
  • LeSS adds an overall Retrospective for all teams together.
  • LeSS specifically addresses what role managers can still play and how they can still add value even when their responsibilities are largely taken over by the Product Owner or delegated to the Teams.
  • Where Scrum says three to nine in a team or team of teams, LeSS recommends a maximum of eight. It’s based on observations during many LeSS adoptions.

Planning and Budgeting

LeSS sticks with the Scrum per-sprint planning cycles. There are no overarching planning cycles or events such as quarterly PI planning in SAFe.
Image1 58
LeSS’ whole product focus and emphasis on stable long-lived Feature Teams, means a product-oriented approach is a natural fit for planning and budgeting. The cost per year follows from the number and size of Feature Teams and the size of the Product Owner team. The question that remains is when specific fixes and feature updates will become available. This can be taken, in true Scrum fashion, from the Product Backlog prioritization and your experience with how much the teams can handle in a Sprint.

Coordination

LeSS and LeSS Huge both avoid ritualizing coordination between teams into events. LeSS explicitly states: “Coordination: Just Talk, Communicate in Code, Travelers, Open Space, and Communities.”

In other words:

  • Cross-team collaboration as needed on architecture, design, modeling, etc.
  • Use the source code as a fountain of knowledge about the product.
  • Use Open Space “technology” to share information, knowledge, and experience.
  • Promote cross-team interactions through observing each other’s Daily Scrums and simply sitting having one or more members sit with another team (Travelers).
  • Form self-organized Communities of Practice (CoP) of volunteers with a shared interest. Support the informal leaders, CoP coordinators, that naturally rise in the group because of their more than average interest in the topic.
  • Form self-organized Communities of Practice (CoP) of volunteers with a shared interest. Support the informal leaders, CoP coordinators, that naturally rise in the group because of their more than average interest in the topic.

Queueing Theory

LeSS is the only scaled agile framework that explicitly accepts all the implications of queueing theory and advocates it to guide your improvement decisions. That means eliminating queues, not just managing them through managing Work in Progress (WIP) levels. LeSS values reducing WIP levels for many reasons, but calls invoking Little’s Law to say that it automatically leads to a reduction in cycle times, a myth. This is because the proof in Little’s Law, as LeSS states: “depends on conditions and assumptions that are in no way guaranteed to be or even commonly true in high-variability domains such as software”. This is certainly true when measured over relatively short (or mathematically) finite periods of time.

Key Roles and Responsibilities

In a LeSS organization there’s no place for project managers or a program/ project management office (PMO). You don’t need them because their responsibilities transfer to a Product Owner and the feature teams, and to avoid confusion and potentially even turf wars. In a LeSS organization, Feature Teams do the development work. They are what others would call product teams. Each team creates and is responsible for end-to-end customer-centric features, rather than components or a technical layer. They stay together for the long haul. They’re self-managing and cross-functional — pooled together, their members have all the skills they need to produce a shippable increment. They’re guided and coached by a Scrum Master. In LeSS this is a dedicated, full-time job, though one Scrum Master can serve up to three teams. All feature teams have the same Product Owner and share a single Product Backlog. The Product Owner can have a Product Owner Team in which other Product Managers support the Product Owner. Together, they’re often referred to as Product Management. The Product Owner (Team) connects customers/users and teams so teams can do detailed backlog refinement with them directly. As the Product Owner doesn’t need to act as an intermediary in this, s/he can focus on product discovery with customers. Note that in LeSS Product Owner and Feature Teams are peers. LeSS, like Scrum, explicitly seeks to keep a power balance between them.

LeSS Huge

LeSS Huge groups Feature Teams in Product Requirement Areas — major areas of customer requirement as opposed to system layers or architectural subsystems. It introduces an Area Product Owner (APO) into the Product Owner Team, with each APO focusing on a single product requirement area. Each item on the Product Backlog gets assigned to a single Product Requirement Area. The Area Backlog is then simply a filter on the full backlog.

Organizational Structure

Many organizations that have transitioned to LeSS still have managers. LeSS is one of the few frameworks that specifically addresses how they can reinvent themselves and provide value despite losing many of their traditional responsibilities
Less Huge Organizational Structure 1
The Head of the Product Group is the hierarchical manager of all the teams working on the product. S/he supports the feature teams, helping them overcome obstacles and acquire and improve their skills. The Undone Department isn’t a real department, but the umbrella name for traditional waterfall-y departments like Business Analysis, QA and testing, and Architecture. There’s no place for them in LeSS and you will dismantle them as you get further along in your LeSS adoption. Their people then transfer to become members of the feature teams.

LeSS Huge

Rather than use product requirement areas for organizational structure, LeSS Huge proposes you structure your organization per site. This keeps your local line organization intact and helps to remain flexible and adaptive in what requirement areas you want or need (no need to change your organization when you change requirement areas). While you’ll be dismantling the departments that make up the Undone Department, in large organizations it still pays to have a Support group to manage and run the development environment. Keep it small and focus it on how they can help the teams instead of prescribing what the teams can and cannot use. LeSS considers coaching critical to your transition success. In LeSS Huge, it gets its own Competence and Coaching department focused on continuous improvement through observation, training, and coaching.

Key Meetings, Cycles, Delivery Cadences

A Sprint in LeSS is almost identical to the single-team Scrum Sprint.
Why Less Framework
All teams start and end the Sprint at the same time. All teams work from a single Product Backlog. All teams use the same Definition of Done. All teams work toward a single Potentially Shippable Product Increment.

Key Meetings, Cycles, Delivery Cadences

A Sprint starts with Sprint Planning for all teams at the same time.

It’s split into two parts.

  • 1. Sprint Planning One
Product Owner and representative(s) of all teams decide which items each team will work on and discuss any open questions that weren’t resolved during Backlog Refinement. In addition, teams identify what, if any, need there is for coordination. Note that LeSS explicitly says the Scrum Master should not be the representative of a team. Being a dedicated job in LeSS, the Scrum Master has a completely different set of skills and expertise than someone a team trusts to make judgment calls on the workload impact and dependencies of work items.
  • 2. Sprint Planning Two
This is mostly the same as in single-team Scrum. Teams plan their Sprint in detail, deciding how they’ll get their items to “done”. When teams will work on similar or related items, they can do their Sprint Planning in the same location so they can design the items together and easily communicate about shared work and collaboration opportunities as they otherwise plan their Sprint per team.

Daily Scrum

Each team conducts their own Daily Scrums. They don’t have to be at the same time. That facilitates welcoming observers from other teams for information and knowledge sharing.

Product Backlog Refinement (PBR)

During the Sprint, teams hold their own meetings with customers and users — but not the Product Owner, to refine items on the product backlog that are likely to be worked on in the next (few) Sprint(s). These meetings don’t have to occur at the same time, but teams can decide to refine similar and related items together.
Kanban Team 768X554 1
Optionally, teams can conduct an Overall PBR that does include the Product Owner to decide which team will likely work on which items.

Sprint Review

The Sprint Review in LeSS is an all-team meeting including the Product Owner, customers and users, and other people with a stake in the product or the increment.

Retrospective

Like Sprint Planning, the Retrospective is split into two parts. First each team conducts its team specific retrospective like they’d do in single-team Scrum. That’s followed by an Overall Retrospective attended by the Product Owner, the teams’ Scrum Master(s), and rotating representatives of each team. This second part focuses on how all teams are working together in a single development system.

LeSS Huge

There are no extra events (meetings). The Product Owner and Area Product Owners are the glue between all teams.
Less Huge Framework
LeSS Huge is the parallel execution of LeSS Sprints by all requirement areas.

Methods and Techniques

Apart from the practices for technical excellence, LeSS does not prescribe any methods or techniques.

Common Pitfalls

LeSS has the same pitfalls as Scrum and as any agile adoption in more than a single team.

The biggest LeSS specific pitfalls are:

  • not embracing cross-team collaboration in architecture, design, and modeling and thereby not making options and solutions knowable and available across all teams.
  • not striving to dismantle the undone departments and keeping project managers and a Project Management Office around and thereby reducing clarity and likely facing energy-sapping and unproductive turf wars as nobody likes to lose parts of their kingdom.
  • not severing cross-functional team members’ reporting relationship with their former managers and thereby putting them in a situation of conflicting loyalties.

Getting Started

LeSS is one of the few approaches to scaling agile that explicitly talks about the principles, challenges, and essential parts and practices for adopting LeSS and LeSS Huge. So take advantage of that when you start your LeSS adoption.
Adoption Overview

A few basics to put in place for a more successful adoption:

  • Get everyone on the same page in their knowledge and understanding of Scrum and LeSS. Invest in several days of training for everyone.
  • Get everyone on the same page about what whole product they’re all working on.
  • Use a strong Definition of Done (rather than a weak one that reflects current reality) and create cross-functional teams that can meet them by moving people (letting them volunteer!) from Undone Departments into them.
  • Make it clear that only the Product Owner can give teams work. You don’t want any team interrupted by and feeling any obligation to cater to seemingly reasonable requests by line manager, Sales, HR, or even the CEO.
  • Project Managers have no role in LeSS but may still be around while you get things in order. During that time, keep them as far away as possible from the teams, because they’re likely to interrupt and cause confusion on whether team members should still act upon what they say. See the previous point.
  • Project Managers have no role in LeSS but may still be around while you get things in order. During that time, keep them as far away as possible from the teams, because they’re likely to interrupt and cause confusion on whether team members should still act upon what they say. See the previous point.

Further Reading

Craig Larman and Bas Vodde — the authors of Large Scale Scrum — wrote three books about LeSS and their experience working with clients to apply LeSS for scaling Scrum.
  • Scaling Lean and Agile Development (2009)
  • Practices for Scaling Lean and Agile Development (2010)
  • Large-Scale Scrum: More with LeSS (2015)

Chapters from these books are available online:

  • Introduction to LeSS (Chapter 2 of LeSS book) — where you can find many details on the topics discussed (and not discussed) in this article.
  • Inspect & Adapt Chapter from Practices for Scaling
  • Agile Contracts
  • Design and Architecture
  • Lean Thinking
  • Feature Teams

The Agile Alliance has a very interesting article on LeSS without Scrum. It tells of an approach to adopting LeSS’ organization design first and only then introducing Scrum.

Are You Ready to Do More With LeSS?

If you subscribe to the idea of “Less Is More” and want to keep overhead to a minimum. If you value keeping everyone focused on the whole product at all times. If you’re comfortable with running experiments and adapting as you go. If you like teams progressing in their Scrum adoption at their own pace. Then you’re ready to adopt Large Scale Scrum as your framework for scaling agile. Your first step toward that would be to learn more about LeSS, especially its core principles and its principles for adopting it. I recommend doing so collectively using the same sources or trainers. This ensures that everybody involved starts on the same level of knowledge and understanding, which will enhance conversations around your adoption. If you’re not ready to adopt LeSS, check out our overview of scaled agile frameworks. Signup for updates!

Signup for updates!

Medha Case Study

Check out Nimble Now!

Humanize Work. And be Nimble!

Free Trial