Enterprise Agility: Supersizing Your Delivery with LeSS Huge

By Doug Rose

LeSS Huge is a second LeSS framework that’s a step up from the LeSS framework. LeSS Huge is designed to scale up to many more teams and across the organization.

LeSS Huge
Copyright © 2014–2017 The LeSS Company B.V. Used with permission.
LeSS Huge is for even bigger products.

Even though this framework is larger and scarier than the standard LeSS framework, the emphasis remains on “less is more.” The breadth of the framework is larger, but at its core are Scrum teams engaging in sprints.

If you have eight or more teams, you can use the LeSS Huge framework, which provides additional structure through the use of requirement areas, explained next.

Requirement areas

Requirement areas are customer-centric categories of backlog items, often referred to as product backlog items (PBIs). For example, a website may have a separate requirement area for articles and advertisements. The product owner draws items from the product backlog and assigns each to a requirement area to create different views of the product backlog called area backlogs, discussed next.

LeSS Hue requirement areas
Copyright © 2014–2017 The LeSS Company B.V. Used with permission.
Typical LeSS Huge requirement areas.

Area product backlog

When working on a very large product, the product owner can easily become overwhelmed, and because LeSS focuses on optimizing the whole system, the product owner can become a bottleneck for all the feature teams. The best way to steer clear of this potential bottleneck is to break down the work into smaller batches. So the product owner breaks down the product backlog into smaller batches, each of which comprises an area product backlog assigned to its own area product owner.

Lean thinking is about optimizing the whole and breaking down your work into smaller batches.

Area product owner

The area product owner maintains and prioritizes work items in a subset of the product backlog that pertains to a certain feature or a set of related features. Think of the area product owner as a product owner for a feature instead of for the entire product.

Organizational structure

The LeSS Huge framework is built on top of the regular LeSS framework, so it tries to add the minimum number of new roles and processes required to work on much larger products. Keep in mind that LeSS Huge is designed for eight or more teams, representing dozens, hundreds, or even thousands of developers. When you have that many people involved, you need an organizational structure to align their efforts. In LeSS Huge, the organizational structure involves the following areas:

  • Head of product: The head of product provides the team with a unified vision of the product, communicating to everyone working on the product what it is and what it must do to serve the customers’ needs.
  • Sites: The two “Site” boxes on the left indicate the preference of grouping related teams and team members locally when an organization encompasses multiple sites across two or more buildings, cities, or countries. The purpose of having “teams in site,” as the LeSS developers refer to this grouping, is to reduce the need for long-distance communication among teams.

    Although you want to keep your teams local to a given site, don’t group teams according to requirements areas, because such an approach often results in making certain requirements areas more permanent than they need to be. Instead, look at these site groupings as a way to keep line organization local. (Line organization is traditional top-down, chain-of-command, department organization.)

  • Undone department: In LeSS, “done” means a product increment is deliverable to a customer. A new team may not have the knowledge and skills required to create a product increment that’s considered done, in which case the product enters the Undone department, where additional teams complete the work.

    The ultimate goal is to have no Undone department because, ideally, every team has the capacity to deliver potentially shippable product increments. However, the reality is that on large products, you’ll probably have to spin up new teams that have trouble delivering product increments that meet the criteria for the definition of “done,” so you’ll need this department to complete their work until all teams have the capability to create deliverable product increments (which may never happen).

  • Support: When teams are working on a huge product, they need more support in the form of configuration management, laboratory support, integration, and operations. On smaller products, regular LeSS teams can usually take care of a lot of the environmental requirements to deliver their product; for example, they can spin up their own servers and software development environments.

    Try to keep your support “department” as small as possible and maintain its focus on supporting the teams, not controlling them or trying to set direction. They should be seeking ways to help, not ordering teams to “do it this way.”

  • Product owner team: The product owner team is made up of the product owner and area product owners, who work together to distribute work items and maintain and prioritize their respective backlogs.
  • Competence and coaching: Products that need LeSS Huge can usually support full-time coaching and training staff. Some organizations create an agile center of excellence — typically a small group of coaches and trainers that thinks about ways to improve agile in the organization.
typical LeSS Huge organizational chart
Copyright © 2014–2017 The LeSS Company B.V. Used with permission.
A typical LeSS Huge organizational chart.