Notes on LeSS

LeSS, as in Large Scale Scrum.

I recently attended a LeSS training by Bas Vodde. Herewith, some notes and thoughts on LeSS.

For context, I’ve been using agile and Scrum practices and processes for close to eight years now. I’ve been in agile teams as an individual contributor and have also setup and grown teams with Scrum and Kanban as the organizing tools. In particular, I was part of a sizable LeSS implementation at J.P. Morgan in .

What is LeSS

LeSS is a framework to scale Scrum beyond a team. Here are the key ideas, as I understand them:

There are two flavours of LeSS: LeSS and LeSS Huge. LeSS provides structure for groups of less than 8 teams. LeSS Huge adds a few changes that support organizations of more than 8 teams.

At the risk of over-simplifying, LeSS Huge partitions the product into Product Areas. Each area has its own backlog that is linked to the overall product backlog. Teams use LeSS within each product area.

The big question

In their own words, LeSS is not multiple Scrum teams but multiple team Scrum. The emphasis is on getting all the teams to collaborate and work together in contrast to creating separate swimlanes for each team. LeSS calls for maximizing dependencies between teams. LeSS argues that dependencies are not necessarily bad; what is bad are asynchronous dependencies which lead to integration phases and staggered delivery of a fully working product increment.

This is an idea that I remain deeply skeptical of. My experience suggests that it is hard to scale synchronous collaboration linearly with number of teams and scope of product. In fact, connectivity theory tells us that communication pathways (and hence collaboration points) grow as ~n^2. The natural response to taming this exponential growth is to reduce the scope of a product. However, LeSS explicitly argues against this. It calls for a product definition that is as broad and expansive in scope as possible. For large companies, i.e. precisely the kind of companies that are looking to scale Scrum, this translates into a company-wide or at least division-wide (area) product backlog. A shared backlog of such broad scope in turn calls for expertise across a very large domain requiring a very diverse set of business knowledge & technical skills in every single development team.

LeSS argues that humans can and do acquire new knowledge & skills. There’s no arguing this point and more on it later. However, there’s at least two fundamental constraints to knowledge & skill acquisition.

While engineers appreciate the opportunity to learn new skills, the above constraints place an upper limit on doing so.

Moreover, it has been widely recognized that providing autonomy, mastery and purpose is essential to instilling and sustaining motivation. But the broader the product remit, the more diluted are these three characteristics and thus, the harder it is to keep engineers motivated.

Taken together, I believe this fundamentally curtails the ability of an organization to deliver on a broadly scoped product backlog, one of the key hypotheses of LeSS Huge.

Some thought-provoking nuggets

An advantage of instructor-led group trainings are the discussions that happen. There were a few in particular that I wish to share.

On scientific management

LeSS places a great deal of emphasis on moving away from scientific management aka Taylorism. In particular, LeSS advocates against two ideas that emerge from scientific management:

On feature teams

Bas shared a thoughtful trick to know whether what you have is a feature team or not: does the team speak the same language as the customer? If they do, then you have a feature team. If they don’t, you’ll usually find a translation layer in between, often called Business Analysts.

On perfection vision

It is important for leadership to establish & communicate a perfection vision, a vision of what a perfect endstate looks like. The idea isn’t that we need to hit this endstate. Instead, having such a vision helps us in decision making: does a particular decision move us towards that perfect endstate or not? The better you communicate this vision, the easier it is for your teams to make the right trade-offs, thus federating decision making as much as possible.

On sprint lengths

Sprint lengths should be long enough to deliver a valuable product increment and short enough to reduce time to receiving feedback & maximize learning on that increment. Bas also suggested that fixed sprint lengths (e.g. 2 weeks) in Scrum serve a similar constraining function as WIP limits in Kanban. Something to ponder.

On organizational decisions

If you think of people as nodes in a system, an outcome of systems thinking is that it’s the feedback loops between the nodes/people that influence, effect, and drive decisions. In other words, decisions are made not by people but by the relationships between them.

Personal Takeaway

I remain unconvinced that LeSS works at scale. In other words, LeSS is fine; LeSS Huge isn’t.

Do let me know on Twitter if you agree or disagree!