 Good afternoon, it's it's good to be back in India. I haven't been here for Two years or so before that I used to for a decade long be mostly in Bangalore every year but Fortunately or unfortunately, I haven't decided yet. It still looks the same And I'm going to give a short talk about less Before I talk before I start I'll I'd like to pass around this this ipad. Please don't take it Instead you can put your email If you want to and then we'll keep you informed if I might be back in April to do some training here If you are now annoyed just pass it on and pass it to the next person Good so this talk It's supposed to last about an hour, but I'm told I only have 45 minutes So so let's see whether it will fit in 45 minutes or whether it will last an hour And I will talk about three things. I will talk about scrum After that I will talk about less and then after that I will talk about why less The first two I will talk about very briefly. I assume that most of you have heard of scrum before Good And less is very simple. So explaining less takes about 10 minutes or so And then the most interesting part of this talk is about how and why less was created and I give this talk because I've I've realized that it's much more important to understand the over a decade Process for creating less than understanding less itself because it gives you more insight on on why things are the way they are So first scrum This is from this is the what I always call the the most popular perspective of scrum There's actually I'm not going to stand on that if you don't mind There's there's many different perspectives of scrum. This is the most popular one the What what is sometimes called the framework picture or the flow picture or the process picture and It is also actually the least interesting one But there's many if you if you learn to understand scrum, there's many different perspectives on scrum this Perspective on scrum is one that I like a lot more in my opinion This picture explains from much better than this picture because scrum is all about teams who are Set free to be able to organize and manage themselves the teams are Cross-functional and they build in an iterative incremental fashion That's kind of much more essential than a sprint planning shoot loss to two four hours Mechanical Another sorry another perspective of scrum is this one and this perspective is where most people don't like to talk about Because usually if you adopt scrum, it would mean you stop having an architecture team You stop having a development team and you stop having a test team and instead You build cross-functional team if you're doing scrum Well that goes associated with the appropriate Organizational changes so therefore when I go to an organization and I hear somebody say yes people from the QA Department are in the teams. I know they're not using scrum Because that sentence to me makes no sense now The way I like to Explain scrum and what I believe is is the Essence of scrum is this really simple idea of getting a group of people together But together are able to build a product They they set a goal for two weeks They go and try to achieve that goal after that they look at what they did they look at how they did it They think about how to improve. They set a new goal. They go and try to achieve that They look at what they did they and that's about it That's the essence of scrum and unfortunately in many organizations that essence is kind of lost in the the mechanic Now why is this important when we talk about large-scale scrum or scaling or scaling agile What we want to scale is not the mechanics that is reasonably easy as I'll explain later But what you want to scale is that? Sorry for fleshing that essence that closeness of working with customers that ownership of how you work and that reflection so with Less it is trying to figure out how we can get that essence of scrum to work with that When we have a product with more than one team now Less large-scale scrum Again, it has many different perspectives and this is the like scrum the most popular and the least interesting perspective it explains the the the framework or the flow and I'll be going over this in in about No, maybe five minutes, and that's the the the shortest introduction to less you'll Probably ever have so within less just like in scrum. There's always one product owner This often comes as a surprise to people who come from scrum, but if you build one product You have one product owner if you put it that way it would be pretty obvious, but the Delooting of the role of product owner into a business analyst Unfortunately, it's not that obvious so one product owner for the entire product right now the product I work with has About six thousand people working on one product. They have one product owner The one product that clock then we have multiple teams working in one sprint just like in scrum and Sprint starts with sprint planning one and in less we've made the separation of One and two more explicit Sprint planning one is a shared meeting across the team where the teams decide which items They're going to work on in the sprint. They move to sprint planning team, which is either individual or preferably multi-team multiple teams together There they talk about the design because sprint planning to is a design meeting not a planning meeting It's kind of named awkwardly They figure out how they're going to build their Increment of work and they start during the sprint the teams coordinate with each other directly there's no separate coordinator rule and Obviously the one product owner is not responsible for coordination between teams Halfway the sprint there's a backlock refinement meeting which in less must be a meeting which lost about five to ten percent of your sprint and Preferably, this is done by multiple teams together Typically about three to four teams together is the preference And then at the end of the sprint, there's one sprint review Because we have one product where we get feedback from our customers and stakeholders There's an individual team retrospective. There's of course one shipable increment. There's no Integration after the sprint all integration must happen happen during the sprint and Then there's only one event added to less over from which is the overall retrospect and the overall retrospective is Not the summary of the individual retrospective, but it is an event where Management scrum masters and product owner. Those are the mandatory participants talk about systemic and Organizational and cross-team issues the really hard parts of a less adoption Now that was the introduction to less. Thank you very much for calling Just like in scrum explaining this flow is really really simple But it is not the essence of the less framework. So therefore Instead I'm going to move on to topic three and the rest of this talk will be a story about Why less was created? The actually the let me share the the origin of this this talk the origin of this talk is in and Another conference in Singapore. I think it's about two years ago the agile Singapore conference. Was anyone there? It was a great So I didn't I did a talk about less there and it was more the the traditional introduction to less and after the I was pretty satisfied that you can find he talk online even and About a half a year later my colleague He invited me to a conference in China that they're organizing called the aha conference and He said you want to go and do a talk at the aha conference And I said sure and he said what are you going to talk about? I said, well, I made you spoken in Singapore. You saw it. I'll just do that one again And he looked at me and he said but that one was boring Okay, thanks and and he said but don't worry. It's not you it is every talk about a framework must be boring So I consider that a challenge So I thought about how can I change the talk in such a way? That it is an interesting talk and still about the framework and I figured out that One of the things that makes talks interesting is storytelling. So therefore the rest of the What do we have? About half an hour will be the story of the creation of left and And before I start the story of the creation of less I want to do a pre-story story Which is a Story about a discussion I had with my son. So this is my son As you can see a big Star Wars fan and I used to have I have lots of long conversations with him And I also think that there's so much that we Grown-ups can learn from children. I've been wondering whether we not learn much more from children than children from us And one day we were having a discussion while driving back from his swimming lesson and We were stuck in traffic in Singapore. I know that's rare compared to Bangalore But it does happen every now and then So we are stuck in traffic and he's sitting in the back of the car and he is He's annoyed because he wants to go faster. So he says to me, but I I want to go faster And I say to him, but you know, that's very nice, but It's not going to happen. We have all these cars in front of us but then He discovers that the cars on the other side of the road. There's no traffic and they are going faster So he points to them and says but they are going fast And I said to him, yeah, they're going faster, but they are going in the wrong direction We have a choice here. Sorry. We have a choice here, which is we can either go Fast in the wrong direction or we can go a little bit slower in the right direction What do you want to do? So he thought it over a bit and he said I want to go fast in the wrong direction Now at that time I just thought it was funny But the next day I was shrinking over this this conversation a little bit and suddenly realized that it it kind of summarized our industry best Because in our industry we have so much companies and people were obsessed with going faster without asking whether they're going in the right direction or not and Less is not created for going fast Maybe you will go faster. I'm not saying you will go slower But it's much much more important to go in the right direction And that is the key focus on less wanting to go in the right direction maybe a little bit slower now the story of less starts about Now over a decade ago. So over a decade ago. I was working with Nokia. I actually still work with them And I was at that time living in in China And I have a background in extreme programming in the pre agile time and But when I joined Nokia and Nokia Company not the one that makes phones but the one that makes network equipment. So not Microsoft but Nokia So I was living in China and I had switched to try to do waterfall Development there because at that point in time everyone knew agile development doesn't work for large products It only works for small So I've been together with some Friends of mine trying to do waterfall development really really well With a product of about four or five hundred people only to discover that it doesn't work either So therefore Nokia at that time, which is about 2005 wanted to try out agile development And they were looking in the company for someone who had Experience with agile development and they found me and I don't claim to be the only one I just claim to be the only findable one and So they asked me if I could come over and run this so-called agile adoption program And I said yes before They told me that I had to move to Helsinki, Finland You guys in the back can still hear me right because I noticed the volume is not so much Oh Going all wrong now Good anyway So I had agreed to do that before they told me that I had to move to Finland now I had has anyone ever been to Finland here In the in the winter how was it? So Finland it's very very cold So I was in Finland for two years or actually you count the time in Finland in the amount of winters You survive so I was there for three winters and then I migrated south. That's why I live in Singapore No winter still So I moved to Helsinki Finland Only to discover that there's actually no support for agile adoption whatsoever and they have no clue What it is or what they're going to do? So that was a nice start and the first thing we did Was look for somebody who could help us And the the person we started working with was my now good friend Craig And particularly because he had written this book around that time agile iterative development has anyone read this book So he had written it about 2005 and it was it was a pretty good book I guess it still is a pretty good book. It's it tells absolutely everything It tells a little about absolutely everything in agile development and that's exactly what we needed Somebody who knew well at least shared a little bit about everything because we didn't really know what we wanted to do So we invited him over to go and talk to large groups And do a one-day introduction for agile iterative development Talk about iterative development incremental development time boxes the history lean and then talk about scrum and extreme programming and feature-driven development and Etc. Just everything but just very little and After that we would go to the product groups and we would ask them. Do you want to try something out? And usually they say yeah, that sounded interesting and then we asked what do you want to try out and they said well this this Extreme programming that sounded a little bit too extreme We don't want to do that But this crumb thing that sounds easy So let's do that so that's when I personally switched from more extreme programming to a more scrum focused and we also started working with the creator of scrum Ken Schwaeber and He came by a couple of times. I we worked with him there, but very quickly we had One big problem and that was scrum by itself is described mostly for one team And in Nokia at that point there was no product with one team working on it The the smallest product at about three teams working on it and a large products. Nobody knows how much teams work on it We literally have no idea just a lot So the first question that the and that's kind of I want to focus on this question a little bit because This is kind of the founding question of less if you wish How can we use? Scrum not with one team, but with multiple people How can we do scrum not with one team with it more than one team? now We had another problem the second problem was that Craig did a little bit too good of a job because there was not one product that wanted to start trying out Scrum, but there were about 10 or 20 and there were exactly one-and-a-half coach because I was the only full-time coach and Craig worked there part-time Well at the same time touring the world visiting other places So therefore You know we had no idea and how to do this or how to solve this either But because we had so much product one of the things that we started doing is we started doing lots of Experiment where we would go to a product and we would talk over Their current situation we would work on the code a little bit and then we would suggest experiment And they would try it out and then in another product We would suggest other experience experiments etc. So in this period of time We were able to try out lots of different things at the same time And that was wonderful, and we learned lots of things that that work and and don't work like one of our earliest experiment experiments was to use one have one product owner one product backlog for For all of the teams and again that's still part of left But to also then share one sprint backlog for all of the team That doesn't work Don't try it out and in retrospect. It's pretty obvious why it doesn't work But at that time we had no idea. We're just trying out these and We tried out these things based on you know our own Thinking and and background in in things like lean But we were also at that time reading about every possible thing ever written about large software product and then not you know the the What correct likes to say the armchair Methodologists were Somebody writes a book saying I think it should work like that because those are not interesting but instead the Summaries of interesting large product So in two of the most influential ones for less probably have been these two debugging the development process And dynamics of software development. Has anyone ever read these? That's too bad So debugging the development process is basically the summary of how they worked in the Microsoft Excel version one And Microsoft Excel version one was one of the most successful Products ever because they completely took over the market in a very short time from anyone old enough from Lotus, right? notice one two three So after so the second book that is interesting is dynamics of software development written by Jim McCarthy and this book was about the basically how they worked in the Visual C++ version one product, which is also a large product also extremely successful because they also took over the market basically within a year from Portland, yes So I now focus a little bit on the dynamics of software development one of the topics that it described is a daily build Daily builds being the input for continuous Sorry continuous integration the Extreme programming practice and the second thing that it described was feature team And I'll be coming back to feature teams in a moment first another Obscure paper that influenced us a lot was the XP and large distributed software projects written by two people from Now this was of course most influential because Ericsson at this time was like the number one competitor from Nokia So therefore if your number one competitor writes an article about extreme programming on large projects, and you're in an agile adoption You'll pay attention to that But the interesting thing about this paper is that the first time I read it I thought it was utterly uninteresting and the second time also and Only the third time and I read it. It was like a light bulb going on and saying aha They're onto something, but they don't themselves yet realize the importance of what they just did and one of the things that the article described is how Ericsson applied daily builds and feature teams In their development, which always seemed to go hand-in-hand Now feature teams is a is a big and important idea in less because less consist I'll get back to that later of a couple of rules and one of the rules is the majority of the teams must be feature team and I want to pause for a moment on what that means because that means for literally Probably 95% of the large product if you adopt less it means basically a complete reorganization of your organization and That's just what makes less adoptions really hard Now let me talk a little bit about feature versus component teams was familiar with feature versus component Was not familiar with feature versus Yeah, there's no alternative between these two you must have raised your hand We didn't understand the question. I guess that's the alternative Let me explain feature component teams and let me just blank this for a bit and get out of that corner and Practice feature and component and I'll I'll give the Simplest possible example where we have a typical web application Where we have a back-end and a front-end and we need a product owner. You look like a wonderful product owner You want to be the product owner Good excellent, and we need a back-end team You guys want to be the back-end team and we need a front-end team so component teams. We typically organize the Position around the architecture that's the definition of component So the back-end team focus on the back-end part and the front-end team so on the front-end part now the key problem Of course with this is that? Unfortunately our product owner doesn't request back-end features or front-end features In fact, she doesn't care about back-end and front-end. She cares about Customer-centric feature so therefore we have dependencies between these teams and For years I always thought that dependencies between the teams is the number one problem to solve when Scaling agile development or scaling any kind of development and over the last couple of years I've realized that I was wrong dependencies between teams is not a problem and dependencies between teams is not even something you want to prevent or manage But there's a particular type of dependency that is a problem and I call those a synchronous dependency Because if our product owner would come up with features that are consist of 50% back-end work and 50% front-end work then both of the teams work on the same features at the same time and the Collaboration between those teams is relatively easy But our product owner isn't so nice and instead she requests first Lots of features with 80% back-end and 20% front-end and then at the bottom lots of features with 80% front-end And 20% back-end. Did I now mix them up or not? sorry about that The interim stop in Chennai last night in the middle of night didn't do good to my Anyway So what happens now is that this team will work on the most important feature This team will work on the most important feature which has most amount of back-end work But this team from the front-end perspective the most amount of the most important feature is of a much lower priority But for their perspective, it's the highest priority. So they will work on that But they can't integrate their work with the other team because the other team is working on something else right now So then what happens is that this team finishes? Their work and if they're done with their work They integrate it leave it half done into the code base and then a couple of sprints later this team starts Working on their part of the feature and they then integrate it in the code base and of course that never works So then this team starts interrupting this team and this team is annoyed because They're working on something else now Maybe if they haven't over enthusiastic scrum master, they would kick this team away say interruptions go away Just to be clear that would be a very bad right, so What happens is these conflicts between these teams over time? And now we're only talking about two teams with three teams It becomes worse with ten teams it becomes even worse and with a hundred teams it becomes even worse and Having these asynchronous problems is a real problem of working with multiple teams on the same product now the Just to sidetrack a little bit the traditional way of solving This and nearly any problem is by doing more planning Get all of the people in our room Do three-day release planning nap out all of the dependencies and that is an incredibly stupid idea That doesn't work. It's just putting band-aids on a broken system Instead if you want to resolve this problem, you need to change the system in which you're working and that's what feature teams do and Feature teams are really really easy. I'll just make some feature teams for you You're a front-end developer, right and two back-end developers. Can you guys get up? Go there, please and you'll get up Go there. See? done It was that easy right they just now we have two teams But both teams have front-end and back-end and therefore one of the things we can now do is we can take a Customer-centric feature and simply give it to one team and then my favorite definition of feature team almost is Whatever this team will need to do to get the feature to work in the system is the responsibility of this team We take another feature. We give it to this team Whatever the team needs to do in order to get the feature to work, etc. So no more dependencies between the teams problem solved Sorry, so but of course there are still dependencies between the team But there are different dependencies between the teams because now all of the teams potentially work on the same code and I need to integrate at the same time etc etc etc now Traditionally that problem is much worse, but if you look at you know modern extreme programming development practices They like especially unit test test-driven development continuous integration. They're built for solving this problem This is the reason why daily builds and feature teams in the history of product development always happened to go together because they actually Support each other So The other thing about the dependencies that we have Between these teams now is that these dependencies are what we like to call synchronous dependency Which is if this team needs to touch the front-end component and this team needs to touch the front-end component Then they do that at the same time If this team does it one sprint and this team do it does it another sprint, there's no dependency And because the teams change the same code at the same time therefore both of the teams actually Benefit from working together rather than creating that conflict And those kind of dependencies are actually good dependencies to because it's an opportunity For multiple teams to work together and use each other's work So We started out with component feature teams first with three teams. Hey, these are permanent teams That's kind of rude I'm not continuing unless you go back to your team Yes, so fit teams in less are long lived Which means that there's no Plant breaking up of the team a feature team is not a feature project. It's a team you give Features, so after they're done with one feature You give them another feature Of course if the team themselves decide to mix up like like that happened here, that's perfectly okay, but we don't want Anyone else outside the team to start reforming the team based on skills and things like that. That is very harmful so anyway We tried it out in a product with three people three people three teams And it worked pretty well, and then with five and it worked well And then with 40 and it worked well And now we're trying to we're making the last steps to full feature teams in a product with about a couple of 1,000 people and it's really exciting now for me though At this point. I had enough of Finland. It was way too cold and there's not enough people there So I decided to leave and I first moved back to To China where I joined the management team of this product not going to explain what it does But it had about four or five hundred people on it and we took the entire product to start using What at that point we just called scrum? We had no name for what we were doing in fact I was meeting some people who were on this product last week And one of the guys comes to me and says boss What's this this less thing about that I keep hearing about and I say well It's kind of what you did and then the guy next to him He went to a less training and he says So I went to this training. I said what what what surprised you he said Nothing it was exactly what we did at that time But you know there was no name for that So then after a year, I moved back to I know I moved to Singapore because there's no winters And then at some point Craig said to me Shall we write a book and I said I didn't know the correct answer is no And I said yes, and it's extremely painful But we ended up writing two of those. Did anyone read them? Excellent for the other people They're really good You should read them Sorry for the shameless self-promotion Now both of these They are literally a Catalog of experiments so we just wanted to describe all of the things we tried out So the books are structured with try and an experiment which basically said we were in this context We tried out this and it worked or avoid It says we were in this context we tried out this and it didn't work no guarantee that it won't work for you It just didn't work for us and in the second book we added the try avoid Which is we tried it out in this context. It worked. We tried it out in this context. It didn't work good luck and Most of the feedback was relatively positive But we also had some negative feedback and at first of course we Declare to readers to be not smart enough to appreciate our writing Until we realized that's not the appropriate way to take feedback and we started listening better to them and The most common feedback was thank you now you have given me a thousand of Thousand pages of ideas, but I have no idea where to start Because not once did it say you must do this or not once did it say you should start with this It basically said here you go a thousand ideas So after thinking that over a bit we Decided to interpret this feedback using the Shu Hari model, which is frequently used in agile development I was familiar was not familiar with this I'll explain it quickly coming from I kiddo or I kiddo Which basically describes there's three levels of learning Shu, which means you're a beginner And you need rules to follow Not getting rules makes you feel lost Ha means you're a beginning expert or an expert beginner Which means you learn gradually which rules you can break And re you're an expert. You don't need any rules. You basically create them That's kind of the shortest summary I can give and one of the things we realized that the books were in Hari level And a lot of people were on Shu level and they needed some rules because otherwise they wouldn't start but There's a reason why we didn't give any rules because both Craig and me believe strongly in The scrum practice of empirical process control in the people should create their own Processes, they shouldn't follow any rules because if you give people rules, you know Something really bad happens and that is they follow them And that seems good, but it isn't because once they start following the rules they stop thinking And so therefore we never want any rules. We never want to say you must do that But the problem is that if you don't then people are lost They don't know where to start and if they don't start they can't experiment and if they don't experiment then they can't Create their own Processes and rules so therefore there must be rules to start But we don't want to provide any rules because they all follow them and they stop thinking but there must be rules because so we had this conflict And we didn't know what to do with that Until one day we realized that this conflict was already solved and it was right in front of us, which is It's solved in scrum Scrum has very strict rules. Some of them are absurdly Prescriptive such as you must stand up for 15 minutes answer three questions Right yet scrum also promotes teams to take ownership and is completely open on how the team actually works as a team so if you think about scrum is Is it creates prescription on the points where it creates transparency It creates prescription on the points where the team gets more Transparency so that it can take more ownership of how they work and That's what we need. So that's what we need in less, too So we decided to try to we decided to create It's a bit. Sorry. We decided to create some rules. This is a snapshot of the world Obviously having a framework that is called less. We want the least amount of rules Because we don't want to give any rules and all of the rules need to focus on the really essential things Where they create transparency? You can find these on the less side also I'm the latest book Which what got published last year explains the rules and guides on how to implement them there we go and See I need to go to this picture and we decided to And this gets back to the initial talk about the perspectives of scrum Where there's many different perspectives on scrum and there's also many different perspectives on less and I showed you the Flow the uninteresting process kind of processy perspective. No one is not so interesting. This is What we like to describe What we like to Describe as we always call this picture the the less complete picture Which describes less past so less is in essence experimentation Of course, I will never say that you should break the rules You should always follow the rules, but if you always follow the rules, you're not using that Then there is the rules the framework. There's two variants often of them and there's about three pages of those from the rules we Interacted the ten principles, which are these ones the only thing different then then usually with principles is that the principles are Retrospective so they weren't created based on what principles are a good idea, but they are What principles have we used in the successful experiments over the last ten years? And I'll still explain one of these principles is the last thing of this talk and then the guides are Descriptions on the effects of the rules in organization, right rule says for example The majority of the teams is feature teams the guides say what feature teams are and how you actually do that in an organization? because that is really hard so the different we have these different perspectives on less also the flow picture we have the The less complete picture we have the the experimentation we have the essence of trying to get all of the teams working with customers directly on You know building something reflecting building something reflecting then we have this structural thing of how the organization should be structured less is quite prescriptive on the How you structure your organization and then we have lost that didn't go well. That was a bit too fast We have lost the More with less principle and the more with less principles one of the less principles one of the most important ones And I'd like to end with five more minutes of explaining this principle Now I always like to Start this explanation by this quote this quote built your method up. Don't tailor it down Comes from a book called balancing agility with discipline Has anyone read that? For the other people don't read it It's not very good, but it's an interesting book Partly because of the author the author is Barry beam Who has been one of the most influential persons in our industry in fact If you trace back the history of waterfall development, you always end up with very beam He's probably the inventor of waterfall development, although he will never admit that So therefore you got the a book written about agile development by the potential inventor of waterfall development Which is what makes it interesting And if you read it, that's also why he doesn't really understand it, which is why it's not very good but he Comes with this different perspective and one of them is this which he says, you know what? Our industry has made a huge mistake over the last years, which is we always Create these huge methods these frameworks and methods and then we give them to Organizations and then we say don't worry. You don't need to use all of them Instead you can just tailor it down. You can remove the parts that you don't need And Barry beam said that doesn't work and I'll get to that in a moment Instead you need to build it up. You need to find the minimum essential core The absolute minimum and and tell organizations This is the absolute minimum that you should be doing you don't ever need to remove from it But if you're in pain and only if you're in true pain you would add to it Now why is that let me go there first One of the reasons is that whenever you ask an organization to tailor a method down remove from it They usually that is done at the beginning of a new project or product Where the people are new the technology is new the customer is new And we have the least amount of information about this product And with the least amount of information we make these important decisions five minutes four minutes three minutes With this yeah with this least Information we have we make these important decisions Right and what happens is that we look at the process and we say do we in our product Do we need to have a release train conductor? We don't really know but we we better keep it right just just to play safe Now what happens is that? These products end up with too much processes artifacts and rules and Traditionally people think that too much processes artifact and rules isn't harmful But that is the mistake adding too much processes Artifices and rules is extremely harmful because adding too much processes Removes ownership from the teams more processes less ownership Too much artifacts leads to a bigger distance between the customers and the teams More artifacts less customer focus and too much roles Takes responsibility away from the teams and put it in separate people. So more roles less ownership And we don't want more processes artifact roles, but we want less of that We want more ownership more experimentation more customer closeness and What is the last one I? Forgot the last one I Had them right We want more with less. I'll just end it here because the other people are getting angry