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.
Img Src: less.works
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.
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:
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.
Since then, product groups applying LeSS run the gamut in size, from as small as two teams to as large as 2500 people.
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:
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.
Img Src: less.works
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!).
LeSS can be lean in rules because of its ten principles to guide your decisions for everything it doesn’t consider essential (a must).
Img Src: less.works
LeSS scales Scrum itself without adding different scaling processes, artifacts or events.
LeSS helps you gradually simplify your organization and rely on responsibility, ownership, and customer-centricity instead of roles, processes, and artifacts.
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.”
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.
Img Src: volkerdon.com
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.
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.
Continuous improvement toward perfection says three things:
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.
LeSS advocates to keep all teams focused on the whole product, not just their tiny part of it.
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.
And there’s also a lot of inventory in those queues.
Img Src: less.works
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:
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.
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.
The ones that LeSS itself reports:
LeSS sticks with the Scrum per-sprint planning cycles. There are no overarching planning cycles or events such as quarterly PI planning in SAFe.
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.
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:
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.
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 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.
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.
Img Src: less.works
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.
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.
A Sprint in LeSS is almost identical to the single-team Scrum Sprint.
Img Src: less.works
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.
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.
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.
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.
Optionally, teams can conduct an Overall PBR that does include the Product Owner to decide which team will likely work on which items.
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.
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.
There are no extra events (meetings). The Product Owner and Area Product Owners are the glue between all teams.
Img Src: less.works
LeSS Huge is the parallel execution of LeSS Sprints by all requirement areas.
Apart from the practices for technical excellence, LeSS does not prescribe any methods or techniques.
LeSS has the same pitfalls as Scrum and as any agile adoption in more than a single team.
The biggest LeSS specific pitfalls are:
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.
Img Src: less.works
A few basics to put in place for a more successful adoption:
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.
Chapters from these books are available online:
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.
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.