Agile at scale: Large Scale Scrum explained

Introduction

Wiktor Żołnowski: Welcome to Pragmatic Talks, a podcast and video series where we discuss startups, contemporary digital product development, modern technologies, and product management. This episode is brought to you by Pragmatic Coders in collaboration with Agile by Example, one of the largest agile conferences in Europe. We believe that everyone should have equal access to knowledge about product development and entrepreneurship, and also, everyone should have the opportunity to apply it in pursuit of making our world a better place. Through this series, we aim to create an impact on the future world. In today’s episode, we are joined by Viktor Grgić, an Agile coach, software developer, and certified LeSS trainer with over 25 years of experience. Viktor Grgić has coached and trained organizations such as the Dutch Chamber of Commerce, Nationale-Nederlanden, and BMW. He’s also known for writing papers and blogs, as well as giving classes on the subject of IT architecture and agile. Today, we will explore the LeSS framework–Large-Scale Scrum–covering its basics, practical implementation, and unique benefits for scale. Then, we will discuss the challenges and successes of LeSS adoption in different cultural contexts, and we will share some advice for leaders. Lastly, we’ll try to predict the future trends in agile and LeSS in the context of AI and other emerging technologies. Ladies and gentlemen, please welcome Viktor Grgić.

Wiktor Żołnowski: Welcome to the next episode of Pragmatic Talks. Today, we are hosting Viktor Grgić, who is a professional LeSS trainer, and in today’s episode, we are going to cover the topic of growing organizations, scaling organizations, in the LeSS framework. Today, as you can see, we are again at the Agile by Example conference. Thanks to that event, we have the pleasure to meet here. It’s a great pleasure. We’ve been about to record the episode about LeSS for some time, and we’ve been talking in the previous episodes that we need to do that. When I saw your name on the agenda, I thought it would be a great pleasure to have you here. But before we talk about LeSS, let’s talk a little bit about you. So, who is Viktor Grgić? What is your story?

Viktor Grgić: So, I come originally from Bosnia, and that’s where I was born. I lived in the Netherlands for 20 years and now live in Hong Kong for 10 years. A long time ago, like 14 years ago, something like that, I tried to figure out how to work with multiple teams doing Scrum and experimented with that. I found out I actually ended up doing LeSS without realizing it. Much later, I found out from Bas Vodde, who told me, “Would you like to be a LeSS trainer?” And so that’s how I rolled in without even knowing what LeSS actually is all about.

Wiktor Żołnowski: Actually, I have a similar experience. When I was introduced to LeSS a few years ago, I thought, “It’s obvious this is the way we used to work in the past with a few teams, and there’s nothing special in that.” And I was like, but there are so many organizations trying something different that doesn’t work. And the approach that we used to do, works. So for me, it was okay, this is maybe why I believe in LeSS and how LeSS works in helping organizations.

Why LeSS emerges naturally for some organizations

Viktor Grgić: That’s actually a story I’ve heard a few times now, and I thought about it, like, why is that happening? It’s actually interesting why some ended up with LeSS and some end up with something else. It proves to be that there’s a certain understanding of what Scrum is all about that leads to LeSS almost naturally. And there’s another understanding of what Scrum is about which doesn’t lead to LeSS, actually.

Wiktor Żołnowski: Tell us a little bit more about it.

Viktor Grgić: To explain it in the most basic way, one group sees Scrum as basically a learning machine. This means that the teams are there in order to learn–learn how to work better and learn what a good product is, “Is this the thing that we want?”–and constantly, by learning, improving the product and themselves. So, the output of a team is essentially knowledge. The other group talks more about flow and how to deliver stuff sooner or faster, how to deliver more. And this concept, so they are focusing, you could say, more on delivery or execution, while the first group focuses much more on solving the customer problem, while assuming that we don’t know much. And that’s also another aspect. One group, including myself, has a tendency to assume that we actually don’t really know how to do our job properly, and neither the customer knows what exactly they want. So you need to kind of figure out how to then work most effectively. Another group makes an assumption that we do actually fairly know this, so now we need to focus on how to execute upon it really efficiently. These two different ways of looking at it, and what’s more emphasized–it’s not necessarily either/or, but what is more emphasized–will lead to actually either LeSS or something else. That’s my theory.

Wiktor Żołnowski: I think that there are a lot of things in your theory that make sense. But I wonder, if the first group, the group that is more focused on the flow, on the effectiveness in terms of delivering the scope, if they would start using LeSS, what does it change for them? Like, would they also be as effective, or maybe LeSS is less effective in delivering, in just delivering the scope?

Viktor Grgić: It depends very much when they say, “We want to be able to deliver on the scope faster,” and so on. It could mean, actually, when you introduce LeSS, that it feels, it looks actually, that it’s less fast. That depends on the measurement and what they value, what is measured. So for example, if you measure developer productivity, then LeSS is likely not a good idea. If you measure the outcome productivity, whatever that might mean, so achieving the outcome, then LeSS does fit and clearly helps. And it doesn’t basically contradict or compromise the speed. So it’s not like if you do LeSS, you need to compromise speed, absolutely not. What is compromised is what kind of speed one seeks. Do you want to get to the value, to maximize the value as soon as possible? Then LeSS is a good idea. Do you want to deliver as much as possible per developer? Then LeSS maybe doesn’t fit.

What is LeSS in under two minutes?

Wiktor Żołnowski: Let’s get back to the basics. If you could explain LeSS in less than two minutes?

Viktor Grgić: Yes. So LeSS is essentially an organizational design framework, or you could say an organizational system for product development. This is the most essential aspect of it. What you don’t hear in there is “it’s an agile framework.” So if you ask an average person what LeSS is, they put it in the same box as SAFe, etc. The difference is so large that it is incomparable to each other because one is, you could argue, it’s an Agile framework, but it’s actually more an organization design framework. Not any organization design–it’s designed for the specific purpose, which is to be able as an organization to focus on the most important, in other words, what has the highest value, and also to reduce the cost of changing our direction. So you want to have an organization which is able to constantly reduce that cost of changing direction. That’s what it is specifically meant for, not anything else. So if an organization wants something else or has goals which do not fit in those goals, they’d better not choose LeSS. So it’s not like a solution for everything.

How it feels to work in a LeSS company

Wiktor Żołnowski: So how is it to work in a company that is organized that way? How does it feel, or how is it different from working in any other company that is not using LeSS, from the perspective of, I would say, a software developer, product owner, scrum master, or even any other person in the organization?

Viktor Grgić: Yes. Actually, it’s good that you mentioned different roles, and they experience it differently. Let me explain first a more general thing which everybody experiences. On one hand, especially in the beginning, it’s a lot of pain and confusion. So that’s lots of conflicts also. Over a bit longer period of time, conflict basically on every level. So this sounds quite negative. I’ll get to explaining why that happens. So most LeSS adoptions come from a setup where the people have never actually been in a real team, meaning that there’s a very high level of collaboration. So suddenly, this context, which is basically really pushing from every side to start to behave as a real team, people are learning it for the first time, and they need to learn how to collaborate, which logically creates a situation where conflicts start to exist. And this is usually good. Usually, I actually encourage people to end up in a conflict, especially in Asia, which is a bit harder, but they need to obviously resolve it. And so also, management needs to really work as a team, because normally in an organization, everything is kind of divided, and people follow processes. As long as you don’t touch my area, I won’t touch yours, and we are best friends, we drink beer or whatever. But now this totally changes, which forces people to really share their ownership and responsibility and so on. But this requires a much higher level of trust, which hasn’t been built yet. To simplify, if you want a high level of collaboration, there has to be a high level of trust. The trust doesn’t come falling out of the sky; it has to be built up over time.

On the other side, what you also see a lot is this bubbling of energy. So when you see them just normally in the office or even online, there is seemingly chaotic stuff happening. People, everybody’s talking to each other, seemingly across different teams. So nobody’s really seemingly stuck in their own team. It’s kind of like a very, very confusing situation. But what matters is at the end of the day, stuff gets done really fast. And the integrated product is done by the end of the sprint because the reason why it’s so chaotic is because everybody’s trying to do everything possible to get stuff done, not wait on each other, not send a document and wait until somebody reacts, etc. So this is really nice to see, this very high level of energy, lots of friendship, lots of off-work activities.

The difference between a team and a group

Wiktor Żołnowski: You said something that sounds like a very brave statement, but I totally agree with that, and I share the observation that you had, that many people have never ever experienced working in a team. If you tell our audience and explain a little bit more, what do you consider a team, and what is just a group of people who are working on something? Like, what’s the difference between a team and a group? As I said, I have the same observation. As a person who used to work in real teams, as you said, a lot of friendship happened. I still have my best friends with whom I was working in one of my first agile teams that I ever participated in as a software developer or QA. I’m still in contact with all of these people, and we were a team. And I’m not seeing it as often as I would like to in modern companies.

Viktor Grgić: The difference for me between a team and a group of people and other forms is… so what typically happens when we call something a team, there is some kind of a shared management, or so we are reporting to the same manager. A group of people which essentially serves the same purpose, meaning that laid out by the manager or which the manager has, but they are essentially working on their own tasks. They have their own roles, and they help each other. So I’m doing my stuff, you’re doing your stuff, we help each other. People call this often a team. In LeSS, we don’t consider this a team. The real team is when I wake up in the morning and I go to work with a purpose to deliver the objective, the goal that the team has, whatever that might be. I don’t care which task I’m doing and that I’m completing my task. What I care about is whether, as a whole team, we are achieving what we ought to achieve. My whole position, my job at work, is to actually ensure that I contribute so that my whole team is successful. Very concretely, how you notice that is how they discuss progress. So if my teammate is stuck with something, I feel responsible that he is stuck or she is stuck. So there’s an equal responsibility for me, despite the fact I might not even know what they are doing. I do feel the same responsibility.

Wiktor Żołnowski: To give a bit of an idea, it’s a really good clarification on what the team is. I also remember, I just recalled stories when I, as a QA, as a tester in the team, I’ve seen, for example, that we are missing some front-end development jobs, like adding some CSS styles to some admin panel that we created for a client. And I said, “Okay, so I see you are too busy to do that. I will learn CSS, and I will do that. Then you will tell me if I’m doing it right or not.” I’ve learned a lot. Actually, that was the first time, maybe not the first time, but the first time I actually learned how to code the front-end, and thanks to that, later on, I became a little bit more into coding. That was also that feeling that I’m part of the team. We have a goal to actually deliver this admin panel, deliver some functionality of the product or some value to our clients, and go to production in the next few days. And I saw that there was no room for that, so I stepped in and did it. And that was a situation that happened very, very often in our team, and everyone did that in the past, from any angle, any role. You were able to move in and step out from your comfort zone.

Product management in LeSS

Wiktor Żołnowski: Okay, so what about product management in LeSS? How does it look?

Viktor Grgić: I need to explain first how we see product management, as a definition of what product management means. So product management can mean different things in the general community, such as there’s a discovery aspect of the product, there is coordination, there’s ensuring that the teams are actually doing stuff they ought to be doing, and combining all this kind of stuff. So in LeSS, it’s not like that. Coordination is not done by product management; it’s done by the teams. So to simplify, a lot of stuff which typically product managers do, especially if you have many of them, is actually done by the teams, such as coordination, such as actually figuring out even which features to build. So that might be very surprising. That might be also decided by a product owner. So, the product management role doesn’t exist, but you can actually kind of say, “Okay, so what do you then have in place?” A product owner. So a product owner can obviously say, “I want these features,” but it’s actually very, very common, and it happens especially in more advanced or developed LeSS adoptions, that the teams are actually suggesting the features. Very, very normal. And even the exploration and discovery part, that’s actually also a collaboration between the product owner and the teams. So for example, a product owner can put in a backlog item, “Please figure out what’s the struggle with this type of customer.” That’s an item in the backlog, and a normal feature team can actually engage in that.

Having said that, there’s also a bit of a reality check. Before we get to that point which I just explained, it takes a while. A product owner typically has people who help with these kinds of activities, and they are sometimes called product managers. And what kind of help are they doing? Some kind of market research, which feature teams typically, I’ve never seen it happening, no. So especially if it’s some deep market research, engaging with some stakeholders, because the stakeholders are maybe not to be engaged directly with the team. They require high maintenance and they need to be dealt with. Product management as a knowledge area is extremely important. So all the typical techniques that product management has, they are very much embraced in the LeSS concept, such as impact mapping, story mapping, product vision boards, and so on. And so this is very much embraced.

Wiktor Żołnowski: So what about UX? Does it mean having a specialist UX person or performing the actions such as you already mentioned, like market research, which I consider somewhere between product management and user experience research, and then of course UI/UX research, interviewing customers, collecting data, surveys, etc., and then designing, of course, at the end. But this is just the end of the process.

Viktor Grgić: It’s basically a similar answer to what you indeed kind of touched upon because it’s in a similar area of product ownership. Meaning that teams are often engaged in these kinds of activities. In a previous structure, there were UX people, and those commonly go into the teams. They drive these kinds of activities, so they are the ones most active with that. But then they have a huge benefit of being in a team, meaning that whenever there is some kind of research that requires experimentation, you can immediately leverage on it because it’s just an item in the backlog which says “research,” but actual research meaning experiments, try something else, and so you can do that. So this is one way that it happens. But if the LeSS adoption is not so advanced, let’s say, then you have more people supporting the product owner who are then dedicated to doing that because the team is not at a scale where its capability has grown yet in order to incorporate these kinds of activities.

The single product owner

Wiktor Żołnowski: Okay, so one more thing about product management. You said it a few times: only one person, one product owner. How can one person, for example, manage a product backlog or manage the product for 10 teams or 12 teams? You already mentioned that there are some supporting roles that an organization could implement into their structure, but how would you answer that question? How to make it work for a huge number of teams?

Viktor Grgić: Generally, those supporting people are not involved in managing the product backlog. That’s pretty much always a smell, meaning that things haven’t changed. So those people who are supporting the product owner, they are more providing this information from talking to stakeholders or some kind of research, and then they bring in this information. But the actual product backlog is managed predominantly by the teams. So the product owner’s job is also partly to manage the backlog, but the product owner doesn’t go into the details of items. He’s really looking at the impact of each item and the context of each item. So the details are provided and managed essentially by the teams. That’s why in LeSS we have up to a full-day refinement in a two-week sprint, because this is not minor work. This probably is pretty much the same as Scrum, actually.

Wiktor Żołnowski: Yes, like the proportion, the suggested proportion, at least in the previous version of the Scrum Guide, that suggested it was like 10% of the sprint, which is one day.

Viktor Grgić: It’s just that in Scrum, it’s not a mandated meeting, while in LeSS, it is dedicated that you have every sprint. What probably sounds maybe a bit shocking to the audience is, how on earth can the teams do that? Especially if you have a whole bunch of teams. Like, if you have so many people responsible for it, then nobody’s responsible. That’s a typical saying. So what we do is divide being responsible, which are all the teams, versus the actual working agreements on how you do that. And so there is a whole range of facilitation techniques to make sure this is done really efficiently and fast. In a matter of one meeting, in different working groups, they’re working on the same backlog to refine it very effectively. So it goes really fast.

Wiktor Żołnowski: One of our product managers and product owners once said that backlog refinement is like meditation. You should meditate at least once per day. Unless you don’t have time. If you don’t have time for meditating once a day, you need to meditate at least twice. And I believe it’s the same with the refinement. Like when people are struggling with refinement and not having time for that, they should do this at least one day. But if they don’t have time, they should do this more time, more and more.

Viktor Grgić: And the common remark to that is that, “Oh, even more meetings and longer meetings!” And who loves meetings? Nobody loves meetings. That’s something that we encounter, especially in the beginning of LeSS adoptions. Previously, people have experience of these long, ineffective meetings and stuff, and then you end up in a LeSS situation. Suddenly, you also need to do refinement, and it’s one bloody hell of a long meeting. So they’re kind of like, what’s going to happen here? And also, in the beginning, refinements are not so efficient because people are still getting used to it. So this is a bit of a hurdle. I’ve noticed now a pattern after seeing so many groups of flipping of teams, that in the first few sprints, there’s always complaining about the refinement until they figure out how to do it properly. And then everybody, nobody is even questioning it. They already see it as a really, really important part of the process that has to be done.

Convincing a leader to adopt LeSS

Wiktor Żołnowski: If we would have someone here who is growing his or her company, like a startup owner, a founder who has just raised another round of financing and is going to grow from, let’s say, 30 people to 80 or 90 people in the IT, in the product department, how would you convince such a person, or what benefits of using LeSS would you provide to convince such a person in two minutes or something, that elevator pitch?

Viktor Grgić: My first question always would be, why would you want to scale?

Wiktor Żołnowski: I would provide you an answer that is not so obvious, but I heard it recently for real. “Because my investor told me so, otherwise they won’t give me money.”

Viktor Grgić: Yes, that happens. Yes. So, at least I want to have the answer. Unfortunately, the answer is usually not a very good one. And so you can fight it, or you can just simply say, “Okay, then we need to deal with that.” And in a way, that’s also one of the reasons why LeSS exists. It’s not because it’s so great to scale, but because everybody’s scaling, and now how to manage that properly. And so scaling is clearly a need, and LeSS kind of fits in how do we scale more sensibly, essentially, despite the fact that we shouldn’t be scaled most of the time. Not long ago, a company which scaled really fast, Jago in Indonesia–I want to do a talk tomorrow on it–they scaled really, really fast. But first, they scaled or tried to scale without LeSS, and basically a kind of a Spotify thing, with independent teams and stuff, and everybody has their own product owner, etc. So that really didn’t work out. When we came with LeSS, it became like a very obvious choice and so scaling became very clear with a clear message: if you want to scale up, the last thing you want to do is complicate the hell out of everything. So you don’t want to complicate your company. Nobody wants that, actually.

The transformation to LeSS

Wiktor Żołnowski: Let’s talk about introducing, about the transformation that you already mentioned. I have this observation, and I’ve seen it a few times, that introducing LeSS to the organization is difficult, is time-consuming, is cost-consuming, etc., and they struggle with it. But I’ve also seen and talked to people who are saying that no, it’s pretty easy. It’s just, we’re just adding on top of what we have. As you said, one-day refinement, one product owner, one single backlog, and actually, we are doing LeSS. We don’t need to do anything else. And it was like a one-day transformation, and we are LeSS. The difference between those two groups is that the second one is already using Scrum and is doing this properly and just simply added another team, and another team, and then put LeSS on top of that, and it worked seamlessly. And the first group is that they are not doing Scrum at all, or they are doing Scrum, but Scrum is something they are not having a proper Scrum process for. And they are trying to scale it up. So do you think that Scrum is something that is mandatory for LeSS adoption, or maybe you have some examples of companies that were totally not using Scrum and then adopted LeSS?

Viktor Grgić: Unfortunately, I wasn’t lucky enough to encounter a company which does Scrum properly, that I just simply put the stuff on top and it’s kind of easy. In my case, pretty much all of them were not easy at all.

Wiktor Żołnowski: Maybe because you’re a consultant and trainer, and those companies who did this seamlessly, they simply didn’t need your help.

Viktor Grgić: Exactly. I don’t emphasize Scrum much in the beginning with organizations, meaning that pretty much all of them that I encounter don’t understand Scrum properly. So many of them claim to do Scrum. In reality, it proves to be not Scrum at all, “Scrum-ish” we call it. Do I then first start teaching them Scrum and stuff? No, really. And why? Because there is an interdependence between doing Scrum properly and how the organization is structured. So the problem is, as long as you don’t change the organization, it’s, in many organizations, impossible to do Scrum properly. And that’s why LeSS exists. That’s why it’s an organization design framework. The whole purpose of Scrum is to expose the pain so that you deal with it. The problem is that exposing the pain, for whatever reason, doesn’t work. It’s not good enough. And so it needs more. So that’s why we have organizational tools, Lean thinking, systems thinking, to essentially break the barriers to enable this real agility to happen.

Now, can we have an organization without actually doing Scrum in general? Then is LeSS meant to always implement Scrum, but then on scale? No, actually, there are LeSS adoptions which don’t actually use almost anything from Scrum. And in my LeSS adoptions that I do, I really de-emphasize the Scrum rules and the Scrum Guide. So we don’t emphasize that at all. We just simply start working with the teams, and very often deviate from the Scrum rules. So there are some teams that, some people suggest also continuous flow, for example. And I very much encourage it. The only “but” there is, when they say continuous flow, I really want to know what the heck they mean because very often, it’s avoiding the pain and change, and that’s not really an option, because the purpose is to get better.

Wiktor Żołnowski: Don’t you think it’s all about product management that we discussed before? Like, the organizations who are really product-centric and designed that way, or trying to be designed that way, have a much easier time adapting to LeSS because if they already have strong product management, product managers, decision-makers, and this culture of being product-centric, of focusing on the users and delighting them with the product, it’s actually a common root for LeSS and the product-centric organization. And the same for the Scrum organization. Like a good Scrum organization, Scrum teams need to have this product management in place, otherwise, they will be stopped from doing Scrum as it’s supposed to be. In the worst-case scenario, they will deliver the scope, in the group that you described at the very beginning that is using Scrum for delivering scope. But if they are product-centric, they will deliver value instead of the scope.

Dealing with dependencies in LeSS

Wiktor Żołnowski: The best thing I love in LeSS is how LeSS deals with dependencies. And this is the question I often get from various people who are working for big organizations, trying to do some Scrum, some agile, and they are asking all the time, “Okay, how to deal with dependencies?” And they are wasting a lot of time on that. They are hiring special dependency managers, release train managers, whatever, who are doing nothing else but trying to solve the dependencies, predict all the dependencies, mark them, visualize them, and then figure out how to do this. How do you do that in LeSS?

Viktor Grgić: Okay, the dependencies are embraced, in fact. So we don’t mind dependencies, we love dependencies. So that’s the first thing. And so, dependencies are not the problem, because if you do not have a dependency, that means that you do not integrate. Why do we have dependencies? Because different parts need to integrate. What’s the problem is not dependencies, but the cost of them. So in LeSS, we do everything possible to reduce the cost of those dependencies. Now, if you have a separate person, so it means that you have a level of indirection. So there is somebody separate who needs to manage dependencies, which means that somebody doesn’t understand how this dependency really comes about. It’s managing more, so it has a typical management problem. If you’re outside of the development and you don’t understand the details, you have a big picture but don’t see the details. And if you’re inside and look locally, then you see the details but don’t see the big picture. And so this is what creates waste. This is what makes it so painful to have dependencies. And so instead, we change the structure in such a way that we reduce the cost of dependencies massively. Hence, the people who have to depend on each other, they are simply put together. And so in order to deliver value for a customer, you need to go through different components, you need to have certain skills, and so you put those people together and you build the knowledge required in order to do that. So the dependencies are shifted, essentially. And so most of the dependencies happen then within a team. Now, did we solve cross-team dependencies? No, we did reduce a lot. And so the remaining part, for the dependencies across different teams, that happens directly by the teams. So that’s a second form of waste. If you, again, have a level of indirection, if you have somebody separate, that’s very costly. But if you have the teams directly coordinate with each other, this reduces the cost of coordination for the dependencies between teams.

Wiktor Żołnowski: And you need to manage the dependencies on the backlog, so they will be put together so people will actually not be blocking each other and will more likely work in parallel on something that is interdependent.

Viktor Grgić: Yes, correct. That’s actually interesting. On the backlog, you generally don’t see actually dependency pictures there, or you have user stories, whatever, that have some dependencies inside. But since those are like big chunks that are put there together and are not split completely, so this team will take that and the other team will take another part, but not today, but in the next couple of sprints, then you actually don’t need to manage those dependencies because they will figure out how to solve it in this sprint.

Wiktor Żołnowski: That’s correct.

Viktor Grgić: That’s actually a really good and also quite shocking thing to people, because it’s very, very common, even in LeSS adoptions, people miss this point often. If you have three items which depend on each other, they have a tendency to plan one item by one team in one sprint, the second one in the second, and the third one in the third. We really discourage this because this is actually creating a delay, which is another waste, and lots of complications, back and forth, etc. So instead, we encourage putting all three in the same sprint. And it’s very counterintuitive, but this actually reduces the dependency cost enormously by actually depending on each other even more. That’s why we love dependencies. Now you’re not depending across three sprints, but you’re depending every single day, every hour. You need to communicate, you need to figure out how to do this.

Wiktor Żołnowski: But people on the other side have time for you because they have the common goal, the same goal that you have. So it’s much easier for people to communicate. And of course, for some people, it may sound counterintuitive because when you look at it, it occurs that, okay, but there are a few other items that are not dependent on this one that sound more important, and that team that is working on this part could do that at the same time instead of doing this dependent part. But at the end of the day, when you count all of these dependencies, the dependency management time needed, all of this blocking each other, etc., it occurs that everyone is way more effective. It’s a little bit counterintuitive, but actually, the data shows that that works better, and the logic shows it.

Viktor Grgić: There’s also another reason. In the beginning, when I mentioned what LeSS is meant for, the purpose of LeSS is to focus on the most important. Now, if an organization chooses for that–many do, some don’t–that means they are serious about it. What does it mean to focus on the most important? If we say, “Because of the dependencies, you are going to pick up something else in the meantime,” you can logically deduct that you will be less focused on the most important, automatically. Everybody optimizes to utilize their time, which means that everybody starts to wait on each other while being very busy. So the consequence of that is that the most important thing is going to be delayed because now we are working not on a single thing that’s most important, we are working on many things.

Wiktor Żołnowski: And there is the concept of slack time, that even if you cannot participate in working on something that is most important right now, you shouldn’t be just simply running in a circle and trying to do anything else. But you should even be available for others in case they will need you, or work on something that you can improve, like quality, you can learn something new, you can experiment with some new technology, etc. That is quite good. I think it’s pretty much the same in Scrum, not only in LeSS, but the whole concept of slack time is pretty universal. Whatever framework you use, if you have it in place, it works in Kanban as well.

Working with different organizational levels

Wiktor Żołnowski: You are working with different levels of organizations. You’re working with management, with product management, with teams. So, do you have different approaches to all of these levels? Like, do you talk differently or use different techniques to work with the top-level management of the company, or are they pretty much the same tools as you use with a development team?

Viktor Grgić: They are variations of the same thing. Meaning that all three groups go essentially through the same training, a three-day training at least. Management goes through a longer training, but it’s usually not called training; we call it a workshop for political reasons. People don’t like to be trained, they want to work, I don’t know. Meaning that with management, there are regular sessions every two weeks or every month, and we take a subject and go very deep on the subject, etc. But how information is presented really depends on the audience, and even per company and the type of people actually sitting there. For teams which are heavily technical, you typically need to emphasize more how to collaborate better. But for teams who are not so technical, you need to emphasize much more technical excellence practices. The same with management. A lot of management, especially at the highest level, which is actually then outside of the technical management, so not management of IT but actually management of, let’s say, a bank, they just don’t know so much about product development. So then you really need to educate even about product development. Like, it’s not like building a building outside. It’s actually very different. It’s software, so it’s soft, you can change it anytime. So they assume you cannot change it, therefore you need to do upfront stuff and so on and so on. So it’s really basic stuff sometimes.

The role of the Scrum Master in LeSS

Wiktor Żołnowski: Since we are talking about learning, teaching people, etc., let’s talk a bit about the role of the Scrum Master in LeSS. How does it look? Is it different from a regular Scrum Master in a regular Scrum team? What’s the difference?

Viktor Grgić: The Scrum Master in Scrum and a Scrum Master in LeSS are in essence not different. But due to the context within which they’re working, the manifestation can be very different. Because in LeSS, you’re looking very much also at how collaboration between teams is happening. While in Scrum, the assumption is that you’re mainly focusing on how that team is working and producing value. So there’s an organizational context by definition for a Scrum Master in LeSS. It’s just that in Scrum, there are so many interpretations of not Scrum itself, but people make all kinds of interpretations of what a Scrum Master ought to be doing. In LeSS, we make it much more specific and much more clear in order to avoid these kinds of issues. The most visible difference in a practical sense is that a Scrum Master in LeSS is very much encouraged to be deeply knowledgeable about technical excellence, technical practices. It’s basically somebody who’s technically really good and teaching.

Wiktor Żołnowski: So that’s the question aside from LeSS, but for example, at Pragmatic Coders, where we work, we do have Scrum Masters, but those are not full-time jobs. This is just a role of a developer who wanted to take this accountability and play the role of a Scrum Master in a team. We teach those people, we train them. I would say that most of them would easily pass the PSM I Scrum certificate exam without any preparation. So they have this knowledge. What do you think if such a person, taking this role as a part-time role on top of their regular development duties, how would such a person work in the LeSS framework? Would it work, or maybe it’s too much for something?

Viktor Grgić: It’s too much. Simply, it has to do with the amount of required work. It’s the difference between taking continuous improvement really seriously as an organization versus somebody who does it aside. And pretty much always, what I observe when a Scrum Master is part-time, it usually ends up being some kind of somebody who basically manages the backlog and meetings.

Wiktor Żołnowski: That’s the team’s responsibility, not the Scrum Master’s.

Viktor Grgić: Yes, but in reality, I see these activities happening by the Scrum Master. They’re planning the meetings. And it’s superficial. It’s done superficially when it comes to improvement and making sure they’re facilitating the meetings also. That also happens with the part-time Scrum Master. It’s always the one that facilitates the meetings. In LeSS, we encourage basically anybody in the team to facilitate. So typically, these activities that are picked up by these part-time Scrum Masters, they should be actually picked up by the team. But then what is the Scrum Master actually going to do? They need to do really deep thinking and observation and looking at organizational issues, what’s actually blocking the team, and teaching them, introducing all these kinds of new ways of working, pairing up also to teach them all these practices in order to really improve.

The future of LeSS and AI

Wiktor Żołnowski: Let’s focus a little bit on the future and how you think things will change in the nearest future in terms of scalability, LeSS, and especially in the context of AI. Since I think that AI will simplify the developer’s job pretty soon and will reduce the complexity or will address the complexity of the complex systems that people create and will simplify it one way or another, or even make it more complex but make it manageable because people won’t be changing the code, but the AI will do it, and people maybe will only tell it how to change it. Sooner or later that will happen, I’m pretty sure. So how do you imagine the nearest, or maybe not the nearest, but the future of AI combined with scaling an organization? Or maybe there won’t be a scaling organization issue because the number of people won’t mean anything?

Viktor Grgić: So LeSS is actually, it feels almost by design, designed for the AI future. I’ll come to the AI aspect and just explain what it means to be a developer in a LeSS context. It means that as a developer, your job is not anymore coding. Your job is actually solving the customer’s problem, and anything that is required in order to solve the customer’s problem, you do that. And as we know, a small part of that is coding, essentially. So this is a dramatic difference, and typically LeSS is a struggle for developers. Now we go to AI. What is AI about? Is AI actually going to replace a developer? No, of course not, as long as we see developers as I just mentioned, somebody who solves the customer’s problem. “Yes, I’m going to solve the customer’s problem,” because the most important things there are asking the right questions, etc., and understanding, empathy, and so on. So the context, AI is not good at that at all. AI is going to actually speed up this development from somebody who’s actually doing repetitive, routine work and exercising routine knowledge. So routine knowledge is going to disappear, meaning, “I know how to code this function in a language blah blah blah.” So that will largely disappear, which means that what remains is that you’re really focusing on the customer problem thing. So it actually is going to speed up that development where we’re going, meaning that the developer’s job is not going to be replaced at all. It just means that the job is going to change dramatically.

Wiktor Żołnowski: How about product management? I’m pretty sure that this is something that will still be required. Like, all of this aspect of interviewing users, etc., asking the right questions.

Viktor Grgić: Yes. The previous point that I made is actually largely from Craig Larman, also. He did a talk on it, a very detailed one, at the LeSS conference. So he explained this in enormous detail. I would advise checking it out. But almost pretty much all roles are going to be affected in the same way. So let’s say, like a UX designer. Okay, so what does UX typically do, and spend most of their time on? They create, or a product manager in that sense also up to a certain level, they create these designs in Figma and so on. They have an idea, and then they spend time creating these designs. Now, the most time is spent actually on creating those designs. And now, there’s already AI which can do that in a matter of 10 seconds. You just put in the idea. If you don’t like it, you change it and it produces high definition…

Wiktor Żołnowski: I’ve seen that you can put a mockup on a napkin, provide the picture, and you already have a design in the way that you want it. Or you can describe it, you can do a block schema of the functionalities that you want, and you not only have a design but also the code that is behind it and all the functions. So you don’t need to know how to code and how to design to actually do this job. But there is this job of collecting the feedback, talking to the users, finding their problems that we can address and solve. And I believe that this is something that, at least right now, I haven’t seen an AI for that.

Viktor Grgić: That’s true, because the change of a developer’s job is dramatically happening. The developer is automatically going to be closer and closer to the customer. And this means exactly those activities you just mentioned: collecting the feedback, understanding the customer, observing how they actually use the work, and so on.

Cultural differences and scaling LeSS

Wiktor Żołnowski: Let’s talk a little bit about the cultural differences, especially in terms of scaling with LeSS. You already mentioned before that in Asia, it’s much harder to put people in conflict in the team to actually build a team. So what are other differences that you see between, let’s say, Europe, the Netherlands, and Asia, Hong Kong, where you are right now?

Viktor Grgić: Very few things I could say are an “Asian thing.” So Asia is basically full of very diverse countries with all different cultures and stuff. And the more time I spend there, the bigger differences I notice. But there’s one more kind of general thing in most Asian countries, which is that embracing change is more welcomed than in this part of the world. Generalizing a bit, but it’s actually based on experience. In the Netherlands, to take a country, but I think other European countries are similar, Germany the same, and so on, when you go into a company and say, “Hey, shall we do this? Let’s try this,” the immediate question back is, “Why should we? What’s wrong with our current way of working?” This is something that in Asia rarely ever happens. So the resistance to trying things out is very, very low. And that’s something which kind of very much complements the agile way of experimentation and working. So typical LeSS adoptions go faster in Asia than in Europe.

Wiktor Żołnowski: That’s interesting. Is there anything that is more difficult in Asia, aside from what you already said, that team building through conflict? But maybe there are some other aspects that you see that are different and more difficult?

Viktor Grgić: The team-building thing is actually not necessarily because people don’t want to or anything culturally. It’s actually because of more systemic things, that people are never used to, never learned to actually work in a team. And why is that? It’s the hierarchical nature of working in the country. So this, in combination with a certain type of respect for authority… somebody higher in authority is considered smarter. I literally also heard people saying, “Why should we ask or let the team decide? Because we have these managers who are by definition smarter, otherwise they wouldn’t be managers.” Which to somebody from Europe sounds like quite an astonishing statement. It’s also not a very common statement to hear publicly, but I do know it’s actually in the minds of the people. There is this kind of hierarchy. And this obviously contradicts self-management up to a certain level. Does it mean you can then kind of give up? No, because at the end of the day, pretty much everybody also in Asia sees the benefit of self-management. They are not against it, they just haven’t seen it happening often. So when you show that it’s possible, there’s a direct embracement of that. So I usually don’t try to convince them to do self-management, we just do it. Because remember, they are embracing the change, I don’t need to explain much. We just simply do it and then show what it looks like. And then they go, “Oh, it’s actually working. Okay.”

A LeSS success story: Jago

Wiktor Żołnowski: Okay, so let’s talk about your case studies, success stories. Could you name one greatest success of the transformation that you led or helped with and give us some more details about it?

Viktor Grgić: One of them, okay. So the more recent one is this Jago. Spoiler for the talk.

Wiktor Żołnowski: Maybe not. Okay, no worries, no worries. People will see this recording a few weeks after the conference, so they can already most probably find the Agile by Example YouTube channel and all of the talks from this year’s conference, including Viktor Grgić’s talk that he will speak about here before we record. So you can compare if that was the same talk or not.

Viktor Grgić: Yes. So, Jago. The reason why I like it is because it has this combination of difficulties that we typically encounter. I also can talk about another one, but this was smaller in scale and there was kind of like a perfect storm and it was easier to get on with it a long time ago. That was my most enjoyable thing because it ended up so good. Jago is a bank in a fairly traditional culture. So my friends in Indonesia are going to forgive me for what I mention, but they agree. So it’s a very hierarchical way of working where people are expected to execute tasks as they’re being assigned, preferably through Jira. And then you talk about scaling, I talk about lots of people, and changing that into real self-managing teams where people were normally very shy and didn’t talk much. And so on, really opening up. And also multicultural, so there are people from Indonesia with different religious backgrounds, and then Singapore, and then Eastern Europe also, actually quite a few, and they’re working together. And we ended up in really saving the company. Because before the change, there was such a huge stress that they were not going to make it because they just couldn’t get stuff done properly. And in this market, if you are not fast enough with properly delivered stuff, you’re dead. And so it’s a scaling thing, a virtual bank competing with others. And they really turned around completely. And with now, I don’t know the number of teams, I forgot, 30-something, for sure.

Wiktor Żołnowski: Awesome, sounds great.

Top advice for leaders adopting LeSS

Wiktor Żołnowski: Okay, so last but not least, if you could share three top pieces of advice that you would give to any organization leader who wants to start introducing LeSS to their company, where should they start from?

Viktor Grgić: The number one thing, surprisingly, has nothing to do with LeSS, but simply being aware of and asking yourself the question, “What exactly am I optimizing for?” And that proves to be always a surprising question to management. They don’t have a very clear answer. The conversation is usually like, “I want an agile coach, I want this agile thing,” but that doesn’t really mean anything. So, what do you optimize for? That’s the first step.

After that, once you realize LeSS actually might be a way to help you solve your problem or optimize what you need to optimize for, then do training for management so that management is fully educated before you understand what you’re getting yourself into, because LeSS adoptions are painful.

After that, the typical step is choosing one group with which to start. And it doesn’t mean that you’ve decided to start and do feature teams. It means that that group gets educated, and then again needs to decide, the group itself, including the team members, developers, everybody, needs to decide, “Is this something for us? Do we understand actually what it is? Do we understand how it’s going to make a difference? And are we willing to go through the pain for a change?” Because it’s not minor. And once they’ve decided, then we do what we call a “flip,” which is typically a five-day activity of doing several things in order to be completely ready with a new structure, where you then start the first sprint. Now after that, you’re not finished. After that, another pain begins because now you need to get used to this way of working and then continuously improve, sprint after sprint.

Wiktor Żołnowski: So I explained more than three things.

Viktor Grgić: And that was, I was about to ask another bonus question about how the transformation looks. You already told a lot about the beginning. So you’re saying that then it’s just continuous improvement, sprint after sprint, you are introducing new concepts or the next concepts of LeSS and improving.

Wiktor Żołnowski: Yes. So essentially, it’s improving the Definition of Done, which actually at some point requires organizational improvement. To give an example, one team cannot do full end-to-end integration testing. Why? Because one of the tools is basically developed by a different part of the company, or one of the components is from a different part of the company or by a vendor. And then you need to do an organizational change again in order to incorporate that also, which is part of being able to expand the Definition of Done.

Viktor Grgić: So case by case, you are changing the organization structure to fit it into the proper dependency management that we spoke about before.

Wiktor Żołnowski: Yes, to reduce the cost of those dependencies. So it means that what I explained, the big bang organization change upfront, is later step-by-step adjusting the organization structure to the process that we want to follow.

Viktor Grgić: That’s correct. So essentially, no matter the size of the organization, the group that you’re starting with is fairly small, up to 50 people, not more than that. And then also the change, even for that group, you’re not saying, “Now, regardless of the complexity of the architecture, you need to work end-to-end through all the components.” No, that might be just way too much. So you say, you become for the first step more cross-component. So you don’t want to overstretch the organization. No big bang at all. So that might surprise many people. I hear this misunderstanding, they’re thinking LeSS is this kind of big bang, idealistic thing where you change the whole organization, then you can start working. No, it doesn’t work like that. So you do a small group, and not some kind of changing completely into end-to-end teams, because it might be too difficult. Cross-component, and then gradually, sprint by sprint, expanding that further.

Wiktor Żołnowski: I wouldn’t ask the question “how long does it take to transform an organization?” because most probably, it’s a continuous process that never ends. But after what time do you think that the organization leaders or the organization at all sees the first results of adopting this way of working?

Viktor Grgić: So it’s contextual, but usually what you see is between one and two years, you start to see a real, real difference. But this assumes it’s LeSS Huge by definition, which in my case, it almost always is. The reason why it’s LeSS Huge is because it’s a larger organization. And so this is usually also a bit more complex, it takes a bit more time. I had changes which took only several months, and they saw a difference immediately, but that was just LeSS with a few teams, the whole company.

Wiktor Żołnowski: I know that for people who work for a smaller company, never worked in a corporate, like, “Oh my God, two years of seeing the results is a long time.” No, for corporates, it’s actually extremely fast. Since starting some project and seeing the results after two years or one year is actually pretty fast. And as you mentioned, for a small organization, it’s usually much faster.

Viktor Grgić: Again, it’s contextual. So if I would take one of the biggest banks I also worked in, two years is too short. It’s because of the bureaucracy and stuff, etc.

Conclusion

Wiktor Żołnowski: Viktor Grgić, thank you very much. It was a great pleasure to talk about LeSS. I was about to talk about it with someone who was an expert for a very, very long time. I’m very grateful that you agreed to join us today and that we managed to have this conversation. So once again, thank you very much. And thank you, everyone, for watching this. Please remember to subscribe to our YouTube channel and, of course, follow Viktor Grgić also on LinkedIn. I believe it’s the best way. So it’s the best way to also contact you in case someone will have some questions or would like to work together, maybe with you. And of course, I invite you to watch the video recording from Agile by Example that will be made tomorrow during your talk and will be released in a couple of months. I don’t know exactly when, but you should follow the Agile by Example conference social media as well to learn that. So thank you very much.

Viktor Grgić: Thank you. Thank you for having me here.

Wiktor Żołnowski: Pragmatic Talks is delivered to you by Pragmatic Coders, the first-choice software development partner for startup founders. Be sure to catch all new episodes. Subscribe to our YouTube, Spotify, or Apple Podcast channels. And if you are thinking about building your own startup or struggling with product development, contact us and find out what we can do together.