Bas Vodde and Craig Larman on Large Scale Scrum

1. My name is Craig Smith and I am an Agile Editor at InfoQ and we are here at Agile 2015 in Washington DC and it my pleasure to have these two gentlemen with me – Bas Vodde and Craig Larman. How are doing, gentlemen?

Very good.

Craig Larman: Thank you for having us.

Craig: You guys are here as stalwarts of the Agile community.

Craig Larman: That means old and crusty.

Craig: I asked Jeff Patton the same question and that’s how he pronounced it as well. I think it was a certain amount of grey hair was the qualifier.

Bas Vodde: Or no hair.

2. [...] I guess, the one thing I want to to start with is how did you make it into this whole Agile arena? What was the kick off point for you Craig?

Craig's full question: Craig, I guess you have been around in the Agile community for a long time and I noticed when I was doing my research that you have been named one of the top 20 Agile influencers of all time. And Bas, you have been doing a lot of training and coaching around the world and probably more recently, as per your shirt, the founder of Odd-e. I guess, the one thing I want to to start with is how did you make it into this whole Agile arena? What was the kick off point for you Craig?

Craig Larman: It was 1978 and just wrapping up my computer science degree and got a job as a developer in an insurance company and of course, in those days, there was really no microcomputer, so I grew up in the mainframe world and the majority of the group that I was working in in this insurance company was doing traditional, mainframe development - PL1, COBOL, CICS, blah, blah, blah – in relatively long cycles, with a lot of failed projects. I was working in a programming language called APL and I got into a group where the manager basically said to us “You guys need to interact directly with the user customers and I want you guys to ship every one or two weeks” We were the star of the company and so I had this very visceral sense right away, even in the 1970’s that the ways of working and being close to the real user, and short cycles, and making it cheap to change because the tools we were using, APL, also made it cheaper to change, were really important. And that’s where it started for me.

Bas Vodde: I didn’t start it in the 70’s, but in the 90’s, working for a smallish, mid-size company building a multimedia product and we were just working the way we felt worked best, though feeling a little bit guilty that we didn’t do and work in the way that everybody says we should work and that got resolved with the introduction of Extreme Programming where once we got exposed to that, we were like “Hey, there is other people in the world doing similar things as that we were doing”. We didn’t do all of the Extreme Programming, after that we copied a lot, we definitely improved our testing practices further after that. But yes, then we started to be early Extreme Programming adopters and then later the Agile Manifesto got created and then it was called Agile suddenly.

3. [...] Is that what brought you guys together or had you worked together previously before that?

Craig's full question: I guess where most people probably know you both is from your two awesome books, and as an Agile coach they are the books that are probably the most dog-eared and taken off my shelf for a number of years, which was the “Scaling Lean & Agile Development” book which was followed by the “Practices for Scaling Lean & Agile Development” book. Is that what brought you guys together or had you worked together previously before that?

Craig Larman: Oh you want the creation story?

Craig: Yes. Where did life for both of you start?

Craig Larman: Why don’t you pick it up from your perspective first.

Bas Vodde: OK. After working in Holland for a long time I actually moved to China, I lived there for 5 years. I worked in Nokia and it was the Nokia network site, not the Nokia phone site, which is now non-existing. I worked there for a while and at some point in Nokia they wanted to experiment with Agile development. This was 2004 - 2005, 2004 still. They were looking for somebody who had some Agile experience and I seemed to be the only one and they asked me to move to Finland to do a large change project there which turned out to be not a large change project, but just experiment with Agile ideas. It turned out to be huge, but in the beginning it wasn’t. They did not know what they were going to do and Craig had written a book earlier on Agile iterative development in general, with all of the methods and kind of the bigger picture. So we figured he would be a good person to work with.

Craig Larman: And just before you go on, let me kind of take the story of that book and that connection. So, I wrote, published that book in 2002, let’s say, and I had been focusing my experiences on XP, Scrum coaching and so forth from the late 90’s through to that period and by the time I published that book I had basically gotten bored working with a single team and I very consciously wanted to explore applying this in a larger scale. The company where I was chief scientist, Valtech, we had just bought an offshore site in India and I was interested in the application of Scrum at scale there and just looking out in that world. So I was actively filtering for consulting and experience engagements that would focus on scale and it is around that time that I got contacted by these folks. That looked to me like a really interesting place to get experiences.

Bas Vodde: Except it was in Helsinki.

Craig Larman: Except that it was in Helsinki, in February.

Bas Vodde: For a couple of years we become basically pairs. So he was the external coach, I was the internal coach and we went around as pairs and it worked really well and I recommend companies to do that also because what happens is that whenever he would say something, people would say “Ah, you are not in the company. You do not know the telecom domain!” So then I would repeat the same thing and they would go “Oh, OK.” But then when I would say something, they would say “You do not know because you are in the company. You would not know that”. So then he would say the same thing and they would go “Oh, OK” So, that worked actually quite well as a pair so at some point we started doing lots of experiments and then the books were kind of a summary of all the things that we had done.

4. I think the thing for me is those books and up until very recently, were really the only “go to” place for a really good summary of how to deal with scale, how to deal with contracts, how to deal with vendors and those type of things. Was the book just born out of the experience Nokia or was it…?

Craig Larman: No. I was and continue basically just travelling around the world. I’ll typically settle in a time zone for some number of months, focus on working in clients there and then move on. I have done that for many years because it interests me. I was collecting experiences as well. I served as the lead coach of Lean Development at Xerox, the Nokia experience, Valtech India and I could go on to many other stories. But basically I was collecting experiences and doing experiments with groups around the world and the books are a compendium of experiments both from within Nokia Net and from the larger set of companies that I was working with as well.

5. Fast forward to more recent times where you have branded the approach a little more widely in Large scale Scrum or what is more commonly known as LeSS.How did that come about? Was it because the Agile community has moved on quite considerably and the books perhaps needed a bit of refresh or was it just the demand against all the other scaling methods out there?

Bas Vodde: Did they move on or did they move backwards?

Craig: The community or the scaling methods?

Bas Vodde: You want to answer it from here? Go ahead.

Craig Larman: In the early days of the Agile community, Jim Highsmith coined a phrase which was important. He called it “barely sufficient methodology”. This was an important kind of message that we were communicating, that long lists of prescriptive process don’t work and I could open up the box on why that is, but let’s just set that aside for a moment. So barely sufficient methodology and encouraging empirical process control and teams owning their processes and keeping it really simple was an important part of the original folks in the Agile community, me included. LeSS was born out of that vision and that perspective. A few years ago especially, I started to see this kind of check list approach to scaling. If you do these 40 things on this list, then your organization will be Agile and this I thought really antithetical approach to the original message of agility, of empirical process control and so on and so forth. It just frustrated me at a passion level of what I think are important ideas and what works and what does not work. I am a recovering RUP consultant, for example and I know that that whole path doesn’t work. Mostly I have been interested in just doing consulting and coaching and getting personal experiences and helping my individual clients. But especially a couple of years ago, with the growth of what I thought was an unskillful approach to the Agile message and scaling, I wanted to then help the community with a more focused message on “There is another way and we want to help share what we think is important”.

Craig: At its heart howerver, LeSS itself is not a lot different from what was in the two books, particularly the later book.

Craig Larman: Yes, it is not.

6. Was there are drive or a reason to update or is it just to pull that out and make sure it was a clear alternative for scaling?

Bas Vodde: There was another thing going on which was that we got lots of good feedback from our book from people who said “It’s great. It covers, as you mentioned earlier, all the practical things that I needed to know”

Craig Larman: And let’s notice that our interviewer is not a beginner. He is already an experienced Agile person.

Bas Vodde: Yes. So the other feedback that we got was “Wow. There is so much stuff. I don’t know where to begin” And we thought about it for a long time and eventually we got back also to early Agile concept which is the Alistair Cockburn introduced the Aikido Shu Ha Ri model of learning where Shu is the beginner level where you need strict rules to follow and Ha Ri or Ha is the being the beginning expert where you are learning to break the rules and Ri you’re actually creating your own rules. We realized that the books were on Ha Ri level and that for a lot of people it was just too much. They did not want to have 600 experiments to try out. They wanted to have something they needed to start with. So, around the same time we started creating the LeSS rules which we felt was like the minimum structure that enables things like empirical process control and ownership of the teams with their process. So that happened at the same time. Then, to continue the discussion, the comments Craig made, is that out of the frustration that we had, at some point we sat down and sai’ it's like “We have this choice of continuing what we like to do which is being more in the trenches, actually working with products, or what we think is needed now, which is to bring this, we believe more true to the original Agile Manifesto scaling message” We said “OK. That is what we will do.” So to get back to the question, the third book is not much of an update because there is very little that is out of date from our earlier two books in our opinion, but it is almost like a prequel where it has guides that help with adoption and then focuses on the actual rules, the LeSS rules.

Craig Larman: And the way that I summarize it is that I think of a scale of prescriptiveness from high to almost nothing and for a Shu level organization the “nothing” end of the scale doesn’t work and we know that the other end doesn’t work and there is a kind of a Goldilocks zone, a “sweet” spot of barely sufficient methodology in the context of a large scale organization to get them over the hump of making a meaningful change, to introduce empirical process control. What we have done in the evolution of LeSS is to hone down what are the things that a Shu level organization should actually do to put in place the minimal number of mechanisms, to make this change for empirical process control to start working. And those need to include structural changes because at the large scale structure is a very strong inertia for us.

7. You are saying that this is at the Shu level. So someone is out there decides they have to do Agile at scale. What would be the message? Why would they come and look at LeSS as opposed to one of the other myriad of scaling frameworks that are out there? What is the one thing that stands out aside from that? Is it the simplicity?

Craig Larman: First of all, Large Scale Scrum is Scrum and a lot organizations – actually I’ll connect this back to a Nokia Net story. So when I started to work at Nokia Net pairing up with Bas, one of the first things that we would do is we would go to organizations and we would give a 1-day introduction to ideas about Agile, Scrum, XP, so on and so forth. And then Bas’s group would go to the different groups and say “What would you like to do from this buffet of ideas?” And almost always the groups would say “We want to try Scrum. That looks easy!” So there is this interesting quality about Scrum which is that people can recognize that it is enough structure and enough change to actually do something meaningful, but apparently not so cumbersome or complicated that groups are getting straight-jacketed and we think that’s a very important quality of Scrum and so what we are trying to do with Large Scale Scrum is to ask and answer the questions “What are the reasons behind these ideas in Scrum and how does it make sense to apply them when there is multiple teams?” There’s some approaches to scaling Scrum that say that they contain Scrum, but I think that they actually contain Scrum the way a firefighter contains a fire and that’s not what we are trying to communicate. To boild this down to some of the distinguishing qualities, it’s the simple ideas of Scrum, really consistently applied when there is multiple teams.

8. [...] What sort of feedback have you had from people who I guess are now at that Shu level, trying to navigate them through them about the information that they can find about LeSS?

Craig's full question: I guess where this probably came to prominence is you relaunched or launched the LeSS web site a number of months ago and as a result got a lot more people talking about it. But I think one of the key things about that website for me is that it is very simple to navigate and lots of really good information on there. So, what sort of feedback have you had from people who I guess are now at that Shu level, trying to navigate them through them about the information that they can find about LeSS?

Bas Vodde: What is the feedback from them? I guess the most common feedback is “Wow! There’s lots of stuff!”

Craig Larman: Too much. It needs to be simpler.

Bas Vodde: So we added a bit more the other day and put the second chapter for our upcoming book also there. We think it is important because one of the things that the chapter does is it introduces LeSS by going over scenarios and stories which hopefully make it easy to read and also puts it more to the reality of people. So, yeah, the feedback has been positive, most people have been surprised by the amount of things that we have been putting up and we are reasonably happy with it.

Craig Larman: A couple of things that come to mind. First of all, we’ve got a case studies area and because Bas and I have never really focused on marketing per se, we’ve never really tried to even pay attention to all of the groups around the world that have adopted LeSS from our books over the years and we regularly get pleasantly surprised by case studies that have adopted LeSS and now we are starting to add them. Another kind of slight tangent from your question is that what I have come to see over the short amount of time that we have tried to support the LeSS community more formally is that there is a real hunger in the community, the broader market, for something that is in the spirit of agility at scale and as simple as possible and I think that people are appreciating that.

Bas Vodde: I think your case studies points is, so one of the things that isn’t used a lot yet, but at least I have been very enthusiastic about it is that the case studies are like not so much selling case studies, but more stories of what really happened. One of the things I have always been slightly bothered with is that a case study is always one perspective and especially on a large product development there is many perspectives. So one of the things we now created is that all people who have been involved in a case study, they can actually on the site, they can say “I was involved in that” and they will be able to add to the case study with how they have been involved, what they have done within that case study and that way, I think, it tries to build up more perspective than only the case study. It also allows people to almost build up their LeSS resume by showing what case studies, what products they have been involved with. And with all of that, I think that one of the things we are trying to do is make as much of the adoption reality, what really happened in organizations, visible so that people can learn from that. So not make them too much marketing stories, which is what typically happens with case studies, but try to get the real experience of lots of people out there.

9. One of the things that people often say to me about the Scaled Agile Framework (SAFe) is they appreciate that the framework itself is versioned and has been pretty reasonably kept up to date as they have evolved it. Is that something that you plan to continue to do with LeSS, to continue to evolve it?

Bas Vodde: Yes. We have been working on LeSS 2.4 already for a while now. It should be out in five years from now.

Craig: But I mean you were talking before about, for example, when it first launched essentially LeSS was there and then you added LeSS Huge and so it was being consistently different parts made live.

Craig Larman: Those are not new ideas. Of course, all of those things are in the books.

Craig: Of course, the book certainly had them.

Bas Vodde: The core of the framework, the rules, they are versioned simply by date of the last update. But because they are so thin and so core, we don’t expect much change in them. In fact, we hope no change in them – maybe removing something so things would be good, but we hope not to add to that.

Craig Larman: Yes, if there was an improvement it would be less.

Bas Vodde: We got the ten principles and I have had a bunch of requests for adding more principles. But we are not going to do that. We are going to stick with these 10 principles and Craig has suggested to make less than 10, I have resisted so far. The rest of the site is guides and experiments and we will be continuously adding more guides, experience reports and things like that But those aren’t versioned because they are not the essence of what LeSS is about, but most of the guides are about how do you implement that in the reality of organizations and what techniques are useful in that context.

Craig Larman: We do not want organizations to be versioned.

Bas Vodde: That would be an interesting idea, though.

Craig: One of the things that is a core difference I think between your model and others is the role of a Product Owner and if you read the Scrum Guide, for example, there is always this idea of a Product Owner per team and even the other models.

Bas Vodde: I do not believe that the Scrum guide says that because it does not talk very much about scaling.

Craig: Because it is at team level, it says you need those three roles.

Bas Vodde: If you have one team, then you have a product owner per team.

10. That is right. So one things that you allude to in LeSS is that you can actually have a Product Owner across many teams because it is often that role that is very hard to scale. So why did you make that conscious decision? Is it because of that itself is a hard role to scale or is it not needed on every team?

Craig Larman: Do you want me to pick it up?

Bas Vodde: Start, I’ll take over. If your’re not starting…

Craig Larman: Let me just try to organize… First of all the Scrum Guides focus is the assumption is that the product has one team. The real product has one team. In that context, it certainly makes sense or is consistent for there to be a Product Owner associated with that one team. To my mind there kind of a naïve approach to scaling is just to take that model of a Scrum team – a product owner, a Scrum Master and a team – and just copy and paste it. That’s a rather naïve approach. Why? Suppose that there is for example five teams, suppose there is one product backlog for the five teams on the one product.

Bas Vodde: Which is something where the Scrum Guide at this moment moves away from their one-team approach and actually still mentions you must have one product backlog.

Craig Larman: So the Scrum Guide actually, one of its only scaling comments is that there is only one product backlog, whether there is one team or many. So there is one product backlog and suppose that there is one person who prioritizes that and then lets suppose that you have five teams and each of these teams has a so-called Product Owner. So a rhetorical question: what are those five so-called Product Owners going to do 8 hours a day if they are not actually developing the system with the rest of the team members. Well, inevitably, what they will end up doing is some kind of business analysis activity: writing requirements, talking to users and so forth. Now, do you know the old tree swing cartoon where the user asked for this thing and then they got this thing? You know that cartoon? That cartoon was created in 1973. In other words, we have known in the development community since forever that adding levels of indirection between the real development group and the real users is a source of failure, delay, defects and all kinds of problems and the first company where I worked, that was our experience as well.

So, if I were to say to you “Hey, let’s create an organization where there is teams and then there is an intermediate business analyst who collects all of the requirements, talking to users and then explains those to the teams.” Would you think that is a good idea? Most people would go: “Oh no, that sounds like a very traditional bad idea” But, you don’t call that person a business analyst and you call them a Product Owner, but they are doing exactly the same thing and suddenly people are blind sighted and suddenly think that is a skillful idea because they can’t see the underlying system dynamic stripping away the titles. If you really want successful development, you want the real developers in face to face conversation with the e real users, trying to find out what their problems are, developing empathy, eliminating all of the ways to hand off an indirection. And in that context you want one real Product Owner, one and only one real Product Owner to focus on prioritization and focussing on what is the most valuable thing to deliver next, and more of a focus on the outer market, direction, vision. You want clarification to be done primarily by the teams, in face to face conversion with real users and customers. To my mind, this is not a religious issue, it is just stripping away the titles and seeing what problems really need to be solved.

Bas Vodde: A lot of the LeSS framework is about trying to push the teams closer to actually understanding the customer domain and working with the customers because once – and this has been my experience always – once you get teams who actually know that “I am building this for him to solve that practical problem”, your work becomes so much more meaningful and a lot of the large adoptions or large products that I have seen, the work of the teams completely meaningless. They do not know why they are doing what any more. So a lot of LeSS is pushing teams closer again to understand the product and the customer and we want to eliminate the roles in between them.

Craig Larman: So we sometimes summarize. We don’t want a naïve scaling approach where you’ve got multiple Scrum teams, we want multiple teams Scrum.

Craig: Excellent. You mentioned the book that is coming out later in the year which the title is according to Amazon is “Large-Scale Scrum: More with LeSS”.

Bas Vodde: Yes, it will be out last year.

11. [...] I assume the book has probably got a more comprehensive approach on how to attack LeSS - would that be correct?

Craig's full question: So that’s working on a Waterfall type approach! The website is a reasonable resource and really good stuff and congratulations for that, even if you are not doing LeSS even so a lot of the explanations in there are good just for people trying to do team based Scrum or any sort of Agile. So what is the difference? Why would I buy the book if I can get the stuff online for free? I assume the book has probably got a more comprehensive approach on how to attack LeSS - would that be correct?

Bas Vodde: It would support us. You would have because, of course, you would read books on paper and not on e-versions. So you would have a paper version. We can sign it.

Craig Larman: You can replace it.

Bas Vodde: You can put it in your bookshelf and it will look nice.

Craig Larman: Of course, he is just teasing. The book contains something that bas mentioned before, which are the guides. This is essentially the smaller set of 50ish key suggestions or guides that we have to go about everything from adoption to how to execute a sprint, to how teams coordinate together, to the role of managers and so forth. All of those guides which reflect our experience over the last 10 years are not on the site – not that we are meaning to hide them, but we are just focusing on writing them and putting them in a cohesive story that fits together in a relatively small book you can just hand to someone and say “Here is a cohesive, simplified story for a Shu level person of the things you really need to do and the guides that are really worth following”.

Bas Vodde: Yes, and that is why I joked a bit. It is not so much that the content will be much different than the site – we are not hiding the especially good secret ideas only for our book – but I think the package and the way it is formulated and things like that, hopefully add some value to the site.

Craig Larman: The book is meant to really be read front to back and it is a cohesive story and if done well, a book can add value that way, in a way that a site can’t.

Craig: I think the interesting thing about the web site, is you click around and you see that it sort of answers the questions you want, whereas as you say the book with take you on thejourney. But the website and the book are one thing, what are the other things....

Bas Vodde: So if you knew the answer why did you ask the question then?

12. So that the people on the end of the video… So obviously the book and the website are a really good resourtce, but if I wanted to do LeSS in my team, how else are you helping the community to go on the LeSS journey?

Bas Vodde: One of the things we started doing when we decided to pick this up more seriously and take some of our effort out of working with products and promoting LeSS, we decided to set up an organization with a trainer network and a certified training program. So we created two courses, the Certified LeSS Practitioner and the Certified LeSS Executive and we’ve been since February we have been giving these trainings everywhere around the world and right now there is seven LeSS trainers, by the time this video is released there should be 13 or so, if I remember your cycle time correctly. So, we try to provide training resources for people. One of the things we’ve done with the site is that everyone who joined one of these trainings they will be getting an account and everyone will be able to put up events that they they’d like to organize such as meetups or presentations or whatever and then, based on their regions, other people will be informed of all the community events and things that are happening within their region. I think that is quite nice.

Craig Larman: The site and our work also includes a LeSS coaching community. So, not only a sort of structured education, but coaches who can come in and help an organization.

Craig: Obviously if people want to know more. We mentioned it numerous time, but where do I go to actually find all the LeSS information online?

Craig Larman: LeSS.works.

Craig: And the book is coming out later in 2015. Is that correct?

Bas Vodde: Yes.

Craig: With the fingers crossed.

Bas Vodde: Our goal now is to get the book out before this video.

Craig: It will be a close race. Anyway, on behalf of the Agile community, I just want to thank you, as I said as a coach, your books have been the life saver to me. Thank you for taking scaling and all the things that go along with it and simplifying it for the community. Thank you for taking the time to talk to us today.

Craig Larman: Thank you Craig.

Bas Vodde: Thank you.