 Great So Yeah, we got a bit of metrics got a bit of metrics, right these guys get something done on average three days These guys get it done in 20 days Right, so it's helpful to visualize of course. We also it's also useful I mean if you can walk into team room and see if people seem to be having fun, right? There's all these soft factors that also count, but here we also get a little bit of more, you know Concrete data right useful Also useful for a team to do self diagnosis, right? Let's back out a little bit Anybody here in Japan? Anybody been inside this park? Yeah It was a while ago. I was there. I actually grew up in Japan I spent the first 16 years of my life in Tokyo and I Actually, I haven't been to this park. I don't think But people who have been told me something interesting That during that the peak season during cherry blossom when you walk into this park It's very big park is a lot of people there and having picnic So you walk into the park and there's a guard who gives you a ticket? He gives you a ticket and it doesn't cost anything. There's nothing specific printed on it. Just gives you a card Okay, what do I put it in my pocket? I guess and I walk and I have my picnic And then on the way out of the park the guard is collecting the tickets. Can I have it back, please? Why? Huh? It's time. I spent in the park. I that's not visible on the card. There's no time style. I think there's a time stamp There were people in the park that that's my guess Because it's it's a beautiful solution, right? They're only we only have 1,000 cards on the table So when all the cards are handed out the table is empty the guard doesn't let anybody in he doesn't have to count Right and if people come out we get cards back if somebody lost their card will print a new one Okay, big deal. So this is a simple flow control mechanism Kanban just means sign in Japanese just as so if you tell Japanese people we do Kanban They'll be like what we do sign But the way it's come to be used when you talk about a common systems a single-link system is Visual and limited in supply Right because there's no limit to the number of cards on the table. We lose the whole point for this park, right? So that's a Kanban system if you like Right, it is a single-link system, right for supply and demand and Then the movement of supplies and services and then it's visual and it's limited in supply Or at least it should be and if it isn't your system kind of breaks down, right? This is a 10 million dollar bill or From a from Zimbabwe Bank of Zimbabwe on this hyperinflation If you don't limit them on a currency and in this your system you get problems just like in Kanban I know it's a bit stretched just calling this a Kanban system, but I just want to you know Help you get this in perspective Okay, so Uses Kanban in fact, this is Tai Chi owner who is considered to be by many the kind of the father of the Toyota production system Which is a Japanese word for what we call lean and One of his famous quotes is that the tool used to operate the system is Kanban, right? It's kind of that the lifeblood of what makes this work and What and I visited Toyota and saw this in action. It was quite interesting is There's a buyer Right or consumers such as a factory, which is you know putting cars together and then there's a supplier supplying maybe door handles or something, right? and as This this supplier has expensive people and expensive machines But they will be idle until a Kanban card shows up saying there's demand, right? And when there's demand they produce another a new batch of widgets of hand door handles And they put that in a box and they put the card inside the box and they ship it off So this truck is going to the to the consumer or to the factory and then there there's a person putting together a car or machine and as they When this box of door handles or whatever is empty They take that Kanban card and they put it in another box to signal that up. We have consumed it. We now need more, right? So these cards boxes of just cards go back the other direction and There's a limited number of these cards. They're physical things moving around, right? They talked about like yeah, we would actually like to have an electronic system But we haven't found any better way than the physical so far, right? That's it. They have some parts using electronic Kanban, but anyway, so the philosophy there is it's better to have machines Doing nothing than to produce lots of stuff that nobody needs right now because that just generates an inventory, right? So yeah, that's kind of what Kanban means in in in the manufacturing Toyota but in software, it's different It's really not a lot of correlation other than the ideas behind right because we're not moving physical parts around so much So software the basic principles of Kanban if you look if you read different books you talk to different people Nobody really owns the definition of Kanban David Anderson was one of the early pioneers, but nobody really owns the definition. So there is some divergence But just about anybody you talk to would agree to at least these core things visualize the workflow, right? You know, what are the steps in our workflow and visualize the contents of the workflow? What are the things that are in our workflow right now? And limit working progress So board like this can be useful without whip limits, but don't call it a Kanban system because I'll just be confusing It's really quite core. If it's not if there's no whip limits. It's really not not Kanban Might still be great So we play how many things are allowed to be here, right? There's many ways of doing what limits it doesn't have to look like this another per column But somehow I'm making a limit to how much stuff can be on the board and that's to make us fast, right? And measure an optimized flow So yeah, that's 12 days for I take it to cross this board whether it's user stories or support issues or whatever you're doing in your Process just you know measure that and they use that as a handle to drive process improvement You know, what can we do to cut this at half? Maybe we need to reduce the size of this queue, right or whatever Explicit policies Kanban doesn't really give you anything more than this So start from what you already have and just visualize it start doing whip limits and make policies explicit things like Definition of done or what are the whiplers make it make even those visible because by making them visible. They're easier to challenge and question and thereby easier to improve right So make them visible not because they're standard and aren't allowed to change But because you want them to change and therefore make them visible so we can attack them, right? So a lot of this is about continuous improvement So this is kind of the core of Kanban. Here's just an example of a typical Kanban board In fact, there's no such thing as a typical Kanban board They tend to look quite different, but this is just yet they're 16 people doing organic feature teams That means that they're not stable feature teams They organize and reorganize as needed to implement whatever the highest priority stuff is on the board, right? That's what they do Here's a big okay, I talked about this yesterday This was a 60-person project divided into three feature teams here We actually had two layers so we had the big project shared board and then each feature team had their own subboard so here were epics and Features and down here. We have features broken out into tasks. So teams are working at this level two layer system And of course you can do this electronically too. It just gets a lot harder, right? But if you're distributed Physical is not always the best way although there are tricks for that too So electronic the principle is all the same whether you do it physically or electronically Remember if you do do it electronically make sure that darn board is visible all the time, right? If you have to log in somewhere to see the board, it's dead probably Right, so have a projector make make sure it's our TV screen on the wall So people walk by it every day as they go get their coffee or whatever So as we compare these things We've got to be careful we're not comparing things to judge them we're comparing to understand And I like using the metaphor of tool And what I mean by tool is anything used as a means of accomplishing a task or purpose, right? So there's physical tools of course like a hammer or a fork By the way, what's before what's your favorite by the way if a fork or knife? Any favorite tool yeah, yeah, you like fork, yeah, hand up who prefers fork What's the purpose he must be a consultant yeah, it's just It's a silly question you can't evaluate the value of a tool unless you can talk about what's the context and Compared to what by the way, right? Maybe a fork is not very good for eating soup compared to a spoon But a fork is very good for eating soup compared to a chainsaw, right? So it's all depending on what you compare to Right, so the process tools things like pair programming. I'm simplifying. I'm calling that a process tool The product owner role process tool and there's thinking tools like lean agile systems thinking that fluffy stuff That's been principles and putting a bunch of these together into containers what I call a toolkit Scrum is like a toolkit number of principles a few practices and so using this kind of a terminology Then we can classify tools along this axis more prescriptive more adaptive what I mean by that Well, Scrum actually has 10 things in it if you read the Scrum guide It says you have to have a product owner a Scrum master team There's the and you have a few artifacts and a few activities and adds up to 10 right depending on your account Right, so that's how much Scrum tells you to do the rest is adaptive. So where does cut? Where does Kanban gone? Which side of Scrum? As more adaptive Kanban only tells you four things depending on who you ask But I gave you the four most common denominators, right? And if you don't do those for you probably shouldn't call it Kanban So you don't have to do sprints in Kanba. You don't have to have product owner You can if you want to but Kanban doesn't you know prescribe that right so adaptive better Lot of consultants in here. Yeah If adaptive was better like oh, it's better to be more flexible, right? Yeah, then why not just do that? Do whatever It's the most adaptable method in the whole world because there are exactly zero things prescribed, right? Which is a little bit silly. So yeah, there is some value in fact the value in a tool isn't how it limits you If it is unlimited, then it's really kind of What what does the tool do if you can do anything, right? So yeah, if we go this way XP tells you, you know, it constrains even more, right? Although it's a bit debatable because XP doesn't actually force you to do pair programming, etc But strictly speaking there are 13 things that are in XP, right? So it's a little bit bigger than Scrum Right, what about Rup? Does anybody use Rup rational uniform? I'm gonna get some coffee. I'll be right back. I Stop counting after 120. These are all the things that Rup Of course I'm cheating a little bit because Rup doesn't tell you to do all that it gives you this smorgasbord this Pile of stuff and you choose what you want, right? So nobody in the right mind would use all this, right? Eva Jacobson who boarded one of the guys behind this would laugh if somebody it's like idiot Of course, you're not gonna use all this you pick the stuff you need But the difficult thing here is that Rup gives you too much and you take away the stuff you don't want That seems to be hard Scrum Kanban gives you too little you need more that you iteratively adaptively discover what that is and you add it As you need it, right? So you start with too much and take away what you don't need and it's not really part of the process to reconfigure up as you go So you kind of stuck with what you have Here it's more like you get a little bit and you adaptively improve that maybe one of the reasons why these seem to be Gaining more success and popularity and this is quite quickly. You know, there's few fewer people doing this But nevertheless, there are good ideas in here some stuff like use cases could be perfectly fine You might put use cases in your backlog or who knows so don't develop an attachment to any one weapon or any one School of fighting said Miyamoto Musashi a famous 17th century samurai, right? Don't get don't fall in love with this one or that that one tool makes a match, right? When you're just learning something I stole this from Jeff Patton a great metaphor if you're just gonna learn to ski I don't know I might be a stupid metaphor in India. I don't know how many of you ski Okay, if you write so when you learn to ski You learn using this kind of funny technique called the plow, right? You're you're you go like this with your skis, right? And it looks kind of silly and gets you down very slowly, but it gets you down fairly safely, right? Experts don't do that normally, but if you're gonna learn to ski you better learn to plow first or else you might get hurt So you learn to plow not because you want to get good at plowing but because you want to be able to stop plowing All right, so it's like training wheels a lot of this stuff is training wheels Right if a team is really good at focusing they might not need whip limits because they don't gather a lot of whip You might not need the scrum as a role if the team is good at self-improving, right? So think of these as starting points not not end points, right and and and have the courage to break the rules Don't don't get stuck on what the books say, right? All right, so toolkits. There's some overlaps from XP Kanban There's a lot of like in the middle here. I would say visualization communication is very central to all three But XP is more engineering practices stuff Scrum is a little bit more about the interface between that between the team and the outside world and yeah There's little different flavors of agile and lean and there's some tools that are useful in all three cases But don't belong to any specific one such as value stream mapping. It's a tool So any tool can be misused What do you think this guy is thinking he just bought his shiny new chainsaw and he's trying to chop down a tree What's in his mind? That would a crappy tool. It was expensive too The whole tool was better So he didn't understand that the new tool means a new behavior and as long as he blames a tool He's making it impossible to learn, right? So you got to be careful about saying that scrum didn't work for example, in fact, I'm doing a whole talk on Saturday, I think called what to do and scrum doesn't work A bit of a blast for me to say that on the scrum community Yeah So I'm gonna do a little demo and If we had more time, I might have done this interactively but now since we don't quite have tables and not quite enough time I'm gonna kind of just tell you what happens, right? And if you like this demo, I really strongly encourage do it yourself Especially with your managers your customers or whoever it is that is causing problems, right? right, so Here's the thing How long time does it take to write a name? If this is David, he wants me the developer to write. He doesn't know how to write So he needs to go to developer, right? If you just a metaphor here, right? So writing text metaphor for writing code How long does it take to write something like this? Who would be your estimates? You're saying it depends how many are capable of writing Right, how many have written names before? Right, so don't bullshit. We it depends. You have some idea of how long it takes to write a name What? What once again? 10 to 20 seconds. Wow. Maybe yeah, you have longer names here in India, don't you? Maybe that's What about a name about this length? What would be your estimate? Two seconds, okay, so now we're starting to get a range at least it's not gonna take a month, right? Maybe right, so I just put some most people say around four seconds. I'll just put that up What are the factors that that you know, it depends yes, it does depend on some things What does it depend on? style writing what else? Size length of name. Yeah, my skill in writing it depends on a bunch of stuff I just put out the most common answers here, right quality requirements doesn't need to be pretty or can it be fast Do I have the right tools? What's the font size etc? It depends on a lot of things, but this is a still a pretty fair estimate I might turn it into a range four to eight seconds right So that's how long it takes to write one name. So how long would it take to write five names then? Something around 20 maybe a bit longer because you got to jump between the cards So maybe a bit shorter because you're getting fast, but say you know times five roughly, right? Right, so why did that happen when we actually did this exercise? It took 60 seconds to write a name and team B took four seconds Why any idea? Do you think team B had really long names? because Or they know where or they'd had crappy tools or they wrote very pretty names. You can speculate, right? And they actually in I shouldn't have written team I should have written developer because it was just one person right writing in it in the two teams, right? But a dramatic crazy difference. This is fifth. What is it 15 a 15 times longer than we thought 15? It's crazy for something. I still is writing a name on a piece of paper working cause that I'll show you Now what about how long did it take to write five names then right? 70 seconds How can that be one name took 60 seconds five names took 70 seconds Think about that for a moment, right team B One name took four seconds if I ask a random customer of these five customers How long it'll take for you to get your name? They said four seconds here. They said about a minute, right? But if I look at our productivity, how many names did we deliver in a certain amount of time? Turns out that this team over here not only is 15 times slower. They're also three times less productive, right? So these guys can deliver 15 names in the time that they can deliver five. It's it's crazy So let me give you a hint right for solving this mystery That's a data, right? Here's a chart showing the the the timelines of these five different names being written for the first team What's going on? They're writing one letter at a time bingo. Look at that I started writing Henrik and then you want showed up say I need my name written I'm like, yes, I'll do that. I don't want to lose a customer, right? So I start writing Johan, but I'm not finished with Henrik yet And while I'm in the middle of Johan Anders calls and say, you know, I got money here. Can you write my name? Yes, sir I will get right to it, right? Corporate policy is never say no to a customer, right? So So we just keep adding up, you know, it's multitasking and as a result it actually takes every time to this exercise I get these kind of numbers. It's ridiculous because of multitasking the other team. What's going on here? Yeah, they write Henrik and if Johan calls in the middle of that they say we'd love to write your name But we're gonna finish the last one first. So you have to wait, right? So they have a whip limit And that's what really matters. The rest is just blah blah blah, right? That's what really matters and nobody brings us up try yourself ask people how long to take to write a name And then they ask you what are the factors that influence this and they'll give you all these reasons But nothing about whip limits or multitasking and that's what really kills us, right? That's what really makes stuff take time when we bounce between projects, right? So what I'm trying to do is make a business case for the idea of whip limits. Is it working for you? You seeing that the point? Limiting whip, yeah, so they have no whip limit. They have a whip limit of one. It doesn't have to be one It can be two, right? Whatever Another thing, what about planning after 10 seconds? Suppose you're building a system and these are weeks instead, okay? 10 weeks From a planning perspective, what do we know here in this first case? Nothing at all customers will ask when will my thing will be done? I have no idea Because maybe five more names will be added, you know to the project pipeline or whatever. So I have no idea What about here after 10 weeks? What do we know? We finished two projects. We've delivered them. We're done, right? So we know, you know, we know the risk We know how long stuff takes so yeah, we can do proper estimates how long things will take Oh, your name is slightly longer. So I estimate maybe seven seconds, right? So there's a bit of uncertainty, but it's not this kind of absolutely crazy uncertainty. We're talking about There's a lot of benefits doing this, but it's all based on the the skill of being able to say no Say no, we don't we have a whip limit. So, you know, we'll get to you But as a result we'll deliver 15 times faster than the competitors, right? And we'll charge half the price because we're much more productive Just have to wait, all right Um, so if you have problems with people shoving work on you causing multitasking do this exercise Don't show the pictures do the exercise with them. It's really fun. It works Okay, real life example This is my little sign. It says I should be about a third way through the time right now. Am I? More or less, right? All right This is a value stream map. How many of you have used value stream mapping a few right? So this is a game company, um, is Scandinavia and um, they wanted to get faster at building games So we did a value stream analysis Which means get all the people in the room from different roles not the whole company but different roles manager developer tester right, um Office people just one from every role and and map out what are the steps involved to get a game done You know a typical game turns out that well goes through a few people here Who have to approve the project? We got to present the concept to a concept presentation group And then they will have some resource assignment and then we have graphics being done sound being done I'm now tracing this game imagine like you know thl tracing a package right going through a city I don't care how many hours people are working. That's not nothing to do with this. This is just What steps is a game going through? So we had graphics sound then we write some code make build a logic and then integrate on the website and get it out in production Now we have happy customers right hopefully if it's a good game And we put times to that. I asked to just estimate roughly How long time does a game spend in each step and they can estimate that or we can look at examples We can take the last game they delivered and look at the data right, but normally people can estimate it And why is it one month there by the way? So sam approves this concept And why is there a one month wait for the constant presentation meeting? By the way And the meeting happens every second month So the average wait time for the next meeting is one month already there. We have one month of waste Right this game is just sitting on the shelf for a month because just because that meeting happens every other month So the red the red numbers are waste time passed the game didn't get any nearer done right Green means there's work being done. So two hours here four hours there. What happened here? What does that mean? Yeah, we we Yeah, we approved this game. So we put it in the game backlog And there's eight other games there So it took six months for this game to get through that backlog and into into development right Wow six months just sitting there because of a backlog. This is why mary hates backlogs by the way Because you're wondering Yeah, be careful of mentioning the word backlog around mary as you discovered yesterday during dinner. Yeah So, uh, yeah, and then um, yeah, here it's pretty effective. We're getting through their system Graphics sound is done. We cannot look at the games. It's pac-man, right? I can see pac-man. I can hear the sounds But I can't play the game Oops, there's another backlog Design ready games. We have 15 design ready games waiting for coding to start because these guys are very busy working very efficiently But they you know So six months wait there They work for three months except that they're multitasking. They're building many games at the same time So I asked them, what if you only worked on one game at a time? They said, oh, they can finish it in a month in a month So that means strictly speaking they could have done it in a month, but they did it in three months So from a lean Valley stream perspective that was two months of waste And then darn another backlog, you know stuff waiting for production, right? So all this took about two years Building a game But it was actually just three months of work right So three months of work took two years. This is quite typical if you do a valley stream happen whatever process you have in your company I would expect something like this unless you've been optimizing this it's it's quite common and it's quite surprising so Why does this happen, right? Why does this happen? Well, it has nothing to do with how many hours we work or how many employees we have It's not that we've got to hire more people It's flow control As long as there is more stuff coming in here Then what is coming out the other end? Doesn't matter what we do, right? It gets crowded, right? If you pour in 30 liters of water into a pipe and you got 20 liters of water coming out Do that every second the pipe is going to burst, right? I think crowded you get turbulence So yeah, um, so I'm going to skip this silly metaphor. I don't need it. Um, so I think you got my point anyway So it's a flow control issue. It doesn't matter what we do inside here. We got to look at the end points, right? So how would we tackle this Yeah, your consultants many of you Keep less things in flight. Yeah, how which policy would you introduce to make that happen? Come on. Hey, wow. That's a good idea. Yeah, come on or scrum would work But it's not the only way of course, right? Well, we decided to do a scrum Scrub tends to be more revolution calm down tends to be more evolution So you pick what you need sometimes you need more evolution sometimes you need more revolution And I'm not going to explain why I hope that'll Be clear as I do this presentation, right? So we did a revolution. We said take these people out from here put them in the same room Right Everybody needed to build a game turned out to be about eight people in different roles put them in a room You guys can work any way you want But there better be a demonstrable production ready game every second week That was the rule do whatever you want But they have to be a demo every second week production ready game But you know flexible scope. So how do you think the first demo looked like after just two weeks starting from nothing If we're building pac-man Yeah, a little yellow ball. That's all maybe right What does that prove well proves that we can collaborate we can get something into production We can draw graphics we can do it proves a lot of stuff actually Next two weeks they demonstrate the guy can move around, right? Etc every two weeks we look at this thing and we think about what to build next And this is really the the core of scrum right Now but the core thing is they're not allowed to build another game until they finish the first game That's the whip limit, right? So we did this Proved that hey at this team can build a game in three to four months and they can do it repeatedly Which is eight times faster. It's crazy people like wow So they just the structure kind of died and they pulled out more teams. They after all we had three such teams So that became our natural whip limit three teams equals three games at a time instead of like 40 which was up here So that's an example of our scrum Indirectly reduced our whip and thereby made us very fast without hiring more people or adding more cost This is this this case Uh is is described in more detail In in Mary's second book. This was my client, but Mary liked this case So she put it inside Leaning lean software development. So if you want more details, you can find it in there It's put on my stuff to blog about lists for quite a while all right So cross-functional teams, why why does that make you so fast? Well, because if suppose we have a linear handoff situation here Whether it's requirements design code or whether it's a graphic sound code or whether it's code test deploy Whatever your serial pipeline is Tends to have people optimize joe is really fast And dave is really fast Lisa's very fast Why is Lisa very fast because she doesn't start her work until everything else is done? Right, so that makes her fast like I don't start testing till everything is done So then I only have to test once right But the whole takes a long time you put them together and cross-functional team Okay Um the collaboration going on right I test stuff before it's done Whether it's requirements design code or whether it's a graphic sound code or whether it's code test deploy Whatever your serial pipeline is Tends to have people optimize joe is really fast And dave is really fast Lisa's very fast Why is Lisa very fast because she doesn't start her work until everything else is done Right, so that makes her fast like I don't start testing till everything is done So then I only have to test once right But the whole takes a long time you put them together and cross-functional team Okay The collaboration going on right I test stuff before it's done Right and then there's feedback going up and down all the way So I'm a bit slower right because I'm collaborating with other people and there's feedback going on But altogether we're a lot faster and we're building a better product too because we're collaborating right So this is one of the reasons why cross-functional teams make you very fast Incidentally, it turns out it's more fun Almost every company I work with that move from this to this say that they enjoy going to work more now It's more fun because we're focusing on building something Together like a product instead of me focusing on moving a widget from one place to another right Right, so if we had done Kanban, which we didn't we did scrum But if we had done Kanban here, it would have been like take the existing process don't change it But map it out on a board make this value stream map live And so we could see what's on the board which game is where in the process And then gradually add whip limits and that will drive collaboration and all kinds of good stuff And over time we'd probably get similar results But it would be more gradual right So sometimes this is the right solution when you don't know that that scrum is the right solution You might start with Kanban, right my case study yesterday was was exactly that And it's Quite common doing this also, you know work in progress done work in progress done a little trick to find Kanban So what's anyway going back to scrum case we have three scrum teams That means we can create a portfolio level Kanban board saying that well We have three games in progress here, and this is kind of how far they've they've come this one's just being polished here It's mostly concept work, right So each game and each game team reports where is our our thing and then here is the next game We don't need to have 20 games here. It's enough with one right? What's the next game? We're going to build that's all we need to know so we don't need to decide that up front We'll look at you know how popular was our last game and based on that knowledge. We'll choose the next game Each game takes three or four months. So now we can we can start experimenting and playing around What about this crazy game concept? Let's try it out Before the feedback loop was two years. So it's kind of scary. So we better plan a lot to make sure we build the right game Here we can just experiment right So I'll give you another concrete example Here's a company that that this is a common trend. You'll probably recognize this Three teams start doing scrum, right? And there's a handoff to operations It's quite common Some of the best companies I've worked with don't have that anymore Spotify for example, they don't have handoffs operation. Each feature team puts stuff into production on their own And they're supported by an operations team. It's an important difference But in this case, you know, okay, there's a handoff the operations guys get inspired by scrum Look at those guys doing something cool. It seems to make them have more fun to get more effective Let's do the same and they do scrum and they're like, yeah But not quite right. It got us to a better place, but sprints Yeah, I didn't quite fit us sprints and iterations. So they ditch sprints And and maybe keep the other parts of scrum and introduce whip limits and now we have this scrum team delivering to a kanban team So in this case kanban was pretty much scrum minus iterations plus whip limits And then these guys over here get inspired by ops and say look those guys aren't doing iterations And we don't want to do iterations easy because we're building all these little things that our Requirements keep changing. So we don't want to have these fixed sprints. So let's start doing kanban us too, right? At Spotify the teams can choose whichever method they like as long as they, you know, deliver early and often So some use scrum some use kanban some combine them. They're quite compatible all right So, um, I'm going to give a little demo of the mindset that kanban is trying to give a team Right, and this is a cartoon animation It's on my blog too if you want to find it if you just google around one day in kanban land But this is a cooler version because here we get stuff moving on the board. Yeah Very simple kanban board Rather simplistic most boards aren't the simple but just illustrate the point Here is a backlog like okay. Here's a bunch of stuff that we want to get done You can you know, are these user stories are the bug fix? I don't know but this is stuff we want to get done right and The next two is like these are not in priority order But the question is one of the next two things we're going to build and it's limited to two You don't need to have we don't need to know what ten things Because as we start building stuff we can start thinking about what are the next two right? And the team starts working on a and then they finish that They start working on b And now this becomes like a trigger to the product owner if you have a product owner The trigger is all the team is going to run out of stuff to do soon. I better start thinking about that, right? So the two things pop up there Um, and we get a done pretty in production And so basically you can imagine the the client Reaching his arm in and pulling out stuff like this. It's a pull system, right that makes sense This is a sunny day in kanban land when everything is fine and dandy It's called single piece flow. You don't need kanban if you're this good Your process is working right kanban comes to use when your process sometimes breaks, which is a normal case So let's look at a rainy day in kanban land a lot more interesting Just finish this simulation All right rainy day in kanban land All right, now I added some roles too. We have a product owner a cross-functional team of developers and testers And here we have specialists that that that do release stuff operations, right? So just an example um, and the p.o picks the next two things here They work as a pair on a because they think two people is just the right number of people for a task, right? Whatever These two people start working on Why by the way, why don't they all work on a? Wouldn't that be more correct? Yeah, maybe it's just very ineffective. You know two people is great Three or four people is a crowd. You don't need that many people That's context specific, right? So it's a cross it's a self-organizing team They choose how to use their time effectively and they decided that this is the most effective way we can work Perry, okay Fine, that's why the whip limit's not one. It's three in this case. We allow for this right the team chose this number themselves Product orders thinks about the next thing And they get done with a right so that's a trigger point for the ops guys over here puts it to production It's a handover. We don't like handovers, but sometimes it's a fact of life So con buddies just start with what you have, right? That's what we have All right, um, and they start working on c, you know, you know, they finish, right? So they start working on the next thing it's natural Oops Something went wrong highlight that right something went wrong that uh, we got a stack trace We can't put stuff into production darn right So maybe they decide to split up. Okay. I'll keep trying to fix this and Lisa here tries to put b at the production That's their choice, right? How are we going to get flow? Um What do you think those guys are going to do now? What would they normally do in a typical scenario without kanban? Yeah, you know, we're done. Let's start working on the next thing. We're programmers, right? They might even they might not even know this is a problem here and if they do know that it's like that's their problem Right But they can't know because look it's a it's an alarm bell saying look, you know, our work limit is full We want to add in more, you know, it's like it's like paper jam and the printer don't keep printing right fix the paper jam So what do they need to do? They've got to go help out right find out. Maybe they can help explain what the stack trace means or something, right? And as a positive side effect, they'll learn a little bit more of the consequence of their crappy code Just good learning right follow your your dirt downstream and see what happens with it Right All right Now, uh, see got done moved over you note that this whip limit applies across both columns. So this got done And the product owner is not affected yet because his whip limit is not full right So he's still thinking about what to do next but uh, oh, maybe the whole build environment is down, right? This is problem is getting worse So what what what are they gonna do now? Go ask how can I help, you know, maybe they can't help maybe there's enough people here That's fine. The answer might be no, you can't help, you know, or go buy pizza for us could be anything, right? But go there and ask how can I help? So this everybody's it what this creates it creates a global sense of urgency and it gradually escalates Like we have to fix this and we can't just add more work on top of it So after a while even the product owner will be affected he'll be like why is my stuff still stuck here, right? So he'll be incentivized to wander over and say oh, what's going on? Oops blockage here So what's what should the product owner do? If he's not technical for example, which what might he do? The animal future would create more problems. So but so what should I do instead? Should I just go home? There's a lot of stuff I could do but the first thing I should do is ask these guys how can I help, right? Because here's the bottleneck So that's not only their problem. It's everybody's problem. How can I help? I'm not technical, but you know can help someone. Yeah, you can you can pick up my kids from school You can you can block the door so people stop coming in disrupting us You can get more money for a new build system or how about you just go out by the new build system? This is what we need, right? So so this is servant leadership So this is the kind of behavior that we're trying to trigger and by doing that We maximize the likelihood that this problem will get solved quickly before it becomes a big problem Right and we get learning everybody has now learned something from this because if it's a recurring problem We got to work differently to make it not happen again This makes sense So this is what what come but the big type of behavior that come on will promote It doesn't always happen if people don't want to collaborate. They won't But I've been surprised quite a lot of times It seems like most people actually do want to do a good job and they do want to see good results And when everybody sees the whole and they see the consequences of their actions people tend to do the right thing Um, it's interesting. All right. So it stabilizes and we're back on track again, right? So evolve your process. I mean, why is the board structure like this because that's where we started from and it's going to change so Common is grown by both empirical, right? There's like Meters we can look at capacity. What's our velocity? How much stuff is getting delivered per week or something? And what's the average delivery time or flow through time for one thing we're working on? These are easy to measure. I gave you examples yesterday. Some of you um quality defect rate Test coverage whatever quality metrics you use and even things like predictability Now predictability is not a goal at the panel this morning. I said that 100 percent predictability means zero percent innovation So be careful with predictability But a little bit of predictability is useful for planning, right? So you can measure that too and then think of you know, your process has a bunch of of levers You're pulling on, you know, should we have a few large teams or many small teams? Should we have high whip limits or low whip limits many columns few columns? There's all these things, you know, no iterations short iterations long iterations tweak and experiment and find out what happens and gradually improve your process, right? So that's a commonality with both scrum and kanban. We don't try to get it right from the beginning In fact, we just assume it's going to be wrong from the beginning Kanban is more configurable like I mentioned before because it doesn't tell you that you have to do sprints, for example Oh great more options, right? But oh shit more decisions Go to the bad side yin yang, right? So here's a real-life example April 7th, here was the board A couple of weeks later that was the board that was unusually fast Normally evolution is a bit more careful You got to be careful too because evolution shouldn't only happen in the direction of adding more stuff to the board Because then you get complexity, right? You get like technical debt on the board in a sense So you got to you know, maybe we remove a column or simplify it But just allow the stink to evolve it tends to stabilize after a while So how the heck do we know what the right whip limit is? Let me see I'm on time Right, so how do I know the right whip limit? Well, I don't but there are symptoms of being too low or too high So a symptom of a too low whip limit is people have nothing to do Right, we said the limit is only one and now there's people working on that So we have nothing to do that happens a lot. Maybe the whip limit is too low And that makes flowing slow because we have people who are just doing nothing Whip limit is too high. How do we know that? Well because tasks are off an idle All right, we've got too much stuff in our system that's not being worked on So people are off an idle Adhere is tasks are off an idle people are never idle here. They're very busy, but it still sucks Slow flow And then you get lack of wall space too after a while Yeah, so just the right whip limit means tasks are rarely idle. There's almost always someone working on it People are sometimes idle. That's the price we pay. It's called slack. It's fundamental in curing theory If you don't get slack in a traffic system, your traffic system is stopped So people idle sometimes is fine. That's even good, but if they're always idle, then you're you're too low So experiment right find the right whip limit start anywhere and then tweak it So let's do the comparison then just a quick comparison Well scrump prescribes rules kanban doesn't so you can choose in kanban If you want to have a product owner role or not, you can choose in scrump as well actually But if you decide to do scrump and you decide not to have a product owner Please don't call it scrump. I mean, it's not important for you to have to call your process scrump It's like, okay, there's not much in scrump. If you're going to do scrump do those things or just decide not to do scrump In kanban, all these are optional Most teams I'd say 90 percent of kanban teams I work with have these roles They might not call it the same thing. They might call that You know the project manager We might call that, you know the agile coach So but in practice roughly the same roles scrump prescribes these time box iterations where we combine all these things into one cycle We're planning. We're committing. We're reviewing stuff in a demo and we're doing much respect All this is baked into one cycle. We're doing it over and over again. Nice and simple But not always suitable So kanban team one they might do the same But kanban team two says we'll use different cycles for these different activities So retrospectives every fourth week planning every second week We skip commit we skip commit. We just planning is just you know, filling up the queue in queue We don't know how much we're going to get done in two weeks. We'll see And release every friday. We just release whatever is done, right? And if something is half done We set out. We set a feature flag. We say make this invisible to users Very common pattern. Yeah The question is come on time box some teams do time box iterations some don't so If the eight comment does not prescribe whether you're not you're going to do time box iterations What? So it uh, I'll get to that actually um Good question. So in this case this team here, they don't do a okay They do a retrospective cycle every fourth week just a second, but planning is on demand It's not even There's not a cycle for that planning is on demand You know when the team is about to run out of stuff to do they trigger a planning meeting And or when the stakeholders want to change priorities they trigger a planning meeting Um, so it's on demand and release is on demand We release when we have something that is good enough that it's worth releasing. Um, this is very close to just chaos It's a final line, right? So you had a question So it's a There's no time pressure in come on, but there is release pressure And the reason why is because in scrum there's a I call it positive release pressure Um when the sprint ended there better be something to show that causes a positive release pressure in Kanban Unless you choose to do sprints, there is no such thing as you know at by this date there's something to show But there's another type of pressure in that we have three things in progress And we're not allowed to start the fourth one until we finish one of these three So that creates a positive release pressure. We can't put new stuff in until we deliver something But I mean if you like the time box stuff then do the time box stuff So yeah Kanban doesn't say you don't have to do iterations Although a lot of people go to Kanban because they don't like sprints. That's a common reason what What was your question Break your features. I'll get to that actually Yeah So scrum backlog and it's must fit in a sprint. That's a difference in scrum You don't you don't start anything in a sprint unless you can finish it in the same sprint That's the rule So you chop things down so they can fit inside this bucket of a sprint, right? Which which is a lot of work sometimes often causes good types of behaviors But sometimes that you can say it causes waste. We're spending a lot of time Making something fit an arbitrary, you know a limit here, right? So, um, but that's scrum and Kanban is Not like that. You can have a long running task here a big epic You're working at the same time. It's doing little things. It doesn't have to be finished right there, right? But there's a whip limit So instead of saying you can only fit 15 you only only do 15 things because that's our estimated velocity We say you can do it, you know, you can do as much as you like in a sprint But you can only do three things at a time, right? So it's a different type of whip limit. Yes Yeah, indirectly Kanban incentivizes you to break things down Because you can't start something new until you finish something old Scrum is more direct. It kind of forces you Kanban more incentivizes you, right? It's different All right, so both limit whip in a different ways in scrum whip is limited per unit of time the iteration, right? You pick how many things you're gonna do and then that's what you do. You don't pull in new stuff, right? And Kanban is whip limit per workflow state typically, um, not per unit of time It's different ways of achieving the same principle And which leads to another thing scrum batches items into a sprint, right? And when we pick like 10 things Um, even though we might only work on one or two at a time and discourages change in mid iteration We try not to add new stuff This is because scrum recognizes that people need to focus to get anything done So stuff keeps changing. We get nothing done, right? But that depends on what kind of work you're doing Is it difficult advanced creative stuff or is it just little support issues you're doing, right? How how flow critical is your is this type of work? Breaking tasks into similar sizes is a common pattern, but it's by no means a rule It's scrum teams tend to do that also over time because they see the value in it. Yeah So, uh, but in so if in the middle of a sprint the product notices I'd like to have e the typical answer is wait till next sprint, please because we want to focus, right? In kanban the typical answer is wait till a slot becomes available here Which may be in 10 minutes. It knows, right? So whenever there's a slot available the product don't even put something in Or take something out right now and put it in So it's a little bit more in a sense a little bit more agile, right? We're allowing change more often But it can be at the cost of less focus and flow for the team So once again, you know fork knife It's advantages disadvantages Other minor differences a scrum board is reset You know, you see typically if you have a board like this Typically it looks like that in the beginning mid sprint and sprint then clear start over, right? Kanban board is looking like that all the time kind of Advantages disadvantages, but this is a difference, right? Um scrum prescribes cross functional teams Right put everybody together. You're a cross functional team This could be quite difficult to achieve but it's very valuable if you can do it Um So which basically means that everybody is responsible for everything Everybody doesn't have to know everything We can have a little bit of specialization But everybody shares a high level responsibility Kanban team might do the same in fact typically they often do But this kanban team over here might actually have a lot of specialization And you know this guy specialized on that but works a little bit with this Same thing here, right? They're pretty cross functional and here's a real specialist He can combine combine this this notion of cross functional and specialization Exactly yes So the difference here is that if I was going to implement scrum I would say put these people in the same room they plan together They all commit together to this whole thing Over here these guys may be in different buildings They may have different specializations They may be different departments And they're having trouble So we start by making a common system that cuts across the whole thing And the gradualist will drive them towards collaborating And maybe after half a year they'll start moving closer together And then maybe we're over here So once again revolution evolution, pink your flavor Scrum prescribes estimation of velocity But in practice I would say don't feel bad about cheating here Just because it says in a book doesn't mean you really have to do it But strictly speaking if you read the scrum guide I'll say you have to estimate So estimate the items you're building and then use that to drive your release planning Right, which is a pattern you can use It can be useful You can do that in Kanban too if you like It's the exact same mechanism How many things do we get done per week Or per sprint or per day or per whatever You can measure that But you don't have to So Kanban is more open like you know estimate if you want to So in practice that's where I get to the tasks This varies a lot Some don't estimate features they just count them Like I showed you yesterday for some of you Swedish police Some estimate in t-shirt size Some estimate in story points Some estimate in days Right, oh this can this can cause misunderstanding Because somebody might believe that three days actually is three days Which it isn't In practice Yeah You can fit a Kanban inside a sprint Yes, I don't see very many do that Some ad whip limits it's on their scrum board But what I see more commonly is the opposite You have a bunch of scrum teams That are related to each other And you have an upstream process like product management And you have a downstream process like operations And you kind of put a Kanban across the whole thing With scrums inside But that's just observations I can't say it's a rule Well typically yes There's some kind of you know you have commitments You have contracts, you have promises The thing is just avoid fixing both data and scope And you're probably fine either way Well if you try to fix both data and scope You're probably in trouble either way But this is a bit off topic I realize I should get back Because I have to be done in like what five minutes Darn time flies right So I gotta wrap this up So tasks optional You want to do tasks You want to estimate them optional I'd say whether you're doing scrum or Kanban This is a local decision Decide what you want to do Right Okay so I'm going to skip ahead Because I want to make sure I don't miss The kind of takeaway points from this talk There's some minor differences All this is inside my book by the way It's called Kanban and Scrum Making the most of both Which happens to be the same title as my presentation And the book is actually available free online If you don't want to buy the physical one You can just google it and you'll find it Right so if you're sad that I'm skipping over some details Don't worry about that right I'll skip over some details blah blah blah blah And let's get to the takeaway points Here final points Right This is a summary If you want to just look at the presentation And get the high low summary Similarities differences This is it Okay Oh by the way yeah there's the book So I'm not going to go through this But I'm showing you that it's here Um yeah that's the that's the book Don't be dogmatic That's the key takeaway point Right This is dogma And thou shalt limit whip Or thou art a bad person Like don't don't don't go there right Or go away don't talk to us We're in a sprint To use scrum Right Because we're going too much by the book Being too dogmatic Right All this does it creates anger And and and resentment Right People hate you and you and your process Okay um and there's some skills you need Either way You can't get away from You have to have these skills Whether you're using Kanban or scrum or any hybrid You have to know how to split the system Into useful pieces You have to find ways of doing incremental delivery If you build one big snowball You know the whole pile of agileene principles Won't really help you anymore It kind of starts there Breaking things down Craftsmanship If your code is crap Right These you know sticky notes on the wall Won't help you right So yeah You got to really make sure There's some some some good Engineering practices in there Like test automation etc And you got to you know Have the skills and the patience To sit down and talk about process Improvement On a regular basis Because your kanban system Your scrum implementation Is going to be broken from the beginning And then you improve it And you keep improving it Right So some facilitation skills are on that So take good points Know your real goal Because kanban scrum It isn't the goal It's just a tool to get you to somewhere right Never blame the tool It's nice Never the tools fault You choose which tools to use For what Right So um And don't limit yourself to one Go ahead and try things From different tool kits Although keep in mind The thing about learning the ski Right If you're going to use scrum You never used it before Then try following the rule But first Learn it properly Then start cheating Right Kanban You might start the board without whip limits And you add whip limits later It's one step at a time Compare for understanding and not judgment It's not about which tool is better Experiment Enjoy the ride We're learning It's fun So don't worry about getting it right from start Because you won't So the important thing is really not how you work But your process for how you improve your process So that's what really counts So that's kind of the core in lead Right That guides it Right I think that's about it I don't want to hog this room So any questions or stuff Let's do it outside Right Because there's another presentation here Thank you