Descaling Enterprise Agility with the LeSS Framework

By Doug Rose

While most other agile frameworks scale up to enterprise agility, LeSS takes a different approach — it scales down. It steers you away from building up your teams and creating dozens of new roles, which is why LeSS creators, Craig Larman and Bas Vodde, often call their approach “descaling” enterprise agility.

Larman and Vodde feel so strongly about the necessity for creating small, tight-knit teams that they start with a word of caution. They lay out three obstacles that commonly cause enterprise agile projects to fail:

  • Making teams too large
  • Having teams work at several different sites
  • Offshoring one or more teams

The LeSS creators start out by saying these three obstacles will cause your projects to fail. It’s almost as if they’re saying, “Scaling agile will probably fail, but maybe not with LeSS.” This is a very honest approach, but it’s also very discouraging. Most organizations have all three obstacles. That’s why they’re looking for a scaled agile framework. They don’t want to be told they’ll probably fail; they want to be given something that ensures success.

Instead of giving up on these organizations, LeSS tries to enable large organizations that face these obstacles to scale with less risk of failure. It provides the framework, principles, and practices to help organizations overcome these obstacles and others.

Embracing the spirit of LeSS

Like Scrum, LeSS is intended to be a “barely sufficient methodology” to guide the product development process. Although the framework diagram contains some details, LeSS is a minimalistic approach intended to provide just enough direction to get started and to encourage organizations to experiment on their own to find out what works best for them. This approach is captured in the LeSS Complete Picture diagram.

LeSS complete Picture
Copyright © 2014–2017 The LeSS Company B.V. Used with permission.
The LeSS Complete Picture.

To provide a minimal amount of guidance and foster a culture of learning, questioning, engagement, and continuous improvement, LeSS replaces the notion of best practices with principles, rules, guides, and experiments:

  • Principles: The principles govern the way organizations apply LeSS in their specific context. The purpose of the principles is to enable an organization to adopt a new mindset regarding product development. Many of these principles are just an upsized version of the agile mindset. Your teams need to be transparent about their work. They need to focus on the customer and inspect and adapt based on what they’ve learned or change requirements.
  • Rules: The rules are key elements of the LeSS framework that support empirical process control and whole product focus. The rules are baked into the frameworks; for example, teams are required to conduct a retrospective at the end of each sprint.
  • Guides: Guides provide direction on how to adopt the rules, and they provide a subset of experiments (discussed next).
  • Experiments: Instead of prescribing best practices that would work for most organizations, the LeSS developers present experiments you can try to determine what works and what doesn’t work in your organization. You can try these experiments on your own or use them to brainstorm ideas for your own experiments.

You can check out some experiments in the first two books written by the LeSS developers: Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum and Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum.

Experimenting to create your own approach

LeSS encourages teams to experiment with their processes. From their perspective, an experiment is like a process recipe. It’s something you can try at your organization and then evaluate the results. The creators of LeSS don’t think in terms of best practices that work for every organization. Instead, they encourage organizations to be empirical — to experiment, measure the results, and make data-driven decisions.

The LeSS experiments usually begin with “Try …” or “Avoid …,” so a LeSS experiment might be something like “Try … See root causes during causal modeling and retrospective workshops, with Five Whys and Ishikawa diagrams.” These experiments range from small process tweaks to overall organizational structure. Here are few that have been pulled from the two books:

  • “Avoid … test department.”
  • “Try … acceptance of test-driven development.”
  • “Try … product owner writes the tests.”
  • “Try … zero-tolerance on open defects.”
  • “Try … see the positive feedback loops in your system.”

Start with the least amount of process and then experiment your way to an enterprise-level framework. Just enough. Just in time. In other words, start with less and then build your way up to a more robust framework.

Seeing software developers as craftsmen/women

Less incorporates Lean thinking, and one of the pillars of Lean thinking is respect for people. In LeSS, employees are treated as craftsmen/women who develop products. The creators of LeSS see software development as a rigorous intellectual pursuit. They cringe at the idea that software developers should get their requirements from business analysts and then make what they’re told to make. Instead software developers should work to continually fine-tune their craft and, by extension, improve the product and the process for building it.

LeSS embraces the three-step shuhari model of learning and honing one’s skills. The idea behind shuhari is that most software developers are stuck in “Shu.” They only follow the rules and learn the basics (so called best practices).

To reach the next level, developers must learn to break the rules and put their work into a larger context. Only then can they reach the highest “Ri” level where they actually make the rules and set their own path. It’s at this level where software developers can unleash their creativity and help their organization build value

LeSS is Scrum

The LeSS creators are quick to point out that LeSS is Scrum. So what does this mean? Nearly all other enterprise agile frameworks include Scrum, which makes sense because Scrum is the most widely used of all the agile team frameworks. Yet what they’re saying here is different. They’re saying that LeSS is Scrum — it’s not a new version of Scrum or something layered on top of Scrum.

Staying close to Scrum

One of the core ideas behind LeSS is that you don’t have to add roles, events, rules, layers, and bureaucracy. You could take this lightweight Scrum framework and expand it out (wider but not necessarily deeper) to meet all your scaling needs. In other words, Scrum is all you need.

This approach differs significantly from how other enterprise agile frameworks deal with Scrum. The SAFe framework puts Scrum in the bottom corner of its diagram. Scrum is seen as just one of several agile practices you can use for your team. You could easily run SAFe without Scrum at all. All your teams could use Kanban, or Extreme Programming. They could even use a mishmash of agile methods such as ScrumBan or ScrumXP.

Disciplined agile (DA) also sees Scrum as a team-level set of practices. To deliver an enterprise-level product, you need to fill in the gaps that the lightweight Scrum intentionally leaves, which is why disciplined agile delivery (DAD) creates ten new roles to deliver agile enterprise software.

Exposing flaws in processes

Like Scrum, LeSS sees itself as a way to expose flaws in processes. The combination of small teams and short development cycles enhances transparency, making failures more apparent. Again, other frameworks give you many more answers. Both SAFe and DAD add layers of new processes. While these layers provide additional guidance, they tend to obscure problems.

Staying simple

Above all, LeSS embraces Scrum’s approach to simplicity. The creators of LeSS like to think of enterprise frameworks as having two extremes. On the one hand you have very process-heavy frameworks. These might include the rational unified process (RUP), traditional waterfall approaches, or even SAFe. On the other hand, you have very lightweight principles and ideas such as Lean Software Development and Kanban. LeSS positions itself between the two, providing just enough structure and guidance to create high-functioning teams that collaborate closely.

Scrum is simple and lightweight and designed to expose flaws. The creators of LeSS believe that’s why Scrum is widely used. They want to take these ideas and apply them to large organizations without losing sight of what has made Scrum so successful.