”Large- Scale Scrum (LeSS) is a framework for scaled agile and scaling Scrum.”
WIKIPEDIA
First there was experimentation, empiricism and experience. Then there was structure, standards and system tuning. The LeSS Framework grew from the fertile soil of case stories from scaling gurus Bas Vodde and Craig Larman.
“We never wanted to create a framework,” says Bas Vodde. “That might sound strange, but Craig and I like working with organizations and teams on practical problems. We both believe in empiricism or empirical process control, where teams own their own ways of working, experiment, learn and improve. So the idea of a process or even a framework always felt counter to what we wanted to do: focus on experiments that worked within a certain context.”
Accordingly, LeSS was not developed but it evolved. As a matter of fact, it was only in 2014 that the partners Bas Vodde and Craig Larman started to use the name LeSS and created the LeSS Framework rules. Before that, LeSS was rather a collection of experiences documented in experiments—stuff they had tried while working with lots of large-scale product development groups. In this context, they learned to focus on increasing transparency, reducing organizational overhead and increasing the ownership and meaning of the work of the teams.
Large parts of these conclusions can be found in the books Scaling Lean & Product Development (2008) and Practices for Scaling Lean & Agile Development (2010). But after listening to the feedback on their books Vodde and Larman realized that they also needed to address readers who were new to agile and scaling, and who requested clear starting points. In the process of writing this forthcoming book – Large-Scale Scrum: More with LeSS – they have had to resolve the conflict between providing more rules/prescription and leaving the ownership fully to the teams, so they could experiment, learn and improve within their own context; they described this conflict as ”the process owning the process or the team owning their own process”.
“When you provide a lot of processes and guidelines to teams, then they will follow them without understanding the original purposes, without thinking and then they become useless… or even harmful,” says Bas Vodde. ”So, suddenly we realized that Scrum resolved this conflict by providing a small amount of Scrum rules. When you explore these rules and think about them, you realize most of them focus on creating feedback and providing transparency. This enables teams to take more ownership. Our conflict was resolved!”
And so the LeSS rules were created – three pages of them – which increase transparency and ownership at scale. ”The rules are simple to understand but hard to adopt,” says Bas Vodde. ”They also tend to be disruptive to organizations.”
From a bird’s-eye view, LeSS consists of four parts: 1) Principles, 2) Rules, 3) Guides, and 4) Experiments. The experiments were there first, as the mindset of experimenting, inspecting-adapting and continuous improvement is the very essence of LeSS. The rules describe two frameworks: basic LeSS (2-8 teams) and LeSS Huge (8+ teams). The guides explain how to implement the rules within different types of organization.
The 10 Principles are listed as the first part of LeSS, but actually came about last. These now consist of three types of principles. The first type are Scrum-based principles, such as “Transparency”, “Empirical process control” or “LeSS is Scrum”. The second type are not exactly principles but more bodies of knowledge, such as lean thinking and systems thinking. The last type are LeSS-specific principles, such as “Customer-centric”, “Whole product focus” and “More with LeSS”.
Bas Vodde on the difference between LeSS and other frameworks
Multiple Scrum teams vs Multi-team Scrum
Most scaling frameworks take a multiple Scrum Teams approach to scaling. The key question they ask is: “How can we get multiple agile (scrum) teams to work together”. LeSS, instead, takes a multi-team Scrum approach. The scaling question that LeSS asks is: “How can we apply Scrum when we have multiple teams?” This leads to completely different decisions about how you scale up.
Tailoring Down vs Scaling Up
There is an important distinction between tailoring down and scaling up. The traditional safe approach towards processes is to provide too many processes and then ask people to remove what they don’t need – they tailor it down to their process. The agile approach, on the other hand, is to scale up and provide the minimum amount of process and ask people to add to that only when they must.
Why is tailoring down harmful? Well, most of the tailoring down decisions are made at the beginning of a project. At this moment, the amount of in-depth knowledge of the product, market, or methodology is very low and people are likely to make the safe decisions to keep more roles, processes, and artifacts than they need.
More or less ‘agile’
LeSS avoids weakening the Agile values and principles while scaling up, dealing with more complexity and traditional organizations. We still want shippable product increments every iteration. We still want to be able to change direction at any time. We still want face-to-face communication and close cooperation with customers. We still want empowered self-organizing teams and emerging architecture and design. Some scaling frameworks relax the agile values and principles while others don’t. LeSS doesn’t.
Grounded in years of scaling experience
LeSS has been around for a long time. The rules, guides and name are new, but they are based on over a decade of experimenting with large-scale agile development in many different kinds of companies building a large variety of products.
“The basic LeSS rules explain how to apply Scrum to multiple teams by clarifying how the roles, events and artifacts scale,” says Bas Vodde. “LeSS – unlike Scrum – also has rules for organizational structure. Craig and I have seen over and over again that if the organizational structure isn’t affected then the Scrum/LeSS adoption will be shallow or even fail. So, we’ve added several structural rules such as dedicated, co-located teams, majority of feature teams and full-time ScrumMasters.”
As Bas Vodde sees it, the strength of LeSS is that it takes a minimalistic approach to being a scaling framework. It doesn’t to add any unnecessary complexity and instead is as small, flexible, agile, and lean as possible.
“We often say that ‘LeSS is for scaling development and descaling the organization’. This seems like a contradiction, but isn’t. LeSS dramatically increases team’s responsibility leading to less traditional roles, processes and artifacts. This leads to simpler organizational structures.”
The beauty of this organizational descaling is that it leads to less complexity with fewer roles, fewer artifacts, and fewer processes.
“This results in more responsibility to the teams, more thoughtful and meaningful work, more ownership, passion, and improvement,” says Bas Vodde. “More outcomes. Hence, this principle is named: More with LeSS!”
Read more
Two LeSS books are currently available: Scaling Lean and Agile Development and Practices for Scaling Lean and Agile Development — both by Bas Vodde & Craig Larman. Their third book, Large-Scale Scrum: More with LeSS, will be published next year.
On the web, the LeSS meeting point is http://less.works where two certified training programs are currently available: Certified LeSS Practitioner and Certified LeSS for Executives.
