BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Podcasts Bas Vodde on LeSS, LeSS Huge and Descaling for Agility

Bas Vodde on LeSS, LeSS Huge and Descaling for Agility

Bookmarks

In this podcast recorded at Agile 2019, Shane Hastie, Lead Editor for Culture & Methods, spoke to Bas Vodde, one of the formulators of Large Scale Scrum (LeSS) about how LeSS is designed to descale an organisation rather than scaling up to cope with complexity

Key Takeaways

  • LeSS is based on the idea of de-scaling and reducing complexity rather than scaling to cope with complexity
  • A characteristic of LeSS adoptions is that the concepts of projects and programs tend to completely disappear in favour of product-based working
  • With LeSS, you have always one Product Owner for the entire product.  Product owners per team are considered to be an exceptionally bad idea from a LeSS perspective
  • LeSS is based on having largely stable, cross-functional teams working on customer centric functionality
  •  LeSS is based on a set of ten principles which guide the approach, and then imperical feedback based on experiments and constant learning

Transcript

00:00 Shane: Good day folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. I'm at Agile 2019 in Washington, DC and I'm sitting down with Bas Vodde. You are one of the original authors of LeSS,

00:19 Bas: I'm one of the formulators of LeSS, together with Craig

00:25 Shane: and you're an agile coach at Audi, based in Singapore.

00:28 Bas: I am.

00:29 Shane: And you're at the conference. LeSS is one of the sponsors?

00:33 Bas: Nope.

00:34 Shane: Not a sponsor

00:34 Bas: The Fans of LeSS are a sponsor.

00:37 Shane: So the Fans of LeSS are a sponsor.

00:39 Bas: I want to stress that, because I think this is a wonderful thing that happened here in the conference where the community decided that we're not promoting LeSS enough yet in conferences and other things.

00:54 So the community people asked, do you mind if we start sponsoring conferences and having a booth and things like that. And we said sure enough.  They did say,  can you guys pay for it? Sure, no problem. But it is whole community driven and everything you see or saw at the booth over here has being the community deciding they just want to get the word out of LeSS more.

01:24 And I think that's wonderful. I think that makes it the first and probably only community sponsored both here at the conference.

01:31 Shane: For those that haven't come across LeSS, what is it? What does it stand for? What's it about?

01:40 Bas: LeSS is a way of building products with more than one team. Originally less stands for large scale scrum, it still does, but usually we say LeSS rather than large scale scrum, that's too many words to say. We want less words to say, and it originates out of experiments in organizations that me and Craig did, which is why I said formulated.

02:05 Starting in 2006 or so, we did years of experimentation, wrote two books. A catalog on experimentation in organizations describing what worked well for us and what didn't work well, and you probably don't want to redo our experiments.

02:26 And then after that, we started packaging and formulating that into what we now call LeSS. It's interesting how that has grown and evolved and now some of the basic concepts, which is why we liked the name, also a lot.

02:41 The basic concept is if you want flexibility or agility or adaptiveness, then that means you need to have simpler organizations because complexity, complex organizations, creates slowness and therefore you need to work on simplifying, which sometimes refer to as de-scaling the organizational complexity.

03:08 And therefore LeSS is a big differentiator, in that it doesn't focus that much on roles or processes, but it focuses significantly on structural changes in organization.

03:21 Shane: How do you de-scale an organization to get bigger products?

03:26 Bas: There's a lot to it, but I'll just give some examples and I'll give this specific example because I notice from the previous podcasts,  one week ago, that you've got a new book out on no-projects.

03:40 So one of the things that usually happens within LeSS adoptions is that the concepts of projects and programs tend to completely disappear. It's product focus, and then there's a lot about what your product should be, so from a LeSS perspective, your product definition, that tends to be much larger than what people originally thought.

04:03 And because of the removal of projects and expanding of the definition of products and the usage of customer focused feature teams, each of those changes tend to to remove roles out of the organization and bring the teams closer to the customers. And that we then refer to us that removes or de-scales the organizational complexity.

04:29 Shane: So this sounds to be almost directly opposite of what we see in many of the so-called scaling frameworks.

04:37 Bas: Correct.

04:38 Shane: Why?

04:40 Bas: Well, let me try to stay as nice as I can. The largest scaling framework, SAFe, seems to have accepted a lot about how organizations are, and sometimes we'd say that they start off from the question, how can we make the existing organization more agile, rather than how does an agile organization look like?

05:07 It's a very different starting question. And similarly, Disciplined Agile starts from exploring the current context and organization and then adopting different practices within that.

05:22 So in that sense, both of them start off from, we have this organization, how can we gradually change that a little?

05:32 And in LeSS we start off from, we want to have this agile organization, if you wish, this flexible organization, and then it still provides the tools for going there for the graduation adoptions, because if you have say 2000 people you're not going to change that overnight, you can expect a decade of change at least.

05:57 So the tools for how to get there gradually, still are there, but the starting point is just very, very different. The starting point is we must try to simplify and remove complexity out of organizations. We must try to get the people building the product work as closely as possible, directly with the people who are going to use the product, try to remove everything in between that and try to change the organization to supporting that to happen.

06:31 Then Nexus is okay, more or less, similar than LeSS. The meeting structure and ceremonies in Nexus and LeSS are very, very similar, but then it's a little bit softer on the structure and it provides recommendations that often make it almost the same as LeSS, but in Nexus they're just recommendations for implementation, where in LeSS those structural things are considered to be the essence of LeSS.

07:03 Shane: What does a LeSS structure look like? If I'm maybe a banking organization and I've had the traditional IT siloed approach, we are trying to become more agile and LeSS sounds like a good idea. What's that going to look like on the ground to my teams?

07:22 Bas: For now, for sake of this question, I'll start off assuming that there's, say, five teams or so, and the reason for that is there's two variance of LeSS, the two to around 18 variant, which we call LeSS or Basic LeSS and then the around eight plus team variant, which we tend to refer to as LeSS Huge. And I can explain LeSS Huge later, but LeSS Huge is based on many of the basic LeSS adoption structures. Therefore that's easier to start with.

07:59 Organizationally, you have always one Product Owner for the entire product.  Product owners per team are considered to be an exceptionally bad idea from a LeSS perspective. If you have say five teams, you probably have two or three Scrum Masters, maximum, who work on that full time.

08:20 The teams are cross functional in organization, as in they do not report to functional departments, but they tend to have cross functional managers who tend to still be there. If you didn't have managers, of course, you don't need to add them because you don't want to add more things. 

08:40 They tend to work off of one backlog. Teams work on customer centric functionality, so they don't own components or technology. Instead they work across the product on customer centric features and they clarify much of those features together with whomever's going to use that. So there's an as much as possible direct connection between the team building it and the people were later going to use that.

09:12 One big change is often where we say the team needs to be what we refer to as, not a programming team, but a product development team. They need to understand the business domain; not one person, but the team needs to understand the business domain. They need to understand the problem that they're trying to solve. Not just take orders from users or customers, but instead understand their problem and together work with, using their technology knowledge, to build the best possible product.

09:47 Shane: Okay, so that sounds very much like the value stream concept, that I'm an advocate of.  This concept of all of the skills within the stream, so the value stream being perhaps that product line. If you've got  teams talking directly to the customers all the time, which definitely sounds like a great idea, what are you doing with the Product Owner?

10:12 Bas: Well, there's only one, remember, product and the Product Owner is the one with the vision and prioritization. If you go back to the origins of Scrum, then the Product Owners that we often see in organizations do a lot of stuff that is not actually the Product Owner responsibility in Scrum.

10:38 The Product Owner doesn't accept things, the Product Owner doesn't create acceptance criteria. Product Owners definitely don't write stories and Product Owners do not even have to do all the clarification of features. And in LeSS they don't, that kind of work are kind of, you know, one team Scrum scenario, added responsibilities or practices of a Product Owner. 

11:04 A LeSS Product Owner doesn't do that, and instead focuses on vision ,focuses on prioritization, decision making related to considering multiple users, what are the most important things to do? Stays in contact with the business themselves, the customers themselves to understand all of that and usually is the responsible person in the organization for all the development.

11:32 Shane: Are we  back at, dare I say, the single wringable neck.

11:36 Bas: Why back?

11:38 Shane: In Scrum, we've heard of this single wringable neck for a while, and there's been quite a push back against it.

11:44 Bas: The phrase is not necessarily the best phrase, but yeah, and this is the same in Nexus.  In Nexus it's one Product Owner for one product, and I don't think that has really changed. It's just been, unfortunately, misinterpreted and the Product Owner has become, in many locations,a   business analyst, working with teams, clarifying features, which is not what the role ever intended to be.

12:16 Shane: Coming back to the essence.

12:18 Bas: It's going back to the origin and the essence of what a Product Owner ought to be in Scrum, and then just clarify that in a larger context.

12:29 Shane: How do we ensure collaboration across multiple teams?

12:33 Bas: Take a step back before answering that question. So LeSS consists of 10 principles and set of rules, which we sometimes refer to the framework, a set of guides, which I like to describe as the typical implication of applying the rules on an organization and then a whole bunch of experiments, which is the way knowledge gets shared within the LeSS community.

13:04 So within the LeSS community, the phrase and concept "best practice" is considered to be a bad idea, a bad practice, and instead, everything is described in a context specific way, usually using experiments where people would say, you know, we were in this context  and we tried out this, the results for us was...  Either positive or negative or nothing, and there's no guarantee that within your context, you'll get the same results, it's just me sharing my experiences with the community.

13:42 You can find a lot of case studies on the LeSS site, which are full with experiments that people tried out.

13:50 Now, getting back to the principals though,  two seemingly simple principles are very impactful and those are:

14:01 Customer Centric, the principal Customer Centric, which basically boils down to everyone, every team, every member of the team needs to understand the customer, their domain and why they want what they want.

14:16 And then the principle of Whole Product Focus, which basically means that every team, even though they're working and on a small part of the product, still, they need to understand the larger product. They need to understand that if they just build their small part and it doesn't actually work well with the other parts, there is no product.

14:40 And those principles are reflected within the framework itself. For example, the backlog refinement, if you have five teams then the prefered way would be to do that with one multi-team product backlog refinement, but not with  individual teams.

15:01 Now, usually that's done woth what is LeSS is called big stop groups. Which means that we form smaller, say again, maybe four or five groups, but each of these groups has at least one member of the teams and they clarify the functionality, the features together with, I'll simplify it with users, but in practice, there's a lot more nuance to that, and then what happens is that in every team there's members together, who clarified all of the features within the product.

15:39 Then once you start the sprint, again the sprint planning. Is split into the One and Two, the traditional Scrum division. The first one, Sprint Planning One, tends to be shared across all of the teams where all of the teams together, decide which teams are going to work on what. They all have  enough knowledge to pick up any of the items from the backlog. They'll have a discussion between them, of course, still based on the priority order teams pick up the items they'd like to work on, and because they all know what other teams are working on, and they all know what the functionality is and they all work on one shared code base, because of that during the sprints, we actually rely on a lot of the spontaneous informal coordination between teams. So teams tend to do a lot of cross team pairing and things like that.

16:43 Shane: Tell us more about the 10 LeSS guiding principles.

16:47 Bas: There's 10 of them. Two of them I already mentioned

16:51 There is the More with Less principle, which is what we consider the most impactful one, which suggests what I mentioned earlier that we need to create less structure and processes and artifacts.

17:05 There's principles taken from Scrum the Transparency and Empirical Process Control. They're kind of elevated towards LeSS principles.

17:17 There's the Large Scale Scrum is Scrum principle, which mostly refers to the staying true to the essence of Scrum, not the framework, but the essence and it refers to the usual problem solving technique of always trying to map any problem to a one team situation and trying to solve that within that context.

17:41 Then there's the broader thinking tool principles, System Thinking, Lean Thinking, Queuing Theory.

17:50 And then there's the Continuous Improvement Towards Perfection, which is kind of taken out of lean Thinking to be its own principle.

17:59 And I didn't counted them, but I hope those  were 10, otherwise I've forgotten one.

18:03 Shane: What is LeSS Huge and how does that work?

18:10 Bas: Yes. So after around eight teams, eight is not a hard number, it becomes hard for the Product Owner to keep an overview of that one product.

18:23 Shane: How many products are going to have eight teams working on them, individual products?

18:28 Bas: Very many, because most of what we call a product in LeSS tends to not be equal yet, what is a product in, for example, a bank? So a product is never an application. A product is always all of the larger systems together for actually delivering value to customers.

18:51 So what is your product is actually a significant part of LeSS.

18:55 So for example, I just finished working with a bank and they're a section of around 250 people we would consider to work on one product.

19:07 To go back to the original question and so the common scenario of LeSS Huge, you start categorizing the functionality in the product backlog based on a customer centric perspective. Common ways are groups of users, industries, or business processes, and then you create a view or a perspective on the product package.

19:34 We like to think of it as simply a filter in Excel, and then have a group of maximum eight teams working semi-permanently on that subset, and the view of that backlog is called an Area Backlog and then there tends to be a person who acts as a product owner for a particular area although those areas are never smaller than four teams.

20:02 Shane: So in this case, you then have multiple Product Owners.

20:06 Bas: ou have Area Product Owners and one product owner.

20:11 Shane: A-ha - so now there's a hierarchy.

20:13 Bas: No, it's not an hierarchy.  The Area Product Owners usually function fairly independently, and the main thing about the Product Owner is to determine overall product vision, and cross area prioritization.

20:32 If we have two areas and the features in area one are over lower value or strategic importance than the features of area two, then that means that that's where I mentioned semi-permanently, teams start moving between areas again, to get the flexibility, the agility that we need at that scale.

20:55 Shane: That's LeSS where it is now, what is the take-up, what's happening in the marketplace?

21:01 Bas: It's growing gradually and we're pretty satisfied how things are going. Most of the LeSS adoptions we see in Europe where several large companies adopted LeSS that has impacted the market. Similarly in Asia, reasonably.  And now we are here in the U S and that's been a bit less.

21:27 Shane: And the evolution of LeSS, where's it going? What's on the horizon?

21:32 Bas: Don't think much will be on the horizon. I mean,LeSS is not, again like another particular framework where it needs to get simpler over time, it's not a collection of all practices stuck into a framework, that's exactly what we don't want. So therefore, I don't know, but the future, but they're not that likely to change and the rules or frameworks are three pages and that's it and over time they should become less.

22:04 We do have a change notes page and one of the LeSS trainers once looked for a word cloud within that change note to see whatever you're true to the spirit, and he did discover that the word removed was the most common word for the changes where we  tried to make things simpler and try to get more to the essence. So over time, you'll get more guides and experiments and case studies of people adopting LeSS and sharing experiences with each other. So that will grow.

22:39 But the essence of LeSS is so small,  you've been around for a while, back to the barely sufficient methodology principles that it's not incredibly likely to change.

22:52 Shane: Thank you for that. Switching topics. You've spent a number of years in Singapore.

22:56 Bas: 11 already

22:58 Shane: Wow - that means we've known each other a long time because we met in one of those early Agile Singapore conferences.

23:07 What is the state of agile in Singapore and how are things going in that region?

23:11 Bas: I think things are mostly going healthy. One of the favourite things that I liked in Singapore is that the Singapore government has created their own development group,  GovTech, I think you've heard of that before. Some of the people that I worked with gone, there are some people that are trained, gone there and they've changed their government to pick up agile projects and they've grown significantly  and they have a wonderful space, and I think they've been doing a really great job in there.

23:41 And it's interesting to see a lot of the good agile development being done by the government. Now, next to that, there's lots of financial institutes in Singapore, and I think all of them are using agile development. The community's thriving, as you mentioned, there's been two large conferences. Big Dave  Thomas brought the Yow! Conferences to Singapore also. So it's a nice place. I'm sad that I'm actually not there often enough to join the community and to meet up with the people there. But I think it's pretty healthy.

24:18 Shane: Bas, thank you very much for taking the time to talk to us today. If people want to continue the conversation, where do they find you? Where do they find LeSS?

24:26 Bas: Well, LeSS is on less.works  which is the site. You can find the rules, the principles, a bunch of guides and experiments over there. You can find the case studies over there.

24:37 We ask people, the case studies are, they are actually not case studies,  they're experience reports with experiments that people did, and we ask, especially people who want to become trainers to write really thorough case studies about what really happened, not the marketing kind of case studies. So they're really good.

24:57 The LeSS Conference you can find information about which will be annually.  The next one will be in Munich, but when you listen to this it probably has passed and you can join courses. There's a bunch of LeSS courses available all around the world. You can find them on the LeSS site too.

25:16 You can email me, sometimes I'll reply to email, I try to, I do get a lot of email. Or if you don't know my email, you can go to a course and simply click contact the trainer on the LeSS site and it will get to me also.

25:30 Shane: Excellent. Thank you so much.

25:32 Bas: Thank you, Shane.

Mentioned

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article

Adoption
Style

BT