LeSS Framework

Agile gives a breath of fresh air for businesses across the world. It helps various teams to continuously improve while focusing on attainable goals and timely delivery. However, implementing Agile in a large organization is not always an easy process.

Companies that desire to scale Agile across multiple departments have different Agile frameworks to consider to help them combat these challenges.

In this post, we highlight one of the most popular Agile scaling frameworks – Large Scaled Scrum.

For many companies, the LeSS approach to scaling Scrum teams may be the next logical step on their journey to scaling Agile.

What Is LeSS?

LeSS literally means Large Scaled Scrum. This is one of the leading frameworks of Agile software development. You can apply this multi-team framework to an Agile team that consists of dozens or hundreds of people. They can work together on one specific shared product.

LeSS isn’t a new and improved Scrum, it is something different layered on top. It is about figuring out how to apply the goals, principles, and key elements of Scrum in a large-scale context, as simply as possible.

Large Scaled Scrum allows creating large or small-sized products. This is a minimalistic and quite a simple framework that requires less enforcement of rules, roles, processes, and artifacts (in contrast to other popular scaling Agile frameworks). It only involves conventional Scrum roles: PO (Product Owner), SM (Scrum Master), and the team.

LeSS is a customer-centric framework, so teams may interact directly with customers while the PO focuses on setting the product roadmap, and establishing priorities.

Origins

At the very beginning of the century, many believed that Agile development was only for small groups. This judgment was greatly facilitated by “Agile and Iterative Development” written by Craig Larman in 2002. Over time, there were more and more requests to apply Scrum to large, multi-site, and offshore development.

Nowadays, the LeSS framework has been adopted in big groups worldwide in disparate areas: trading systems, telecom equipment, investment, and retail banks, marketing and analytics platforms, video conferencing, online gaming, etc.

What is the LeSS structure?

The basement is cross-functional Agile teams that range from having 8-12 members who are experienced and seasoned in coding, testing, architecture, design, and business domain knowledge.

Depending on the company’s structure, there can be multiple teams. The types of LeSS are:

• Basic LeSS (2-8 teams)
• LeSS Huge (8+ teams)

These teams are responsible for producing high-quality software while collaborating with other teams. A Scrum Master may facilitate 1-3 teams. He/she guides the teams on how to work in LeSS.

Then there is the PO who manages the backlog that includes the list of features. There is also a team of product owners that report to the head PO.

In LeSS Huge, there are multiple Basic LeSS implemented at the same time. It suits large enterprises with more than 8 teams. There are Area Product Owners. They are responsible for their respective product backlog. The PO manages up to 3 teams, and the Chief PO leads the area product owners and focuses on the entire product.

Key LeSS principles

There are a dozen of principles that Less defines for applying the value, elements, and purpose of Scrum across an organization. These principles help to build more responsible teams with better collaboration and customer focus.

Teams can be focused on transparency, learning, and delivering customer-centric values that companies need to stay competitive and responsive.

The list of the LeSS principles includes:

• Large-Scale Scrum is Scrum
• Empirical process control
• Transparency
• More with less
• Whole product focus
• Customer-centric
• Continuous improvement towards perfection
• Systems thinking
• Lean thinking
• Queuing theory

LeSS frameworks

As we’ve mentioned above, LeSS provides two configurations: Basic LeSS (8 teams = 10-50 individuals) and LeSS Huge (8+ teams about 50-6000+ individuals).

LeSS guides

There are useful recommendations described by Craig Larman and Bas Vodde based on experiments conducted with LeSS. They compose the LeSS guides. They are helpful in understanding the ways to adopt the framework, the roles and responsibilities, and how to coordinate and integrate between teams.

LeSS experiments

LeSS includes experiments. The authors propose some companies to try them, and others to avoid. Some of them have had mixed results. The outcomes from these experiments were foundational in the forming of the framework.

Planning in LeSS

In LeSS, sprints are planned, and teams create a deliverable product in each sprint. The development is iterative and incremental, and the sprints usually last for 1-4 weeks.

Two stages of planning in LeSS are defined:

1. The selection of items from the product backlog when two members of each team meet with their PO to choose from high-priority items of the backlog.
2. The discussion of the selected items. The team gets the items from the product backlog, and then planning is done to reach the sprint goals. Typical whiteboards and wall charts help to plan.

A product backlog grooming session also takes place. The team and the customer discuss how the existing requirements can be improved or if new requirements should be added.

Teams also run their own retrospectives, reviewing what is done to continuously improve.

LeSS vs Scrum

Scrum and LeSS are often compared to determine which is best. And this is actually not the right mindset. Remember that LeSS isn’t a better version of Scrum. LeSS builds upon Scrum to support its use in a larger context and how to scale it across larger companies and beyond one team.

However, many admit that Basic LeSS looks similar to one Scrum team. All teams work together as a Scrum team even though comprised of one or more teams.
In LeSS Huge, the role of a PO is expanded to include Area POs that coordinate and collaborate across many teams.

With the aim to support these efforts, the PO runs the single team product backlog grooming. The meeting helps to align the delivery of the work across all the teams working together.

LeSS vs SAFe

Besides LeSS, many other scaled Agile frameworks are becoming more and more popular. For example, Scrum of Scrums or Scrum at Scale. Scaled Agile Framework (SAFe) is also a great example of the leading framework.

LeSS and SAFe have many similarities. They both start with scaling a Scrum team and incorporating principles (such as continuous improvement, Lean thinking, and customer-centricity). However, LeSS focuses on simplifying organizational structure by remaining adaptable and flexible.

SAFe requires additional roles, including the following:

• RTE – Release Train Engineer
• STE – Solution Train Engineer
• Epic Owners

It also includes artifacts, processes, and organizational changes that some companies may not be ready to take on.

What Are the Benefits of Large Scaled Scrum?

The power and the focus of the LeSS framework are not to create a different framework, but to apply the principles of Scrum to many teams that cooperate to deliver a complete end-to-end product.

Here are some evident benefits that can be achieved with the LeSS framework:

• One PO who bridges the gap between the business team and the technical team.
• Decreasing costs for implementation by implementing practices that teams already use in Scrum.
• The framework provides a complete product view within the area of focus.
• Fewer people are required for the product delivery.
• Teams can closely contact business stakeholders and customers.
• Continuous improvement is enabled through frequent Retrospectives and other fundamental meetings.

Summary

To conclude, here are the most important facts you should know about LeSS:

• The Large Scaled Scrum framework provides the entire product view that ensures high transparency in the work you do.
• Teams can constantly contact customers, which allows them to realize the actual idea of what customers really need.
• Lean thinking leads to minimal waste, ensuring teams focus on what really needs to be done.
• Teams have opportunities to learn and grow consistently. They are feature-oriented and customer-centric.
• Dependencies are handled at the integration level by sharing code bases with other teams.
• Management is focused on determining the vision and nurturing the team members.
• Teams coordinate with each other frequently and share the codebase.
• Every sprint is assisted with a big room backlog refinement session.
• DevOps and continuous integration are key for smooth delivery to the customer.
• Frequent retrospectives help to ensure continuous improvement.