Large-Scale Scrum (LeSS) is an understanding of a team’s standard Scrum. From this point, your organization should be able to comprehend and adopt this framework, which requires examining the purpose of a team’s Scrum elements and figuring out how to achieve the same purpose while staying within the constraints of the standard Scrum rules.

Developing Agile with Scrum requires a deep organizational change to become agile. Therefore, neither Scrum nor LeSS should be considered merely a practice. Instead, they form an organizational design structure.

Two different scale frames

LeSS provides two different large-scale Scrum frameworks. Most sizing elements focus on directing all teams’ attention to the entire product, rather than “my part”.

Global focus and “end-to-end” are perhaps the dominant issues to be solved in scaling. The two frameworks – which are Extended Single Team Scrum – are:

LeSS: Up to eight teams (of eight people each)
LeSS Huge: Up to a few thousand people on one product

In short, LeSS is an extended version of a team’s Scrum and retains many of a team’s Scrum practices and ideas. In LeSS, you will find:

1. A single Product Backlog (because it’s for a product, not a team),
2. A definition of Ready for all teams,
3. A potentially switchable product increment at the end of each Sprint,
4. A product owner,
5. Many full cross-functional teams (no single expert teams),
6. One Sprint

What makes LeSS different?

Sprint Planning Part 1:

In addition to a Product Owner, includes people from all teams. Team members manage their product backlog item division and also discuss opportunities to find shared work and cooperate, especially for related items.

Sprint Planning Part 2:

This is carried out independently (and usually in parallel) by each team, although sometimes for simple coordination and learning, two or more teams can carry it out in the same room (in different areas).

Daily Scrum:

It is also performed independently by each Team, although a Team A member may observe Team B’s Daily Scrum increase information sharing.

General PBR:

There may be an optional short General Product Backlog Refinement (PBR) meeting that includes a Product Owner and people from all teams. The main objective is to decide which teams are likely to implement which items and therefore select those items for single-team PBR drill-down later. It is also an opportunity to increase alignment with the Product Owner and all teams.

Product Backlog Refinement:

The only requirement in LeSS is single-team PBR, the same as single-team Scrum. But a common and useful variation is multi-team PBR, where two or more teams are in the same room together, to increase learning and coordination.

Sprint Review:

In addition to a Product Owner, includes people from all teams, relevant customers/users, and other stakeholders. For the inspection phase of product increment and new items, consider a “bazaar” or “science fair” style: a large room with several areas, each with team members, where the items developed by the teams are displayed and discussed.

Overview:

This is a new meeting not found in a team’s Scrum, and its goal is to explore improving the overall system, rather than focusing on a team. The maximum duration is 45 minutes per week of the sprint. It includes the Product Owner, Scrum Masters, and rotating representatives from each Team.

10 principles of LeSS to guide your team’s decision

Large at Scale Scrum is a set of principles that govern the way organizations apply LeSS in their specific context.

While some enterprise agile frameworks, such as the Scaled Agile Framework (SAFe), provide more structure and more roles, LeSS calls for less structure and fewer roles, leaving decisions up to the organization itself as to how to implement LeSS.

The guidance the framework offers comes more in the form of its ten principles.

1. Large-scale Scrum is Scrum

It’s not “new and improved Scrum.” Rather, LeSS is about figuring out how to apply Scrum’s principles, elements, and purpose in a large-scale context.

2. Empirical Process Control

Inspecting and adapting products, processes, organizational structure, and practices to create a suitable Scrum-based organization rather than following a detailed formula.

3. Transparency

Based on tangible ‘done’ items, short cycles, teamwork, common definitions, and keeping fear out of the workplace.

4. More with less

(1) In empirical process control we have: more learning with less defined processes. (2) In lean thinking we have: more value with less waste and high costs. (3) In dimensioning we have fewer roles, artifacts, and special groups.

5. Whole Product Focus

One Product Backlog, One Product Owner, One Potential Launchable Product Increment, One Sprint—regardless of whether there are 3 or 33 teams. Customers want the product, not just a piece.

6. Customer-centric focus

Identify value and waste in the paying customer view. Reduce cycle time according to your perspective. Increase feedback loops with real customers. Everyone understands how their current job directly relates to the benefits generated for paying clients.

7. Continuous improvement toward perfection

Create and deliver a product every time, cost-free and defect-free, to fully delight customers, improve the environment, and make life better. Experiment with both humble and radical improvements every Sprint in this regard.

8. System thinking

Seeing, understanding, and optimizing the system as a whole (not just parts of it), and using modeling to explore system dynamics. Avoid sub-optimizations that focus on the “efficiency” or “productivity” of individuals and individual teams. Customers are concerned with the flow and total lifecycle time of the product (from conception to payback), not the individual steps.

9. Lean Thinking

Create an organizational system based on having “managers as teachers” who apply and teach systems thinking and lean thinking, manage to improve. Add the two pillars of respect for people and continuous improvement. All to achieve perfection.

10. Queueing theory

Understand how queuing systems behave in R&D environments and apply that information to manage queue sizes, work-in-progress limits, multitasking, work packages, and variability.

Final thoughts on LeSS being your guide

LeSS was designed to scale an agile team, it maintains many of the Scrum practices and ideas. As well as complete, multidisciplinary, self-managing teams, a Product Owner and a single product backlog.

With LeSS, all teams are in the same sprint to deliver a common product increment each cycle. Just as a part of Scrum, LeSS has the same events during the sprint, but there are some adaptations to make it scalable.

But LeSS won’t work in your organization, not for LeSS, but for the way you are in your organization right now. Your organization would tend to change in a way that would allow you to work with LeSS. This is something that is not easily and quickly achieved.

Adopt LeSS, go further, challenge the traditional conventions of projects, products, roles, and technical practices. What LeSS seeks is to establish an agile culture by changing the structure and policies of the organization.

Types of equipment are multifunctional, and they are dedicated to developing code and testing. Therefore, it includes all architecture and design skills, business domain knowledge, UX/UI skills.

In that so, use the principles of LeSS to even create more ways to decide your teams goals and improve performances!

Make right decisions to guide your team with GitScrum!

GitScrum has top-notched tools that lead you to the best experience to scale your agile team. Follow your own mindset to increase your team’s productivity with GitScrum!

Sign up now and get the best lifetime deal you will have!