At the recent Agile Singapore conference Bas Vodde spoke about Large Scale Scrum (LeSS) – the scaling model he and Craig Larman have introduced. He explains some of the important elements of LeSS and the recently launched website which describes the framework.
InfoQ: Bas, good day to you. Welcome. Thank you for coming along and talking to us. Would you mind briefly introducing yourself for the readers?
Bas: Sure. I am originally from Holland and worked there for a couple of years. Then, I moved to Beijing, China where I joined a 'small' company called Nokia. This was not the Nokia Phones, which is now Microsoft, but the telecom network group that is now called Nokia. Before I moved to China I had experimented with Extreme Programming (no Agile Manifesto yet at this time) and I continue experimenting with that in Nokia. After a year, I moved to Hangzhou, China where I started working in a large waterfall-based telecom product development group.
At that time, everyone knew Agile was for small projects and thus, for the next couple of years I was back to doing very traditional waterfall-based development. I discovered that that doesn't work well for large product development. So, I went back to what I knew worked which was Agile/XP type of development. And we started experimenting with that in the larger product group. In the meantime, Nokia Networks had become interested in trying out more Agile development. They started looking for people in the organization who had experience with Agile development and I turned out to be one of the few who had. They asked if I would be interested in leading a change project in Nokia Networks.
I moved to Finland and started working with my good friend and co-author Craig Larman. We worked as a pair where I was the internal change agent and he was the external change agent. It worked really well.
The first thing we did in our change program was to give a lot of general presentations about Agile development, which summarized all the different methods. We then asked them whether they would like to try some and which sounded the most interesting. People said Scrum seemed really simple. Let's do that...
As we started working with Scrum, we decided to invite Ken Schwaber to help us kick-off Scrum in the organization. Scrum was adopted throughout the whole organization from products as small as two teams to products with hundreds of teams.
After living in Finland for two years, I decided to move back to China and I joined the management team of a product of about 600 people. They had already piloted Scrum and had decided to go all the way. We adopted Scrum across the whole organization and started applying concepts that have now become part of LeSS. After a year of doing that, I decided to move to Singapore and founded Odd-e.
Odd-e is an Agile coaching and training company with teams located in Tokyo, Seoul, Shanghai, Bangkok, Manila, Singapore, and Hong Kong. I kept on working with Nokia and some other companies around Singapore. Craig travelled around the world and continued scaling Scrum in different large projects and companies. Around that time we also started writing the first two books, for which we co-located ourselves in Singapore. In subsequent years the people in Odd-e started experimenting with different types of organizational design but that is a different story for a different interview.
InfoQ: That would be a good story on its own.
Bas: Yes, it would. But to continue, I did continue working with Nokia as an external Agile Coach and also worked with a few other companies adopting LeSS. And now, again a couple years later, we're writing our third book.
InfoQ: And the third book is specifically focused on LeSS?
Bas: Yes, it will be titled “Large-Scale Scrum (LeSS).” And we just launched the LeSS website also.
InfoQ: What is the fundamental problem that LeSS is trying to tackle?
Bas: The fundamental problem is - how to apply the concepts of Scrum when there is more than one team.
InfoQ: How does this differ from the Scrum of Scrums?
Bas: Scrum of Scrums is most commonly described as a simplistic coordination method between teams. LeSS provides a framework like Scrum which assumes multiple teams working on the same product. The core of LeSS is the LeSS framework with is a set of simple rules (2 pages) that expand on the Scrum rules. Above that, there are lots of guides that explain the organizational impact of that, such as how typical organizational structure ends up or what changes in management styles are expected. The LeSS Framework provides the absolute minimum that we would expect a product group to do when they have more than one team.
InfoQ: Now, when you were describing this yesterday, you made an interesting point. You spoke about not building a large framework and making it small but taking a very, very small framework and only adding on what is the minimum needed. So what are some of these minimum add-ons that you have identified as catalysts?
Bas: Yes. One of the things we've done is to change the Thinking Tools (from our earlier work) into the Ten LeSS Principles. These Ten LeSS Principles guide all of the rules, guides and experiments. One of the LeSS Principles is “LeSS is Scrum.” LeSS is not taking Scrum on team level and then adding stuff around to deal with multiple teams, but instead it is taking Scrum and asking how can we apply the same concepts across multiple teams. LeSS is not a special scaled framework that happens to include “Scrum for each team” but instead LeSS is Scrum scaled. This is a fundamental difference between LeSS and some of the other scaling approaches. Scrum itself is a one-team framework and the team has to figure out how they work within it. How many people actually know how thin Scrum itself is? Many people assume that some practices are part of it, but they are not.
InfoQ: Indeed, the Scrum Guide is only 16 pages long.
Bas: Yeah, but that is already a long description. I'm also a Scrum Trainer and together with some other of the older trainers used to refer a lot to the Appenfix A of the “Agile Project Management with Scrum” book. Appendix A is called “Rules” and it is three pages. The LeSS rules are like that, they expand on the Scrum rules. For basic LeSS they add 2 pages and one additional one for LeSS Huge (which is for groups with more than about eight teams).
LeSS actually consists of two frameworks. One we just call LeSS and the other we call LeSS Huge. Basic LeSS is up to about eight teams and would probably work for about 80% of the product groups. Over the last years, I've mostly been involved in LeSS Huge adoptions, which are for more than eight teams. Sometimes going up to hundreds of teams.
The LeSS framework only adds one additional thing to Scrum: one meeting called the overall retrospective. This is a retrospective meeting with multiple teams where they can discover systemic organizational things. The rest of the rules are clarifications on how do you do Sprint Planning, Refinement and things like that. And, of course, how do you coordinate between teams?
The LeSS rules do tell you something about how you should structure your product development. These are probably the most difficult ones to adopt for organizations as they do require change within the organization.
InfoQ: One of the things that intrigued me when you were talking about LeSS, not LeSS Huge, was the single product owner for all of the teams, a single backlog for all of the teams. This seems quite almost contradictory certainly looking at many of the other "scaling approaches."
Bas: Yes. All people are building one product together. One of the LeSS principles is “Whole Product Focus”. In my experience with large scale development, one of the key problems is not how can you get Scrum to work in one team but it is how to get everybody to understand that if each team develops “their part,” if it isn't working together then you don't have a product. It's not going to be useful.
Every team needs to put the whole product before their own part. There are several things within the LeSS framework that create that Whole Product Focus. One Product Owner working with One Product Backlog is one. This one Product Owner doesn't clarify all items but instead focuses on prioritization. The teams do not have their own Product Backlog but instead they work on the One Product Backlog. This ensures the prioritization of the work across multiple teams to ensure that all the teams work on things that are the most valuable for the product. Teams are not pre-assigned to items, but instead this is decided as late as possible to keep the flexibility. This also means the teams need to have a broader understanding of the product. That helps them build the whole product instead of building separate parts of a product.
The final decision of what teams work on what is made in the one Sprint Planning meeting. The representatives of the teams will there pick up the items their team want to work on. Before that, they will probably have a shared Product Backlog Refinement session so that the items are clear before they are picked up in the Sprint Planning One meeting. Likewise, there is one Sprint Review at the end of the Sprint where the participants inspect the whole product and adapt the whole product.
InfoQ: One shared Sprint review. And this prevents Conway's law?
Bas: No, this is unrelated to Conway's law. That's a completely different subject. One of the rules added to LeSS is that the majority of the teams are feature teams. Conways's law refers to organizing around architecture and with feature teams organize your organization around customer-centric features. It is really just the logical effect of insisting on having a working product at the end of every Sprint. If you work in component-based team then it will be hard to figure out which team will be doing the full-feature integration and QA. With feature-based teams this problem is not a problem.
The effect though is that adopting LeSS usually means adopting a completely new organizational structure. The LeSS rules contain rules for adoption; we've seen so many LeSS adoptions go wrong because they weren't able to put some basic elements in place. So, the LeSS rules for basic LeSS (not for LeSS Huge) state that you must make the switch to feature teams all at once. It isn't a gradual adoption.
InfoQ: So it is the complete switch?
Bas: Yeah. Without the structure in place, the chances of success are so dramatically less that we felt it's worthwhile to state that you need to put that structure in place. That makes it hard because you will not be able to adopt LeSS without changing, anything unlike some other approaches.
InfoQ: You have a new book coming.
Bas: Yes. As mentioned, it is called Large Scale Scrum.
InfoQ: You're also offering training and certification?
Bas: Yes. Our focus will be on LeSS. We started an organization for promoting LeSS. We started offering LeSS training classes which will start in February 2015 and we'll be creating a trainers network who will be giving the certified LeSS practitioner course. We got the website up and we're writing a book.
The book is almost finished... but it's been almost finished for a while. The target schedule was two months... but that was two years ago. And we'll be focusing on that. I'm very excited about that.
I'm excited about working with lots of other people and building up this network of people that have LeSS experience. There are a lot of people with LeSS experience.
About the Interviewee
Bas Vodde is an experienced coach in agile methods and especially Scrum. He's also a certified Scrum master trainer. Next to Scrum, he trains and coaches teams in TDD, retrospective and agile planning. He is originally from Holland, however has lived in China, Finland and is currently living in Singapore. In the 90s he worked as a developer in Holland and felt a mismatch between what he experienced as working and between "what the official literature said you should do". That was solved with the introduction of Extreme Programming and evenmore so, with Agile Development in general. In the beginning of 2001, he had enough of the "normal life" and moved to China where he started working for Nokia. Here, he gained experience on very large projects and the traditional ways they are run. After this he became even more convinced that Agile Development is the way forward, for all size projects. Currently he is running his own small coaching and training company called Odd-e.