Craig Larman has spent the last decade helping large organizations reshape the way they approach software development in the large. Together with colleague Bas Vodde, Craig has developed a Scrum-based framework that they call LeSS. Where others promise packaged solutions – Craig offers hard work and an experimental mindset based on deep agile and lean principles.
Let’s begin with the name of your framework, LeSS, what does that mean?
LeSS is short for Large-Scale Scrum. I often suggest to people that if they want to understand the key ideas in some system 
of thought or practice, then consider the name itself, and examine why the founder named it that. Why is Scrum called Scrum? Why is agile called agile? And similarly with LeSS.
First and hopefully clear from the name Large-Scale Scrum starts with understanding Scrum for the standard one-team Scrum definition and its deep ideas, such as (1) empirical process control rather than following a process recipe, (2) a cross-functional real team together that does everything end-to-end (from UX analysis to testing to HI design to architecture to documentation, with no other teams required), (3) a team which is composed of multi-functional “T-shaped” workers rather than single-function mono-specialists, and (4) the team follows the direction a real business-side owner of the product responsible for ROI (e.g., head of product management) rather than an IT project manager or business analyst.
From that understanding, to adopt LeSS then requires examining the purpose of one-team Scrum elements and figuring out how to reach the same purpose when the context is many teams, while staying within the constraints of the standard Scrum rules. Not for ‘religious’ Scrum-adoption reasons, but because the Scrum rules are creating the context for transparency, empirical process control, system optimization, and structural change.
For example, in LeSS with multiple teams there’s just one Product Owner, one Product Backlog, and one Sprint that ends with a shippable and ideally shipping product, every Sprint. And the teams own and evolve their processes, rather than processes & practices being pushed on to the teams. Just like in one-team Scrum.
The second implication of the name LeSS is… less. Rather than pushing a large and complex set of processes, structures, roles, and artifacts on to a group, we keep it very simple. The idea is that LeSS defines a “barely sufficient methodology” (a key idea in the early agile days) for a group to scale, to enable shipping every Sprint, and to enable transparency and empirical process control. We feel very strongly that a group should scale up a simple framework from simple elements, rather than attempt to “tailor down” a complex process framework.
The slogan of LeSS is more with LeSS. So, more learning and adaption, less following and conformance. More value, less bureaucracy. And so on.
A third and related implication of the name “less” is, ironically, to descale the organization. In other words, LeSS is not attempting to “enable” a big awkward organization to “do agile.” Rather, as with Scrum, it exposes the organizational design elements that are wasteful and unskillful, and moves the organization to a simpler model, a less complex system.
Who uses LeSS today, and how are they doing?
First, the less.works site has a case study page, though this is of course a miniscule fraction of the groups around the world that have adopted LeSS over about the last 10 years. We semi-regularly get an email from someone at a company that says, “Hi! We read your 2008 LeSS book, Scaling Lean & Agile Development: Thinking & Organizational Tools with LeSS, and changed the organization to a LeSS model. It’s worked well. Thanks!” So there are surely many adoptions we haven’t heard of.
If by “who uses LeSS” you are asking about industry-domain patterns, it’s really varied across domains. For example, the LeSS case studies include healthcare, financial services & trading, telecom equipment, online gaming, port shipping traffic management and radar systems.
Closer to home for Swedes, there’s been several LeSS adoptions at Ericsson. There’s even a LeSS case study on one of them. Over the last few years, I’ve given several internal keynotes at Ericsson conferences related to LeSS, supporting their adoptions. Because I haven’t worked closely inside lately, I don’t know how things are currently going, but I have heard that the Ericsson product group for “Media Gateway for Mobile Networks”, which did a LeSS adoption, is going well.
That said, I’d like to debunk a common misunderstanding: Scrum, and LeSS, are not solutions that create success. Rather, they are frameworks for transparency (and empirical process control) that powerfully and quickly expose deep weaknesses and problems. Then the group has to address those weaknesses and adapt. Many groups claim they want transparency, but when it is actually and painfully introduced by introducing real Scrum, it challenges so much of the status quo or is embarrassing to the status quo forces, that there’s a reaction to “customize” the framework to “fit in our environment”, which essentially means, “we don’t want to have to expose that weakness, or change the status quo.” A really successful LeSS adoption causes a descaling of the organization to a much simpler system, but that’s quite disruptive to the traditional organizational model. So for the status quo, a “successful” LeSS adoption is one in which LeSS is modified so that nothing meaningful changes
How would you explain what’s different with LeSS to someone who is considering learning more about scaling agile?
LeSS (Large-Scale Scrum) is the simple high-impact framework for scaling lean and agile development designed to optimize the whole system. It’s based on over a decade of adoptions in many big groups worldwide (e.g., see case studies). In addition to learning about it at less.works, it’s described in the three books on LeSS that come from that decade of experience: (1) Scaling Lean & Agile Development: Thinking & Organizational Tools with LeSS, (2) Practices for Scaling Lean & Agile Development: Large, Multisite, & Offshore Development with LeSS, and (3) the upcoming third book, More with LeSS.
Although LeSS is described as for scaling, a key purpose of LeSS — the implication of its name — is actually descaling through organizational simplification. Descaling the number of roles, organizational structures, dependencies, architectural complexity, management positions, sites, and number of people. LeSS is not about ‘enabling’ an existing big and clumsy organization to “do agile” by painting agile labels on top, it is about scaling up the simple Scrum framework itself to achieve organizational descaling.
In a way, LeSS is simple because there’s only a small set of elements, whose purpose is transparency and empirical process control. It’s ‘hard’ because transparency reveals weakness, and empiricism requires learning and change rather than following a recipe.
Unlike some other scaling frameworks, LeSS does not define a one-size-fits-all detailed recipe, and like Scrum, is based on recognizing that development is too complex and situational for a prescriptive detailed recipe that a group can just “buy and install.” Rather, it will require creating a learning organization, and lots of situational adaptation.
There are no fancy titles, no trains, no layers of management, but when you simplify and descale, you ought to be able to achieve more impact and flexibility with LeSS.
Meet Craig Larman and learn more about LeSS 4-6 nov