Thursday, October 29, 2015

Scaling Agile: LeSS

The Large Scale Scrum Framework
This is the third of six articles on approaches that try to help scaling Agile. For the introduction to this series please read the first article Scaling Agile: Nexus Framework. The second article is about Disciplined Agile Delivery (DAD). This article will present Large Scale Scrum, or LeSS.

The creators of LeSS, Bas Vodde and Craig Larman, take a different approach to scaling Agile as DAD and SAFe do. LeSS is centered around Scrum. Scaling Scrum starts with understanding standard one-team Scrum. From that point, your organization must be able to understand and adopt LeSS, which requires examining the purpose of one-team Scrum elements and figuring out how to reach the same purpose while staying within the constraints of the standard Scrum rules.

Agile development with Scrum requires a deep organizational change to become agile. Therefore, neither Scrum nor LeSS should be considered as merely a practice. Rather, they form an organizational design framework.

The LeSS Frameworks

LeSS provides two different large-scale Scrum frameworks. Most of the scaling elements of LeSS are focused on directing the attention of all of the teams onto the whole product instead of “my part.” Global and “end-to-end” focus are perhaps the dominant problems to solve in scaling. The two frameworks – which are basically single-team Scrum scaled up – are:
- LeSS: Up to eight teams (of eight people each).
- LeSS Huge: Up to a few thousand people on one product.

LeSS is a scaled up version of one-team Scrum, and it maintains many of the practices and ideas of one-team Scrum. In LeSS, you will find:
- a single Product Backlog (because it’s for a product, not a team),
- one Definition of Done for all teams,
- one Potentially Shippable Product Increment at the end of each Sprint,
- one (overall) Product Owner,
- many complete, cross-functional teams (with no specialist teams),
- one Sprint.
- In LeSS all Teams are in a common Sprint to deliver a common PSPI.

The Large Scale Scrum Framework
The LeSS framework (click to enlarge)

What is so special about LeSS?

Large-Scale Scrum (LeSS) is Scrum applied to many teams working together on one product. Why LeSS? Similar to one-team Scrum. For large groups, LeSS tries to hit a sweet-spot balance between defined concrete elements and empirical process control. And just like one-team Scrum, LeSS is (1) lightweight, (2) simple to understand, and (3) difficult to master—due to essential complexity. A big part of the LeSS Practioner Course is about principles like Systems Thinking, Experiments, Lean Thinking etc, because that is the foundation of LeSS, and those need to be understood and used in order to implement LeSS succesfuly.

LeSS Principles
The LeSS Principles (click to enlarge)

Roles, Artifacts and Events

Sprint Planning Part 1 has the same maximum duration as in single-team Scrum, one hour per week of Sprint, but participation is limited to two members per team plus the one overall Product Owner. Let team representatives self-manage to decide their division of Product Backlog Items and end by identifying dependencies (perhaps with a dependency matrix) and discussing coordination.

Sprint Planning Part 2 is held independently (and usually parallel) by each Team, though sometimes a member of Team A may observe Team B’s meeting and make suggestions when there is a coordination issue between the teams.

Daily Scrum is also held independently by each Team, though a member of Team A may observe Team B’s Daily Scrum, to increase information sharing.Team representatives may hold an Open Space, Town Hall Meeting, or Scrum of Scrums several times a week to increase information sharing and coordination.

The Overall Product Backlog Refinement meeting is attended by two representatives per team and concentrates on splitting, lightweight analysis (e.g., only three examples per item if using Specification by Example), and estimation for upcoming PBIs. Use cross-team estimation to ensure a common baseline for estimation across teams.

Product Backlog Refinement: Similar to single-team Scrum, but for co-located teams, hold this at the same time in one big room with all team members present, with each team facing a separate wall with their own learning tools (whiteboards, projectors, …).

Sprint Review: Same as single-team Scrum but limited to two members per team plus the Product Owner and other stakeholders. Consider a “bazaar” or “science fair”-style phase during the middle of the Review: a large room with multiple areas, each staffed by team representatives, where the features developed by a team are shown and discussed. In parallel, stakeholders visit areas of interest and team members record their feedback. However, begin and end the Sprint Review with everyone in a common discussion to increase overall feedback and alignment.

Overall Retrospective: Maximum duration: 45 minutes per week of Sprint. Since the Team Retrospective ends the Sprint, this Joint Retrospective is held early in the first week of the subsequent Sprint. ScrumMasters and one representative of each Team meet to identify and plan improvement experiments for the overall product or organization.

How does LeSS relate to the other scaling approaches like SAFe, DAD, Nexus?

This question will be part of every article but not answered by me. I will try to find quotes from the author(s) of the framework regarding this question. In the final article, where I will compare all the frameworks, I will give my own opinion.

On the Blog of the LeSS website there are two posts dedicated to explaining the main differences between LeSS and Safe. Comparing LeSS and Safe, Part 1 and
Comparing LeSS and SAFe part 2 - Scaling Agility or Bureaucracy. Summarized it comes to the following:

SAFe and LeSS target into two different local optimums, each having a consistent set of practises, structures, skills, technology and culture. This has an analogy to species in nature. Grass-eaters and predators have different combinations of characteristics. SAFe is not aiming to reduce the Bureaucratic control enough to move the organisation away from the Traditional optimum. Instead, it tries to optimise the existing organisation by creating Lean-Agile programs. The project/program management is an old mainstream practise at this optimum. LeSS aims to reduce significantly the Bureaucratic control. It provides a mutually consistent set of practises that move the large organisation to a new Agile-optimum. 

Are there well-documented use cases of companies using LeSS?

On the LeSS website there are almost 20 case studies available. See LeSS Case Studies for the complete list. They include companies like J.P. Morgan, UBS and Nokia.

Other articles in this series:

Posted on Thursday, October 29, 2015 by Henrico Dolfing