Bas Vodde and Craig Larman framed and introduced Large Scale Scrum (LeSS), the scaling model.
Large-Scale Scrum (LeSS) is Scrum applied to many teams working together on one product.
LeSS is more than a set of principles and experiments. It also provides a framework with rules. The LeSS Rules define what is LeSS (and what isn’t) and they provide a concrete framework for applying LeSS. Within the LeSS Framework, product groups can apply the experiments and discover what works best for them at a certain moment.
LeSS provides two flavors of large-scale Scrum frameworks:
- LeSS: Up to eight teams (of eight people each)
- LeSS Huge: Up to a few thousand people on one product.
InfoQ interviewed Bas and discussed about LeSS and LeSS Huge.
InfoQ: Could you please introduce LeSS for the readers?
Bas: LeSS is a product development framework for building products with at least two teams. The framework is based on the Scrum rules, but extend them to create a multi-team Scrum.
The extended rules contain
- Explanation on how to do the Scrum events with multiple teams,
- Additions mostly relates to the structure of the product development group (“product development group” is the term we use for the organization or department building the product).
Next to the rules, we defined ten LeSS principles.
The principles come in three flavors:
- Scrum-based principles like transparency or empirical process control,
- Meta-principles like Lean Thinking and Systems Thinking, and
- LeSS-specific principles like Whole-Product Focus and Customer-Centric
LeSS also has about 50-or-so guides which are mostly explanations on how the LeSS Framework can be adopted in organizations and what kind of changes you can expect.
The last part of LeSS is the LeSS experiments, about 600 of them, which are ideas to try out or avoid when scaling agile development.
InfoQ: What is the core concept of LeSS?
Bas: At its core, LeSS tries to stay true to the Agile Manifesto and scrum while figuring out how to work with more teams on the same product.
Around the time the Agile Manifesto was created, Jim Highsmith, Co-author of the Agile Manifesto, coined the phrase “barely sufficient methodology” and that phrase would fit LeSS well. It comes with a realization that for adopting continuous improvement involving everyone in the organization, you’ll need the teams to own their process. This means abandoning the scientific management concepts of separating the planning from the doing the work. It also means abandoning strong project management, which is an evolution of scientific management.
In addition, we want to manage products as products and not as projects. This leads to permanent long-lived teams owning their work and continuously improving forever. The effect of having lots of roles, artifacts, processes, and layers is that the team does not own the process, but the process owns the teams… With LeSS we don’t want any of that and instead have less roles, less artifacts, and less processes. Less of those means more ownership, creativity, improvement, and more purpose. We call this principle More with LeSS.
InfoQ: What is the purpose of incorporating Lean thinking and Systems thinking in LeSS framework as principles?
Bas: Eh. Both Lean Thinking and Systems Thinking have influenced me and Craig hugely. We want everyone involved in LeSS to be aware of these two thinking tools as they clarify how LeSS works and helps you solve concrete problems in your development.
Historically, Lean Thinking and Systems Thinking were part of the “Thinking Tools” that we described in our first book “Scaling Lean & Agile Development”. When reflecting on the LeSS principles, it crossed our minds to make actual principles of them, such as “optimize the whole” and “respect for people” but we decided to not do that and keep them what they are and just call them principles (while they are more thinking frameworks than principles).
For people interested in learning more about these ‘principles,’ let me recommend some sources that I’ve found valuable. For Lean Thinking, there is a lot of stuff out there and it isn’t all good. I usually recommend looking for things that stay close to the Toyota origin rather than are interpretations of that. Usually the work of Liker and Ohno can’t go wrong. I’m especially fond of a little book from Ohno the creator of the Toyota Production Process, called “Workplace Management”. For Systems Thinking, the work of Peter Senge never grows old. For other applications of systems thinking, check out John Seddon’s work or Gerald Weinberg, who’s been writing about the application of Systems Thinking for software development forever.
InfoQ: LeSS framework has two versions – LeSS and LeSS huge. What is the difference between these two?
Bas: Correct. The LeSS or basic LeSS Framework is for 2-8 teams and the LeSS Huge framework is for 8+ teams. LeSS Huge is an extension to LeSS for larger product groups. LeSS contains 2 pages of rules and LeSS Huge is one additional page to that.
The reason for the two frameworks is that after about 8 teams, you’ll need some additional scaling techniques that help in scaling the product owner and product backlog. However, these additional techniques shouldn’t be needed when you don’t have around 8 teams. They’d just complicate your development. They actually have a negative impact when used on small LeSS adoptions. To make this clear, we decided to split the framework in LeSS and LeSS Huge. You can think of LeSS Huge as multiple LeSS stacked on top of each other.
InfoQ: “LeSS is about scaling up Scrum itself in order to achieve organizational descaling”. How LeSS helps in descaling?
Bas: When adopting LeSS, it will affect the structure of your organization. What often happens is that organisational problems that are traditionally solved in a complex way, are solved in an easier way in LeSS. Having small batches of working software Sprint by Sprint enables removal of organizational complexity that was created for coping with the lack of transparency in traditional development. This is best explained with some examples.
Traditionally, organizations manage work using projects. A project, from an Agile/lean perspective is a way of managing a large batch of requirements towards a release. When focus on products and continuously delivering value to users, the project way of managing work becomes largely obsolete. It is much easier to manage small batches of work via a product backlog for the life of the product. This also allows to invest (budget) in the product based on predicted and realized customer value. Thus good LeSS organizations descaled the organization by removing projects and project management and solve the organizational problem of managing work in a different way.
To take that further, often large organizations have project portfolios of different projects (inside the same large product). When considering a project as a big batch of requirements, then project portfolio management means big batch requirement prioritization. not something we would encourage. Thus, instead of doing that, we consider the definition of product to be expandable and prefer it to be broad so that the product backlog performs a similar role as a project portfolio, but with simplicity and fine grained prioritization.
InfoQ: LeSS also puts emphasis on technical excellence. How important is it and what are the benefits?
Bas: Without it, your development is likely to fail.
Craig and me use the expression “organizational agility is always constrained by technical agility” to express this. You can’t be flexible as a company without being flexible in your codebase, in other words, if your code is a mess you are slow.
We are of the opinion that very few organizations realize the importance of technical practices. Most pay lip service to it. When diving in code bases (which is one of the things we like doing most), it is amazing what you find even in the most ‘agile’ development shops. When the code is messy, with lots of duplication, lacking domain abstractions and without automated tests, then making changes is tedious and it won’t matter how you organize your development, you are inflexible.
InfoQ: Would you like to tell about your upcoming book?
Bas: Well, I wish it wasn’t upcoming anymore :) We originally thought this book would be a small project, but in practice it has turned into monster project. Anyways. The book is called “Large-Scale Scrum: More with LeSS” and it describes the LeSS rules and some of the LeSS guides that help in adoption. It should be an easier read and slightly more prescriptive than the previous two books. It should have been out already, but realistically it will be available early 2016.
To share a bit more about it, the book is structured in three parts: 1) structure, 2) product, 3) Sprint. The structure part talks about the product group design, roles of management and scrum master, and adoption. The Product part talks about product backlog, product owner, product backlog refinement, and definition of done. The Sprint part covers sprint planning, review & retrospective and coordination & integration.
InfoQ: Please share some information about LeSS trainings.
Bas: Yes, you joined. I hope you liked it!
Me and Craig have created two certified training, of which we consider the Certified LeSS Practitioner to be the major one. It is a 3-day course diving into LeSS and adoption of LeSS to organizations. After that, the participants will be Certified LeSS Practitioner and receive an account on the less.works website, which we consider the home of everything LeSS.
We’re setting up a trainer network so that there will be training available everywhere in the world.
For people interested, you can find the course schedule on website.
InfoQ: Would you like to give any message to the organizations for LeSS adoption?
Bas: If you are looking for a simple change that is easy to adopt and provides a quick-fix for your development problems… don’t adopt LeSS. If you are interested in a long-term improvement in the development that tends to be disruptive, LeSS is the right thing for your organization.
Seriously, LeSS attacks some structural problems in organizations which can lead to dramatic improvements but isn’t easy. Be persistent and keep learning.
InfoQ published a few articles early this year on Introduction to LeSS , Bas Vodde on the LeSS Framework and Using LeSS with Feature Teams to Ship Your Product Every Sprint.
If you want to know more about LeSS implementation refer the LeSS case studies.
About the Interviewee
Bas Vodde is an experienced coach in agile methods and especially Scrum. He's also a certified Scrum master trainer. Next to Scrum, he trains and coaches teams in TDD, retrospective and agile planning. He is originally from Holland, however has lived in China, Finland and is currently living in Singapore. In the 90s he worked as a developer in Holland and felt a mismatch between what he experienced as working and between "what the official literature said you should do". That was solved with the introduction of Extreme Programming and evenmore so, with Agile Development in general. In the beginning of 2001, he had enough of the "normal life" and moved to China where he started working for Nokia. Here, he gained experience on very large projects and the traditional ways they are run. After this he became even more convinced that Agile Development is the way forward, for all size projects. Currently he is running his own small coaching and training company called Odd-e.