Join Murray Robinson and Shane Gibson in a conversation with Bas Vodde on LeSS. LeSS is true Scrum at Scale not just at the team level. LeSS applies the principles, purpose and elements of Scrum in a large-scale context, as simply as possible. Many scrum teams with one product, one product owner, one product backlog, one sprint, one sprint planning meeting, one sprint review and one retrospective. Large-Scale Scrum is Scrum. Empirical process control. Transparency. More with less. Whole-product focus. Customer-centric. Continuous improvement towards perfection. Systems thinking.

Read along you will

Shane: Welcome to the no-nonsense agile podcast. I’m Shane Gibson.

Murray: And I’m Murray Robinson.

Bas: And I’m Bas Vodde

Murray: hey Beth. Thanks for coming on now, podcast. It’s great to talk to you. So the topic for today is less. What does less stand for?

Bas: It originally stands for large-scale scrum. but usually now we just only use less and we don’t often treat it as an acronym so much.

Murray: So tell us a little bit about who you are and what your experience is. How did you get here?

Bas: Okay. So I’m Bas. I’m a product developer for a long time and lived most of my life in Asia. Closer to you guys then now, and now living back in Netherlands again, and lots of experiences with large scale product development. And eventually encoded some of the things we did in what we now call LESS.

Bas: I originally started as software developer run the nineties, I was a software developer the Netherlands in the.com period. So working in startups then, and then lived in China for a couple of years worked there four Nokia. The Nokian network part, not a Nokia phone part. The part that is still Nakia now there started working for very large products and trying to figure out how to apply agile ideas, to larger scale development,

Bas: I was originally, one of the extreme programming adopters. I remembered a manifesto being written basically being told there’s now a new name for the things we’ve been doing.

Murray: Awesome. Not everybody knows what Les is. So can you just describe it for us? And , we’ll come back and ask you some more detailed questions. So just give us an overview.

Bas: So less originally means large scrub its focus was figuring out how to use scrum when you have more than one team and that’s still part of less but changed its focus to figuring out how to create more flexible, adaptive agile organization. So it focused a lot more on the things around the team because just focusing the teams and how they work together only brings you so far when the things around are still stuck in an old way of working.

Murray: So the way I remember it from the diagram is that you have your cross-functional agile teams running scrum, and if you have a product that needs several teams, then they all work off the one backlog and they all have one product owner.

Bas: Yes.

Murray: And that’s basically it.

Bas: That’s what we call the framework part.

Murray: Okay.

Bas: The preferred view of less nowadays is that it’s an combination of, the less principles and then the framework or rules, which is mostly the scrum, like picture that, explain Stevens and the flows and things like that. And then guides, which clarify the effects that you can expect to your organization adopting less.

Bas: And then experiments, which in a way is both the experimental mindset to just try out things within organizations and also, our way of sharing ideas between less adoptions and product. Because , we want to stay out of the fixed solution thinking and framing, everything as experiments that are in context and for particular problem with no guarantee that the experiment would work or fail in another context, I think is a nice way of promoting the learning, but getting out of the thinking that there’s best practices and fixed ways of doing things.

Murray: So I would urge listeners to go and look at the LESS framework while we’re talking, because there’s wonderful clear pictures there. So it said less.works. So it seems really pretty simple from the high level point of view, you’ve got effectively a combined backlog one product owner one sprint planning session, one retro. Does each team have its own planning and its own retro? Or do you just have one planning? I’m one retro.

Bas: in the planning site, it is split into two and the sprint planning one is shared across multiple teams and two is usually per team, but within the same physical location,

Murray: Yep. And the retros I do their own. And then that fades up to an overall one.

Bas: It doesn’t really feed up to an overall one. It’s just different scope retrospectives. Whereas in team retro you tend to focus on in sprint team thinks and an overall retro, you focus more on systemic and organizational things that happened.

Murray: So yeah , I’m doing something quite similar to this at the moment with her program. One of the questions I’ve got though is why is there only one product owner? It seems like the product I know would be spread too thin across all those different teams,

Bas: why do you think so?

Murray: because in scrum, even with a team of buyers, the product owner is normally a very demanding role. Like apart from prioritization, the teams expect the product owner to define the requirements for them and to approve everything that’s been done. And also they got to spend a lot of time with customers and marketing and stuff like that.

Bas: Yeah. So all the things stack you mentioned in after, apart from prior authorization is not something, a product owner would do. And that’s the team picking that on, we don’t want a person to be in between customers and the team, and ferrying information between them. The product owner role focuses vision and prioritization. The product owner in less does not make requirements except features, stories clarifies requirements, et cetera. That’s not something a product owner would do.

Murray: But how am I going to do the prioritization? Don’t they need to be talking to a lot of people to be able to do that. People in the business and also customers.

Bas: Not really Partly because the larger prioritization, which is what a product owner focuses on most, is mostly related to the vision and short-term goals of your product. And if there is an clarification needed in detail then the product owner usually gets input from teams and not focuses too much on too fine-grained prioritization.

Murray: Yeah, we talked to David Perrera a few weeks ago, who’s a product owner, and he was saying that he made a transition from leading one team to leading several teams by delegating everything down that he possibly could and focusing on product strategy and priorities.

Bas: Yeah, but delegating down would suggest that it would be officially his responsibility and unless it simply isn’t,

Murray: The scrum guide says that it is his responsibility.

Bas: The scrum guy does not say that then product owner needs to define requirements, write user stories, approve features and things like that.

Murray: No, but they need to make sure that it’s done. I’m pretty sure that’s what it says. We can go out and look up the scrum guide. Shine, ask a question while I’m looking.

Bas: Please do take the 2017 version instead of the latest version, because the latest version is mostly ignored by less.

Shane: Is that because it got watered down. Was that because it changed the intent? Why is it seen not applicable or usable with the changes that were made?

Bas: let’s just say it wasn’t an improvement in our opinion, especially Confucian related to two types of teams. That only got worse in the later versions. In less, we decided to for now just not focus on the latest version and who knows maybe clarify that way then and clearer description in the future.

Murray: So the current scrum guide says the product owner is accountable for effective product backlog management, which includes the product goal, product backlog items, ordering them, making sure that the backlog is transparent, visible, and understood. They may do it themselves. So they may delegate it to the others in the team, but they remain the accountable

Bas: and that would, in your opinion, include writing stories, clarifying features and approving them.

Murray: I didn’t say it was my opinion. I’m actually reflecting what people expect from scrum. And I know teams do expect the product diners to write the requirements.

Bas: That is where a lot of dysfunction in scrum comes from because the people who are writing the requirements tend to previously B analysts or business analysts and organizationally, they actually have no authority whatsoever to make product decisions. And that’s what in a lot of scrum adoptions where the product owner is a business analyst with a new name but not a product owner able to fulfill the responsibilities of visioning, deciding on date scope and the kind of things that a product owner ought to do

Murray: But the product diner is responsible for the product. backlog. Aren’t they?

Bas: Sure.

Shane: I see the product owner’s role is to make the prioritization decisions, if there’s a choice. If there is a trade off to be made, they engage with the stakeholders and they provide a single voice back to the team on what the trade offers. They remove the anti-pattern of writing stupid papers they go up to a bunch of stakeholders who have no understanding what you’re talking about and somehow make a trade off decision. That’s the role of a product owner. Now we’ve seen product owners adopt other things I read on LinkedIn this week about a person complaining that the product owner allocated them a task and only gave them three points. And the task was only a sentence and he didn’t understand what the sentence was. So, we see product owners behave in different ways. And product owners who come out of project management or a BA background tend to write lots of things, because that’s what they’re comfortable and good at. And they’re not so comfortable and good at , engaging with stakeholders to make trade off decisions. So they will revert back to what they know. And the team will easily delegate the writing of those things to somebody else. Cause it’s kind of dressy work. And I think that’s the best way for a team to operate. I would take it a bit further still because yes, the product owner is responsible and should focus on the trade offs and priorities, but more important than that’s still is that the product owner ought to be able to create and share that goal and vision for the product. And once the team is not just the team of picking up items, but they understand what is the product that we’re making for room.

Bas: Then, you can actually trust the team with a lot of prioritization decisions. Where you can simply say to the team, okay, what of these things do we think we need to do first and the team should be able to say this because division of the product is this and therefore, if we work on these items first, that will deliver the most amount of value. So it’s not just taking that prioritization decisions, but bringing that purpose of the product to the team.

Shane: Yeah, so that’s the difference between a feature factory team and a team that’s working to give it to achieve a goal, isn’t it?

Bas: Yes, except that within less all teams work on the same backlog and the individual teams don’t have separate, longer term goals, they all focus on the whole product. One of the 10 less principal, 50 principal of whole product focus, which means we do not want isolated, separate independent teams. Instead we want teams that understand that what they’re doing is part of a larger product, and they need to understand that larger product and understand how, what they’re working on now fits to that larger product.

Murray: Sure., so let’s take this opportunity to go through some of the other Les principles. So could you run through them for us?

Bas: Sure. So the principle I just mentioned is the principal of the whole product focus which to me it’s been a fascinating principle because it sounds so simple. And yet it goes against a lot of recommendations currently in the agile community. Then the second principle is customer centric, which again sounds very simple. But it also means, for example, for us that we do not want, a product owner in between, the team and customers because that reduces the customer centric newness of the team. And we want the team to be in direct contact with whomever is going to use the product.

Murray: Let’s say product had four main groups of features and you had four teams. Wouldn’t it be a good idea to have each team focus on one group of features as it, they can build up their knowledge about that feature over time.

Bas: Maybe because that would suggest that the priority of the features of each of those groups would be equal to each other.

Murray: Okay. But the alternative then would be, to break it down at a much lower level at the whole product, and then just get people to pick off whatever’s next in priority, regardless of what their team had been working on before.

Bas: Sort of . What happens in less is that you take all features together. You put it in a product backlog and just like scrum, you prioritize the backlog. And then if you wish, just like scrum, you take the top of the backlog, but you just don’t give it to one team, but to the teams. And then there’s a conversation between the teams talking about how best to solve that. So which team would want to work on what, which team would like to learn different areas. So there, you might get that conversation where one team says, we’re working with this customer before we know him therefore we’d like to pick up these items from the backlog. And then perhaps another team saying you’ve been working there for a while already.

Bas: And if we look further on the backlog, there’s a lot of more features coming related to that. So therefore this sprint, we would like to pick that up in stand and have your support with that. So you have this cross-team conversation in the beginning of the sprint planning on how the teams are going to solve the top of that backlog but are not pre assigned in any way to the team.

Shane: Yeah. So what you’re saying is that we don’t put hard and fast swim lanes in place and teach the teams to stay in this swim lanes. We don’t create isolation by design. What we say is just a shitload of work to be done. And we trust the teams to talk to each other and figure out what the next piece, that of hives priority work they can deliver and they talk to each other via usual collaboration and then decide and get on with it. So we don’t provide a framework for them. We just trust them that if we give them the goal, they’ll work to give up and achieve it. Is that what I heard?

Bas: Yes. And addition to that we promote as much cross team collaboration as possible. So that, for example, if there’s , items that are closely related in the product backlog. Then it is very common for two different teams to take that on purpose so that two teams will need to work closely during the next sprint, rather than trying to make the teams as independent as possible during this sprint. So in that sense, it’s opposite to a lot of recommendations to try to create, independent isolated teams who can focus on their individual team output. That’s not what we want. We want to have multiple teams working together and constantly learning from each other.

Shane: So what you’re saying is two teams will actually reform for a period of time to achieve the goal.

Bas: They don’t reform. So they typically stay , within the teams. Although in practice, it is the choice of the teams. It’s just the boundary between the teams becomes a little bit vague. In identity and work accountability, it is very clear. But in your daily work, it is very common for you to spend the half a day pairing up with somebody in another team, because he happens to know something, that you need for something that you’re working on now. So in the actual working together, the boundaries become much more vague.

Murray: So how the decide, which team works on which thing is there some sort of leadership team do you get a hundred people in a room together, like safe or what do you do? Is it three Amigos?

Bas: no, the teams together would decide that and because of the way Les is structured. So there’s two scales. So you have basic less, which is up to about eight teams, and then you have less huge where you divide the backlog in areas, each area is up to about eight teams. it means in practice is that this discussion cross teams on who’s going to work on what at maximum involves eight teams. and for me, I always have a rule of thumb that eight teams is maximum around 50 people, or so. So in sprint planning, one, you will have maximum around 50 people together talking to each other to decide how they are going to divide the items that are on the top of the backlog, which team is going to do what, et cetera, et cetera.

Shane: So, Would you recommend a 50 person sprint planning workshop?

Bas: That’s the common way of doing that? Yes. The most common way of working on this is where you take the product backlog and you print it on carts and you just put it on a table and the teams gather around the table and they typically have a conversation with each other about which of the items which team would take and how they are going to collaborate. Most of the time it takes maximum about 30 minutes or so. And then each of the teams break up to do their own sprint planning.

Murray: So what is the role of management in Les and why would management support it?

Bas: Management’s focus in less is not so much on the day to day activities and definitely not on deadlines, the features et cetera, the product owner related things. But it should be on the capability of the teams. The skills, the things that are blocking the teams from expending and improving the quality and output of the different teams.

Murray: Okay. So why would management want to implement less? Because it seems like there might be less managers involved.

Bas: There are some less adoptions that involved removing some management most less adoptions that I’ve been involved in not explicitly remove management other than things like project and program management which is obviously not required in less because there’s no projects or programs.

Murray: So how do the teams get their funding then?

Bas: And that’s where the product backlog is very helpful. You see what the features are that are coming for your product. Roughly what potential value there might be delivered to your product. And then if you wish you invest for a period of time in that product. So say for free months, I’m going to invest X amount of budget within this product without tying it directly to that scope. So the product owner is free to change the scope during that time period. then typically, you’ll stop. And you’ll look at the features that are coming and you ask the question, do we want to continue investing the same amount of budget in this product more or less?

Murray: We’ve talked about less to a number of our guests, people, and it always comes up as a a lightweight scaling framework, which would Shane and I are attracted to particularly in comparison to safe which is very heavy. What are the benefits of less in comparison to safe?

Bas: As an organization, you need to deeply understand what kind of problems you face. Most of the time, when I see an organization adopt safe, they say, we want to do an agile framework. Therefore we buy X, but not now in our development, we have this and this and this problems. We want to improve those problems and safe is going to help with those particular problems. One of the biggest problems I see is that people, especially management often do not understand what’s not working in the development And why. And that’s where the focus needs to be first.

Murray: Yeah, you often see safe implementations, where the scrum teams aren’t working at all and people don’t understand really what agile is and they’re not even doing the basic things. And yet at the same time, they’ve got this massive SAFE framework with thousands of pages of things to do sitting on the top of it.

Bas: Yes. I, Usually the first thing I ask for an organization is to work within one or a few of the teams fora while. And then most of the time after a couple of weeks, I’d go back and say the teams are not using scrum yet. You’re not there yet, even. And then it. feels often that they’re going backwards rather than forwards, whereas what’s happening is that they’re, hopefully if they have enough of persistence, just start understanding better what is actually going on within the teams?

Murray: When you came out with, less, there, wasn’t a scrum scaling framework. Now we have scrum nexus and scrum of scrums. Why not just use those?

Bas: I’m not interested in selling or comparing less. I’m interested in building products and getting more experiences. To me, nexus and scrum at scale doesn’t, provide the same amount of learning and structure. So I’m not that interested in it. But I’m not very interested in comparing them and more interested in figuring out how we can better help organizations build products, because that was the first goal anyway. The goal has never been to sell an competing scaling framework. Definitely we did want to make sure that we have enough orphan name and alternative that we don’t end up in safe adoptions because we wouldn’t want to live in such an environment.

Murray: Why don’t we talk through a case study then way you’ve actually done less.

Bas: On the less site there’s the case studies they’re like experience reports. The last one published was the less adoption at the BMW autonomous driving when hundreds and hundreds of people there. And it describes a couple of years of gradually adopting less, what went well? What went wrong? This is a common theme in less adoptions where management wanted to go to FOSS in their adoption, that then cost problems where there’s a conflict with the previous organizational culture things like HR practices. It describes in detail the wonderful conflicts with their engineering culture. And then trying to change the working in silos versus working in shared code. I think that sense a typical example of a lesser option except for this one was somewhat large.

Murray: Okay. We started asking you about the principles before, and then we got sidetracked into a discussion about products.

Bas: So the ones I mentioned where a whole product focus and customer centric, which are two easy to understand principles, but they have a huge impact. Systems thinking is what I like to call the foundational principle of less. Less was created simply by thoroughly looking at what’s going on. What problems do we have doing experiments to understand where you are now. Go see understanding the reality of the teams and experimentation and a loop of those free created what we now call us. Then there’s two principles that if you wish have been elevated from scrum, which are transparency And empirical process control.

Bas: then we have the large scale. Scrum is scrum principle which is how can we get scrum to work with multiple teams. So, then if we have multiple teams, how can we make sure that we don’t lose the essence of scrum? And at the same time, it means we want to try to simplify problems by first, figuring out how we would solve them in a one team scenario before figuring out how to do that in a multi team scenario. So an example of that is where you prioritize the backlog. In one team, you prioritize the backlog, you take the top of the back, looking, you give it to the team, or you let the team figure out how to do that.

Bas: Unless you take the top of the backlog, you prioritize it. Then you give it to the teams and you let the teams figure out how to do that. So we basically look at how things work in one team and then ask the question. Can we just do that also with multiple teams? Or how can we get that to work? Then we have lean thinking and queuing theory. And then we have continuous improvement towards perfection. In less adoptions, we’d like to say you accept reality without giving up on perfection. So you’re constantly first thinking, okay, how would a perfect situation look like? then you just go back to what is the current reality? And then you ask based on the current reality, what is one small thing that we can do to least get a little bit closer to that perfection, but you don’t give up on that perfection and consider it on achievable. It’s just you focus the reality and on the small steps that you can take there.

Bas: There’s a certain way in which you might want to do less adoptions but we always start off with what is the current reality. And if the current reality is we need to focus first on test automation or not all teams want to be involved in multi team refinement yet. Then you accept that and you just take a smaller step without giving up on that perfection vision.

Murray: Okay. So I want to raise a criticism of scrum with you that I think also applies to less, and that is scrum creates batches of work. And so therefore we shouldn’t do scrum at all. We should do Kanban and particularly at the team of teams level, we should do portfolio Kanban. What do you think about that?

Bas: isn’t portfolio Kanban by definition, batches of work because portfolio means that you keep your items very large from your QPR items. Very large. There are batches of work and then portfolio means you’re prioritizing large batches of work

Murray: yeah, but you’re not doing it by sprint or by program increment. So you can start and stop them at any time. A program implement could be considered just a scaled up version of scrum. That could just be a three months sprint, which is how some of the site people think about it. to have a situation where teams are scrambling towards an end of a sprint to get things done does cause batching. Let’s say you have a successful sprint in which everything you plan got done then the next sprint you’re starting again. So there’s not a smooth flow of work through the system because you’re stopping and starting. And you’re trying to get things finished that by its nature causes I batches of what your system.

Bas: of the things you need in a team to function, not as a set of individuals, but as an team as is a certain constraint. And the sprint constraint helps the team to function as a team. If everyone has their individual items, then you can just work on your individual items and you don’t really need to care about that anymore. The lead time increases because of that. Now, scrum chose the sprint as a constraint and Kanban chose the WIP limit as a constraint. And from my perspective, they’re basically the same thing. They create a constraint, that forces a team to not work as individuals, but to work as a team. It’s just a different practice for doing that. And common misconception in scrum and less is that you actually wait till the end of a sprint for releasing things. And clearly that’s a bad idea. You can adopt continuous delivery release 20 times a day when you use scrum or less also. So there’s no batching up from that perspective.

Murray: Yeah. We recommend scrum to teams. But I use Kanban at the same time. Do you do that as well? Shane, like Scrumban.

Shane: I have never worked with a scrum team where we didn’t use a Kanban board to visualize our work. Do we focus on work in progress? We try to see that when one of the developers in the scrum team has six tasks and motion that we have a conversation as a team about whether that’s effective way of working or not.

Shane: Do we use empirical controls to actually monitor and measure that flow? I don’t come from a state’s background, so I’m not a strong coach in that space. So I tend to do visual queuing team behavior than empirical controls. So very light combine. But it would be fair to say, I have not seen a scrum team in New Zealand that didn’t run a combo on board and they probably all just use it, stupid JIRA stuff, without any empirical controls in terms of actually monitoring the flow of work and the time between task start task completion and estimation. So the answer is, scrum very small bond.

Murray: Yeah, I like have a few more columns. I like to get the team to basically map out their process that they’re going through and to set up columns for them. Because I find that combination of scrum and Kanban well

Bas: I’d say that is extremely harmful

Murray: Why is that?

Bas: Because it suggests that work happens in a certain sequence. Whereas a lot of agile development in team is about learning how to parallelize that. To give an example the teams have worked with now. We’d had the ex business analyst was clearly not the product owner, but the member of a team. Often pre-work things for the refinement to prepared them. So that makes the refinements smooth. Now, one of the things we started doing now is to first, not pre-work anymore and always do the refinement with the whole team together so that you don’t have one person telling the other people what it is, but instead the whole team exploring, and then second trying to keep it as short as possible and do most of that in side the sprint. We asked the question. There’s still, a lot of things unknown about this feature. Do we think that the unknown things would change the size of the feature? And if the answer is no, then we say we’ll leave it unknown. And just in the sprint while it’s being implemented and being tested, we’ll also discover those unknown things and all of the things analysis, UI design implementation and test automation just happen in parallel. They don’t happen in sequence. And then if you start to put them in a Kanban board in sequence, then it reinforces that individual sequential way of working.

Shane: So, the concept of bringing in high risk or unknown work, if we stack the iteration with a massive amount of unknown work, It’s harder for the team to actually deliver something that’s shippable. Because they’re bringing in too much risky work. So do you find that the LeSS teams tend to naturally balance it out? They will bring in some work that they think has no uncertainty and then they’ll bring in a small number of unknown ones because they know they’re dangerous, this work that they haven’t understood. Do you find they tend to naturally balance out when they bring the work into the iteration?

Bas: Not really, at least with the teams that I work with. We, want to have shippable things at the end of the sprint but if that’s only one of the items of the five that we picked up that’s okay. So therefore, if we pick an item that has quite some unknowns, and then during the sprint, we go oh wow. It is bigger than we expected. We farm in the refinement that it isn’t, but we discovered it is then we want the team to be relatively comfortable saying it is what it is. The other four are going out and we’ll make sure that we have this one shippable, because this is still the highest priority.

Murray: Shane, I think we’ve come to our time. So we better do our summaries.

Shane: Yeah. this is an interesting one for me. I’ve done a little reading on LeSS but I’ve not been lucky enough to be able to experiment with, Less with a customer. There’s also not a lot of visibility of LeSS in New Zealand. That’s gone down a stupid, safe trick and then at hoc. So a couple of things I’ve picked up.

Shane: So I love the idea of shared experiments, talk about teams experiment and in those experiments have push back into the community of LeSS practitioners. So I really liked that. That’s the kind of the same concept I have in my head of patterns.

Shane: And while browsing the list site, I love the statement. There is no such things as best practice. There are only practices that good women as can call them text, so , that aligns with me around this idea of patterns. In a certain context of value and other contexts, try them and see what the hell happens.

Shane: Sometimes in some context they don’t really fit and solve your problem, so go do something else. So I like that. I liked the idea that you talked about the product owner is not between the team and the customer, it’s not their role to be in the way they’re there to help remove blockers.

Shane: They’re here to remove the need for stupid committees. But they’re not there to be the middleware person. So I really liked the idea of the teams aren’t in the swim lanes. we don’t want the teams isolated or separate. We want to hold a product focus. I see two patterns and the world at the moment, one with a more matress, see Spotify, ye we’re trying to isolate teams. So they are in a swim lane and get the work done with no impediment. And then this one, which is just give the team, the goal, give them the work to be done, prioritize what’s important, get the hell out of the way and let them build their own way of working. And so I think they both have value. You just need to pick which flavor you are and don’t get confused.

Shane: So I thought LeSS was just about scaling, and that’s because I wanted to find patterns for scaling that weren’t safe. And everything I read kind of align with that. But what I heard today is it’s not about scaling. It’s definitely about not scaling using hierarchies. I get that. But it is that holistic view is that systems thinking, it’s look at the whole system, the whole way of working and then do as little as possible to remove the impediment. So when you hear three to five teams, we know there are problems. And for me less comes with the idea of what’s the minimum amount of thing you can do to remove the impediments without over baking it, hence the name. And I really liked that.

Bas: Just as a clarification, the minimum amount of things is definitely not the easiest thing.

Shane: Yes. Sometimes doing less is harder than doing lots. I think less huge is just such a cool term that there’s just such a COVID sentence. But actually the idea that you get to a certain number of people that actually you need to figure out another part of the scaling problem, because we go from 50 to 250 and we have a whole new set of problems. So I like the fact that it focuses on the different things. I like the idea that we solve the problems we have in our way of working with one team before we even think about scaling. The people talk to me about how do we start off with 10 teams on day one?

Shane: And my answer is don’t start of one thing to do something well, and then add another one and then figure out the problems and solve them. . That’s ridiculous that we can do a standing start with 250 people on day one. It’s just stupid. And the other thing that we’ve heard as a thing constantly as the team need to understand the goal, like understanding the goal of what we need to achieve and then get on the worker’s key. We’re not there to allocate tasks. And last one for me, we naturally put constraints in front of teams to force a change in behavior, a change in way of working.

Shane: With scrum, we use an increment. With combine, we use wakened progresses the constraint. We are putting our natural barriers and the why of the team to change the way the team works. That’s the goal. my view is over time, the team start solving their own problems, and sometimes we can remove those constraints. We can remove the idea of an increment. If the teams are just flowing we can remove the concept of estimation. If the team are just bringing in enough work that they can do in the time they promise. So that’s okay. It’s just, we’re changing the experiment. We changing the patterns because the context has changed.

Shane: And so the last thing for me though, is I find some of the other scaling frameworks easier to understand and find information about. And I think that’s one of the downsides is less that it’s not so visible. But then as you said, you’re not there to sell a scaling framework, you’re there to help teams do good work and some of the least things the best way of doing that.

Shane: So yeah, I like it much more than lots of the other ones. Yep. That was me, Mary, where you got.

Murray: so I think that there are times when it’s important that teams focus on particular features of a product. And those are the times when there’s a lot of knowledge gaps and knowledge and learning is a big problem. and you go to a lot of new PayPal or you’re scaling quickly or something like that.

Murray: And I think in that case, It helps a lot, if a team focused on a particular area of a product, because they can get to know that quicker and easier and become more effective than trying to understand every part of a large product, which is why Spotify has their squads and tribes. And I think once teams became mature and got to know their product and more experienced, then at that time, it would be interesting to try this idea of any story can go to any team and the teams work it out amongst themselves. But for me when, knowledge transfer and learning is a big issue for people, I’m not keen on that part of. But , I can see what you mean though , let’s say you have five teams of 10 people working on five features, then you’ve got this baked in assumption that each of your features are equally important and need equal amount of effort. And that is not actually true. So maybe it’s a transitional thing to do it that way until you get better. I’m still skeptical that you can have one product that enough for 50 or 60 people without giving them any help. I think, they do need a lot of help, particularly if they’re a real product manager, who’s spending quite a lot of time on the marketing and user experience side of things.

Murray: So I like the idea of a product owner team way. There’s a number of people helping the product owner. And I just see product owners getting swamped all the time. Now I do understand what scrum says about this and how it’s supposed to be. But it just doesn’t work that way in practice. So there has to be some dialogue between what people do and what the theory says they should do.

Murray: And I guess the last thing is less is not very popular anymore. And it’s because safe has done a great job out of monetizing safe for trainers. Trainers can make a lot of money out of safe. Consulting companies can make a lot of money implementing safe site has the answers to everything.

Murray: I don’t think SciFest agile actually think of bot lights most of the key principles of agile But it’s easier to buy because it’s commercialized and I can see that less feels like a non-commercial community offering. I don’t know if it is or not, but it feels much more that sort of thing, like the agile Alliance or something like that, then one of these bigger machines that has a lot of marketing money behind it.

Murray: I like the simplicity of less. I like all the principles a lot. And I’m going to have a go at it when I can. Do you want to respond to any of that best?

Bas: May, maybe as just one addition to the non-commercial versus community-driven. me it’s more sustainable versus not sustainable thing. don’t believe that safe. Well, believe it’s a good idea it’s also not sustainable to continue that. So it’s more like that is likely to go away. And with less, we are trying to explicitly avoid that. We think it’s a, good way of building products and not necessarily a good way of selling a framework. we’d like to do that for the next 10, 20, 30 years. thus, it needs to be growing sustainably rather than a big.

Shane: Yeah, I’d agree with that. If you’re an organization that wants your teams to work in a better way and build better products, and then you’re starting to scale and you’re hitting some problems that always come when you scale, then have a look at things like less because they have patterns and ideas that might help you with those scaling problems.

Shane: And so for me, less as being more sustainable because it’s about providing patterns that may fix that problem for you rather than focused on implementing agile psych. And I hope that’s what happens in the market, I hope it becomes true. Because then we will have organizations that are helping their teams work in a different way. And the teams will enjoy it more, deliver more and have more fun doing it. Which is what it’s about for me.

Murray: So how can people find you obviously we’ve given the less website, which is less stock works. Do you have a blog? Do you write regularly?

Bas: the moment, not a lot, if I write then usually it’s on the blog on the left side. so it would be the same next to working in a team and working with the less adoption I do training. We like in-person training, that’s why there’s been a lot less training the last two years. luckily that’s changing again and we can see real people again. there, will be doing some training mostly in Europe, sometimes in, Asia I should be planning to be in the U S site. Also again, this.

Murray: Okay, so thanks to you and Craig Larman for developing this great resource for everybody. It’s very interesting to read through and, we really appreciate you coming on.

Shane: Thank you. And we’ll catch you later.

Exit: That was the no nonsense at y’all podcast from Murray Robinson and Shane Gibson. If you’d like help with agile contact marie@evolve.co that’s evolve with zero. Thanks for listening.