Moving from Scrum to Kanban
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Davies, Rachel
Many teams who are already using Scrum would like to know what benefits they can get by moving to Kanban. Dropping the Sprint timebox can seem quite scary but on the other hand spending less time planning and estimating seems attractive to many developers. How do you know that you haven't thrown the baby out with the bathwater? Come to this talk to hear about what Kanban can bring your team and what practical steps you take to get started and keep going through the rough patches. We also take a look at potential pitfalls with Kanban and situations where you might want to move back to vanilla Scrum. I'll illustrate this talk with some stories from teams I've been coaching at BBC and Deutsche Bank.
 Hello everyone, my name is Rachel Davis and I'm going to be talking to you today about moving from scrum to Kanban. Now this is actually the first time I've given this talk, I've given lots of different talks and this is when I was talking to the organisers they said it would be good to have a presentation about Kanban and I thought actually what people are struggling with is to move or to figure out like if we were already doing some form of agile, how do we get the best of both or why would we want to change. So a little bit of background about me, so I started out as a software developer but I have become a bit post technical so I haven't been writing any code for about the last five years, I did work in an XP team in 2000 and I was doing test driven development and pair programming so really the methodology that I know best in the agile sphere is XP. Then I moved into becoming a coach, lots of organisations are wanting to get started with scrum as an initial approach so I've been working with scrum teams probably for the last six years and more and more the teams that I'm meeting are looking at other ways of bringing lean ideas into the way that they work and Kanban is a particular approach that has been starting to be more widely adopted and then people are trying to work out do we go that way or do we not go that way or do we kind of have a scrum band mixture. So also I have written a book about agile coaching so that's, I don't think it's at the bookstore here, there's a different one about agile coaching. So please I know that this is Norway and you may not feel like perhaps I was asking questions but please I do encourage you if I'm talking about something and you have a question you think I wish she would talk about this, raise your hand, let me know that you have a question. So my experience is in the industry lots of teams are using scrum, some people have heard about Kanban, some teams are using Kanban and this talk is really about how to evaluate whether it's a good thing for you to use and also what would you need to do to get started. I'm actually going to start by talking about scrum because I think if you're moving for any reason it's usually because something isn't working. So let's talk about what are the things in scrum that might not work in the organisation that you're applying scrum in. So just before we get started in that, who here is using scrum in their organisation? Okay. Now here's a very simple diagram, this is kind of a might cone diagram of what scrum is. So it's a framework for developing and sustaining complex products. The core part of it is that you have a backlog of feature requests and you're going to work in sprints and you make a little sprint backlog for the sprint that you're working in and every 30 days or less you're producing a product increment and every day you're getting together as a team, it's a team approach to kind of work out how are we going to get towards delivering that product increment. Now, so sprints are really this time box and this is the key difference between scrum and Kanban is that scrum is a time box driven approach. Now, this is like how it should work, this is the ideal view. Sprint, product increment, sprint, product increment, each sprint is like a mini project in itself, producing something that could be valuable and used and going live and people using it and giving feedback but it's not really what I see most of the time when people are actually implementing scrum. So the good thing about sprint is you have a clear goal and if you were in Esther's talk earlier on, one of the things that brings a team together is you have a shared goal. So planning a sprint, we all get together as a team, we figure out what our goal is for this month or this two weeks and then we're working towards it. So we've got a reason to collaborate and we're not being pulled off onto all sorts of other different side projects. We've got we're on this sprint, this is our goal and we're not also doing this and this and this other thing. Now, the upside of that is actually from the outside, stakeholders know how to engage, they know when to expect things, there's a sort of rhythm to the development, you have regular meetings where people can see what's being developed, there should be demonstrations of the latest product increments, sprint reviews and there's a cycle for people to know when do they need to get their features ready for consideration for the next sprint. So it's a good coordinating mechanism. Now, let's talk about some of the downsides of scram and I'm going to ask you also whether you've experienced any of these. So one of the downsides of sprints is like any deadline. So we have a date, we have to do stuff by, we may have planned slightly optimistically, there were the unexpected things that went wrong and so often it feels like that crunch time at the end of the sprint where we rushing to get things done, things that may be not done as properly as they should be. There's a little bit of a rush on testing, a little bit of compromise on design and you often end up with things that didn't quite make it, things that didn't get finished or even didn't get started. One thing I think is that this idea of having a time box creates this sort of strange way of packaging up items because the items are packaged up as bundles that fit in a time rather than sensible bundles of features that you might actually want to consume and use. So partly you do end up with this kind of one, we've made a product increment but it's not really what we want to go live with yet so let's make another one and let's make another one. So I don't know who has come across this term scrummer fall? Anyone? So there's a guy called Brad Wilson and he, I think he describes this as the combination of scrum and waterfall to kind of the worst effect. You can see what I mean, but it is very common in large organisations especially working on large products and you might actually have parallel teams working on this that you have a bit of a requirements phase and then the sprints are really seen as the development phase with a bit of testing thrown in. So you're doing your sprints, you produce a product increment, you put it on the shelf and then you produce another one and another one and nobody's really that interested in the product increment you made because it's not really going to go anywhere, it's going to be stacked up and in six months time we're going to release something. So then it means that sometimes the testing isn't fully resourced and we don't get round to doing all of the testing until maybe the fifth and sixth month and maybe we don't have all the people on board the project and maybe now we're getting towards that end point and some of the people involved in the requirements are no longer involved, they're looking at phase two. So you get some of the classic things you would get with waterfall but you are really getting some improvements through having a good coordination within the team. So the team is more focused but the general product or product development is still a big lump of software that's being built. So I don't know, I'm going to ask Sherr of Hans, has anyone seen this kind of situation? A few people. The thing is it's not wrong and I'm not here to judge or say this is wrong, it's just that some of the practices make less sense. Naturally the stakeholders just feel like well I could go and I could go to the demo but on the other hand that's not really what's going to be released. So maybe I'm too busy right now, I'll go next time and then maybe they go to the last one and then they're going that's not what we wanted. So you can get this kind of scrum waterfall situation. There are some other things which are in scrum which I think teams find challenging. So one of them is burned down charts. So who here uses burned down charts in their teams? This is often a source of confusion and mystery. Burned down charts are supposed to make it easy for people to see what's going on but just purely having a slopey line that's the ideal line and a sort of line that is where we're at at the moment often doesn't communicate that to people. It's not enough information because it doesn't kind of say where the work is. It's either things are finished or they're not finished but you can't really tell within the team what the state of them is. So here are a couple of pictures of burned down charts. They're just random pictures that I happen to have on my laptop and one of them and what you'll find is that they don't look the same for a start and you can work in organisations by different teams or using different burned down templates and from a stakeholder point of view that's quite confusing. This bar version has things that were added after planning and things that were removed after planning. Now if you know about Scrum you know that you're not really supposed to do that but it seems like this team is kind of doing it. They've adapted their burned down chart to kind of show well this is why we're running late because we have to do other stuff instead. So we're not really even using that sprint as a protected capsule around the development. There's another one I found and on my laptop I had found that I'd named this crazy burned down chart and it's because it is crazy. It doesn't actually help you know what's going on. I think what does it tell you? It tells you somebody had too much time on their hands to do tracking I think and I don't think it really helps to see where the work is. And so one of the techniques you can use in Kanban is this cumulative flowchart stuff which I'm going to come on to and that's sometimes a way to get a clear review of what's going on. Now the other thing that is a bit of a mystical thing within Scrum is product backlog grooming. Now product backlog grooming is really the art of going through the near items on the product backlog and trying to understand what they are and get them clear. It's not really requirements analysis. It's much more trying to figure out what should be in there, what is valuable, what's the next thing we should really be working on. But people find that it's somehow invisible work. The team is having daily Scrum meetings and they're focusing on what we need to do today and the product backlog work kind of always takes second place. So you end up in this situation where people kind of get towards the end of the sprint and they're going, ah, we better get some stuff ready for the next sprint otherwise our planning meeting is going to take for ages. So this is, but it isn't visible work typically. If you look at the burn down chart that doesn't really tell you where you're at with your product backlog grooming. And Kanban can help you with that. So there is one other thing that I wanted to mention and I didn't put a slide on it just because I thought it's contentious, which is estimating. So one of the things that I see in Scrum teams very often is a lot of confusion about what units we're estimating in, complexity points, ideal days, what does a point really mean? You know, people are always constantly thinking, right, when we say one point we really mean half a day or three hours or, and then there's a lot of discussion. There's a lot of time that the team puts in in terms of to try and estimate their product back, to try to get these magical numbers. And yet are those numbers that useful as an art to predicting things? So, and when you do Kanban, one of the things that I think people are attracted to Kanban is they think, great, now we don't have to estimate everything. And that's not necessarily true. You may still want to do estimation and you may still need to do product backlog grooming, those kinds of activities. But there is an illusion that people move to Kanban because they think they will get rid of planning meetings. And I don't think that's the case. So, let me talk about Kanban now. Now, I also want to know who here is using Kanban. Is anybody already using Kanban? Few people. Cool. And I should say, I'm not pro Kanban or pro Scrum, I'm kind of pro sensible things to do that work for the team. So, I'm trying to really say what's in Kanban that you might be able to use for your organization. So, Kanban is, it's really the Japanese word for visual signal card or something like that. I'm not, I don't speak Japanese, so I may be entirely wrong. But to me, it's all about visualizing the work and using visualization as a way of triggering what we need to do next. So, you need to take some care in thinking about how we visualize it to make it something that people will respond to. Now, there are a whole bunch of books that have been written about Kanban for software development. So, one of these, and I guess one of the main proponents of Kanban is David Anderson. And he's written this book, Kanban Successfully Evolutionary Change for Your Technology Business, is his title. There are other books. There's a book about Scrumban. There's also a book which Henrik Niburg has written. I think there are a bunch of different books, there are a bunch of different papers. People have been really trying this approach out. But it hasn't, I would say, it hasn't really settled into, this is what we all agree Kanban is, isn't just the same as this still debate within the Scrum community about what's the correct unit to use or the right way to draw a burn down chart. So, you will get conflicting opinions within the Kanban arena, I guess. Now, what this does is it really uses two techniques that are really from the lean product development environment, I guess. One of them is making things visual. And the other thing is trying to focus on flow by limiting work in progress. So working on fewer things, having shorter lists of stuff, having less inventory in the process. So a key thing about visualizing is if we can start to really clearly see what the flow is, we can start to get the rocks out of the way to improve the flow. If it's too difficult to see what the steps that things go through, then it's harder to really look at optimizing the end to end flow and people tend to do something called local optimization. They tend to kind of say, well, let's just get the bit of flow between you and me working rather than let's look at the end to end flow. And people are very naturally thinking about it's very difficult to let go of what is the most efficient for me versus what is most effective as a throughput for the system. So it's something that feels counterintuitive because everybody feels they should just be busy all the time. But at the same time, if you're busy, then you may be working too far ahead on stuff that you may not need. And actually your attention might be better placed into improving the system. So one technique that you use within Kanban is to just start making the cues of work visible. So you're starting to make the inventory of work in the system easier to see. So this is just a picture of wait times at Disney Park. And because it's displayed, it allows people to make a choice. So what you're really trying to do is not just make the system cues visible to the people working in the system, but also to the people who are making choices so that people understand what the typical wait time to get something is. If I'm asking for a feature and I don't really understand how long it takes between something going on the product backlog and something actually coming out and being released, which can actually be weeks and weeks in some organizations, then I will not be making well informed decisions. So it's trying to make information available to help people make better decisions. And what you're doing here, it doesn't say how many people are in the queue, it's just telling you how long will you have to wait before you get something. And what typically you do in Kanban systems is you move much towards cycle times. What's the date we started working on something and the date we finished working on something, rather than thinking about points or what points are to time, those kinds of things. You're looking at cycle times. Now here is a picture just from a scrum team. And this is their initial steps towards Kanban. So they are starting to make the work visible. Now I don't know if... Can you make any inferences from this board? Anything that you would... observations you would have about it? Can you see what's going on? Easily. It's a bit messy for a start. And actually if you're going to get into making things visual, you have to take care that things are easy to read, that it is clearly set up, that column headings are clear to understand. For example, this board has a kind of a blocked area, kind of towards the top here. But it's not really clear what's in the blocked area, where the blocked area ends or how things get in there or how they get out of there. And if you took a closer look at these tickets, so they kind of started with good intentions. They thought, well, what will you use something to print out the tickets in our defect tracking system? Because that's what they're using for their planning software. But the thing is that the program that they're using, the main thing it prints in big, big letters or rather numbers is the reference number. So if you look closely at this, it's just a whole, all the big bold text is some long reference number. So in the standard meeting, people are saying, well, I'm working on issue number one, two, three, five, six. And that's not an easy thing to communicate. The other thing that it may not be clear from this board is there's two teams. They work, once they're both writing software to run on internet enabled TVs for the Olympics. And the team at the bottom is using a particular browser. The team at the top is trying to do a HTML version. But actually what you'll see is there's a blank area in the top team. And that's because that area is ready for test. What they're doing is they're working in one week's sprints. And then at the end, they kind of go, put everything over ready for test. And then nothing gets tested in that one week's sprint. And everything carries over to the next. And so they're kind of got a, sprints are being used to build stuff but not build and test. So there's no meaningful product increment. And actually also then, the kind of demo that they have isn't a normal sprint review. It's kind of a management walk around where people show things working on the TVs in their area. So again, there's no real accountability to this is what's working and tested. It's more and more like, you know, here's some stuff. Look how cool it is. And then, so it's not an integrated team in terms of the development and the testing. So you need to do a little bit more than just make the work visible. You start needing to just try and sort of focus on, let's not have too many things going on at once. So Kanban is used in the Toyota production system. This is really going back to more lean manufacturing, lean production. And if you go to a Toyota factory and look at the production line, they're also used in multiple ways to control the flow. So each order for a car has a Kanban card that goes with it, that goes through the production line with it. Also, the stock around the different cells on the production line have their own systems of cards so that you don't have, you know, 100 wheels, you just have a stack of 20. And then as that gets used, you pull in another 20. So they keep the supply chain, the supply levels low so they're not building up batches of stuff. So they don't on Monday make a batch of red cars and on Tuesday make a batch of black cars. They have to change their paint system so that they can make a red car, follow a black car, follow a white car. And that's really improved the flow. So they're using Kanban to be the ticket for the order and they're focusing on how can we improve the flow per order through the system. Now so this is, I guess, a little bit of a sketch of something that's really a bit like the team we were looking at before. They've got some stuff that they're about to work on, there's the stuff that they are working on, but they don't really have anything ready for release because they're really thinking our real release is to make something available for the Olympics. And these mini one week sprint product increments, well they're not going anywhere so we don't really care about them that much. So one of the things to do is to start focusing on releasing stuff. So to have fewer things in the pipeline and actually get that all the way released. And when you start limiting the work in process, so you're perhaps doing less product backlog grooming now and you're now focusing on what's the next thing to release and what's stopping us from doing that. Now as well as having boards that visualise this flow, you can also use a technique called cumulative flowcharts. So I don't know, is there anybody here using cumulative flowcharts to represent what their board information is? Maybe I should also ask, is anybody using a board that looked like that board I showed you with columns and cards on it? A few people. Now who is not using a physical board but they're using an electronic board? Now there's absolutely nothing wrong with using an electronic board. The same principles apply, it's just easier and more tangible to explain it with the physical cards. And I think when you have the limits of a physical board with physical cards on it, you start to realise that you've got too much work in progress more quickly. When you're using an electronic system, it's often easier to keep adding and adding and adding rows and tickets and then it starts to be a lot of things that you're discussing when you have your daily scrum meeting. So cumulative flowcharts, I think I see them really as being a more useful version of a burn down chart because what you're trying to do is trying to make not just the general trend line visible but actually the view of how many items are in each of the columns of your board. So I'm just going to go through a few examples. So here's a very simple one and I've just tried to keep this simple so that you can get the basic principles. So you'll notice that the vertical axis is not points, it's not ideal days, it's number of things. So it's just number of items in any one state which makes it quite easy to create it because you just look at the board and go one, two, three, five, okay, and then on the next one and you usually do this in a spreadsheet. I haven't been using planning software to generate these, I've been using spreadsheets. This is a very simple process, it only has three states. So it's like there's some work that's on the product backlog that we haven't started, there's the work we're actually doing and there's the work that we've released and what you'll see is that the green stuff is gradually increasing at a steady rate and you can look to see how many items are in process at any time and you can look across ways to see roughly how long does it typically take and you'd start to look at what average cycle times are for things. It does assume that items are roughly similar sized so that's not that you know and if you've got odd shaped items your flow will be a bit more ragged. Now if you're doing scrum then what you'd see is really this kind of slightly stop start, you know you release some stuff, you do another sprint, some more stuff released, you do another sprint and if you use Kanban you're not using sprint so Kanban doesn't have the idea of wait until the end of a time box, you really are releasing as you go. So as soon as something is finished release then the next thing release. So it works very well with a continuous deployment setup. Now just to illustrate what Scrummaphore would be like if you used a cumulative flow chart you probably have a lot of different states and notice that many weeks go by before you actually have anything ready to release. So it's you're not generating the value, there's a long cycle time there before you get your value. Now what these charts can help you see and what the boards can help you see are bottlenecks in your process and bottlenecks the definition from the goal is any resource so that's a person or a thing or a machine that their capacity is less than the demand placed on it. Now it could be we've got six developers and one tester, that tester then becomes the bottleneck. Now if we added six testers the bottleneck would normally move somewhere else, it's normal in a system to have some bottlenecks and typically what people do to cope with bottlenecks is they create some buffers in their system. So what if you know that you have a bottleneck what you don't want to do is have a situation where that person is waiting around not doing anything. So you just think about the classic thing you might do in scrum where the development team is busy developing stuff and they haven't made anything available to test and then they say oh right the last day of the sprint is everything to test, that person really can't then cope. You want to level the workload and have some buffers they've got some stuff ready to test that they can pull through the system. So what you start doing when you're using Kanban is you first of all have some basic columns and then as you start to understand your workflow better you start introducing some buffers to try and smooth out the flow so you get a better throughput. Now yes. Yes, yes, yes, I'm coming to that. So I'm not yet talking about how you start doing it. I'm just trying to explain roughly what Kanban is and then what other steps that you would take. So yes, I agree with you. Yes. Any other questions just before I move on? Yes. Yes. Yes. Yes. Yes. So that's an interesting thing is that Kanban is a technique from a production line. Knowledge work isn't a production line. You're creating unique things every time and actually in software development the items are very much different sized. You can get something very, very small like change some text on a page or you know, great build this new component or you know, improve this performance and reliability of the system. They kind of different sized items and so one of the challenges really is that Kanban works best for similar sized items. So typically what teams might do is have columns where you're trying to break those down. So visualizing that product backlog grooming activity so that you're breaking things down into similar sized features so that then you can start to use this kind of flow based approach. Yes. Yes. I think that's actually a challenge for Kanban. So for instance, non-functional requirements or quality attributes, they are things that you have to be checking all the time rather than you can't say, oh well we've done the architecture because you keep changing it. So to some extent or you know, you can't say sprint one, we've delivered performance because you're going to keep having to keep checking that it's keeping to a level performance. So I agree. But I think that's an issue with both Kanban and Kanban. You have to figure out a way to do that and being clear about the measures that you have and the way that you're going to inspect for those measures is part of the answer. So I'm going to move on a little bit now. So this cumulative flow charts, I showed you some kind of ideal ones which are a little bit smoother. Typically what you start to see is that these bands start to expand where there's somebody who's blocked and waiting. And so what people start doing in a Kanban system is they introduce these whip limits. Whip is short for work in progress. And so what you're trying to do is impose a limit of how many things can be at a particular state. And what you're doing is that the way you operate those limits is that supposing you are a developer and you see that there are three things that are already in development, if one of them gets blocked, you can't start another one. You have to try and figure out how to unblock the thing that is blocked or go to help somebody else where there is a further upstream activity that, downstream activity that needs to flow through. So I've got some text to write that out because I think sometimes that gets confusing. So how do we operate whip limits? This is some text from David Joyce who's been running some Kanban teams at the BBC. So the limit governs the maximum number of work items that can be in any state at any instant. And if I haven't reached the limit, I can pull more work in. I can start doing some more stuff. But if I've hit my limit, then you can't start working on some more stuff and you actually have to either wait, focus on process improvement stuff, or try to help unblock the system. And that really relies on team communication. And it isn't helpful if everybody tries to help too much, if you see what I mean. So if you probably want to in your team kind of go, oh, we're blocked on this, right? So maybe you and you, we're going to work to try and block it. And you and you, let's try and look, do some look ahead work and perhaps not focus on the making more stuff. What we're doing instead is we're thinking about how we can improve things, maybe looking at tools, ways of, you know, improving the way that we work. Now, this is kind of a very ideal picture. But really, this is where you've got quite narrow work in progress limits. And what you'll see is that the flow of items is happening more that you're getting things out of the system very soon. So almost as soon as you finish something, it's going live, soon as you finish that something, and you're just focusing really on keeping that cycle as short as you can. Now, I'm going to flip into talking about how you might get started with Kanban. So the very first thing I think is you start with a technique which is called value stream mapping. Now, to formally do value stream mapping, as in the kind of leading textbooks, you really try to follow the work and use examples and look at how specific pieces of work, how long they actually take, where do they wait around. So if you imagine, you might write a requirements document, and then it might be waiting to be signed off, and you might have to wait for the steering committee to get together and then wait for a team to be formed, and there could be all of these different steps. Now, it's helpful to do these practical examples where you actually follow a piece of work and look at how long it really takes to get through, but often in terms of setting up a board for a team to use, you may be better off to start just sketching out what is it we think our workflow is, and so what happens in this picture? There is a little stick person, and he's starting to create a book of work. So he's working in a bank, and he gets traders asking him for stuff, and sometimes he says to the traders, no, and other times he says, oh yeah, that sounds like a good idea, yeah, let's put that in our book of work, and so that's your first cue of work starting to form. And then you start working with the team to figure out what would it take to do these things. Then needs to be a bit of analysis to understand what the impact is, where the piece of work will have to be done in the banking system, so you're doing some of the sort of analysis work, and so then what you're doing in this team is really discussing what is the flow of items, and this team, so I mentioned about estimating, this team do choose to do estimating, they say, well, we want to do some t-shirt sizing just so we can decide, like if something is too big, we might need to actually have some meetings to break it down. They also started at the, I don't know if you can quite see, but at the bottom here, they start having some definitions of done around the columns, but not a definition of done at the very end, but is this ready for us to move forward to the next? And then there are some little buffers starting to appear. Now, this is just what it looks like, it's a sketch, it's what they think they might do, it's a future sketch, it's an illustration, it's not a precise process definition, but it helps to have that conversation and start talking about what the process is, what the states that the work goes through, and where does it wait around. But practically, the team is only going to know how does this system work when they start operating it. So this initial thing, get the sketch done, then try it out. So step two, the team is now based on their whiteboard sketch, they've started to make a board design. They have some names at the tops of the columns, they haven't put their whip limits on yet, and that's partly because they want to get used to this new way of working. So, but notice that they have really tried to make it easy to read, make it clean and tidy, they've got super sticky post-it notes that won't fall off, they have, you can't quite see it, but they have some magnets that they have bought to represent team members, they haven't put those on yet, and they've started, those definitions have done that they had, they printed them out and they put them at the bottom of the columns. Now, that's, this is a board of just representing where's our work at the moment, then they start using it. And in Canman, you typically do have a daily standard meeting, but what you do in your daily standard meeting is you are looking to see, is the board representing work at the moment? Are there blockers that are not being dealt with? Do we have any bottlenecks? Is anybody kind of blocked or too busy? And you're typically, and this is different than a SCRAM standard meeting, you're focusing, you tend to focus from the, I'm just trying to think of how this looks to you, from the done column end first, you're looking back to say, pull the items this way, you're not stuffing more things in, so it's a pull system. So, you're typically, when you're looking at the work, you're not looking at what's the next thing that we should work on, you're more normally thinking what's blocked that needs to be moved forward. And you tend to run this meeting, looking at, talking about the work, not a person by person. So, it's not driving out this kind of commitment, you know, what did you do today? It's much more saying where is this piece of work? And if you're not working on any of those things on the board, then you might not actually say anything. So, you're really trying to shift this into, does the board represent what we're doing, and do we need, does the board tell us that we need to do something different? Now, as you start doing that for a while, you can start to get a sense of what would be sensible whip limits for us to try. Again, this is our initial whip limits, we may need to reflect and add more columns, we may need to change our whip limits. But, I think, I'd be right in saying that David Anderson normally recommends start with high whip limits and then gradually tighten them. So, if you've just got a whip limit of one thing per person and then one thing gets blocked, you're running into blocked quite soon, so you might want to have slightly more relaxed limits to allow people to have something to do. So, now, this is the team after they've been going for a few weeks, and if you look, you can see that there's too much stuff on the board, and they haven't really been following the whip limits. So, this is a team that's still learning, and this is what you're trying to do with the whip limits is to become more aware of when you exceed them. The way that they've designed their board makes it quite easy for you to put another post-it note in, because, so you can see how many post-it notes are crammed into the prioritised backlog column, there's too many things there. One technique that I've seen teams use is actually design your board so there are literally only spaces for the amount of tickets that you're allowed to have, and then put a kind of a cross thing so that you can't, you're very conscious, oh no, look, we're going past our limit. So, you may want to think about that, but more crucially, what this prompts is we need to reflect on what's going on. So, this is a picture from a retrospective, and it is a picture of a cake that is shaped like a bug, and it has a number on it, which is 1133. This bug took many weeks for the team to sort out, and somebody in the team made a cake like the bug, and they ate the bug, but they also used it as a way to celebrate we've killed that bug, but how did it really happen? Why did it take us in this direction? Why was this so difficult for us to fix? A lot of that came down to not having the knowledge in the team, and they needed to expand their understanding of the other systems. This was a, something that was very difficult to replicate, that was happening in one of the databases, and it was difficult enough to replicate, and really, really difficult to figure out what was going on. But it was worth having a retrospective literally just about that thing. And what you want the team to do is to become more responsive to noticing what's happening, what's slowing them down, and thinking, how do we make sure that doesn't happen again? So, yes? Yes? So, that hasn't, it just hasn't been my experience that that's happened, but I can imagine it might happen, and if that is happening, it might be an indication there's too much stuff in going on. If you're finding that the meeting is kind of getting bloated, that's possibly too many things to discuss, we probably are trying to do too many things at once. So, my reaction would be maybe to, to kind of do less, have fewer blockers, and then have a smaller focus. Now, a question that a lot of people worry about when they're moving towards this approach is they worry about where do all our meetings go. So, I mentioned retrospectives. Now, normally in Scrum, we have those at the end of the sprint, and you know, like you have your release, or you should have your release at the end of the sprint. And so, in Scrum, the meetings are pinned to the time box, and the release is pinned to the time box. And what you're trying to figure out when you move to a Kanban approach is really, what's the real frequency that in your organisation, how often does it make sense to get stakeholders together, how much does it make sense to get the team together, do you need to have some meetings or some events that are triggered by hitting a limit. So, there are, when people move to use, when teams move to using Kanban, they're not throwing everything away. It's just they're starting to realise that they don't all have to be kind of bolted to this cycle, that you can have different frequencies for different things. So it's not that, you know, retrospectives disappear or go away. Now, I'm getting towards the end of the time, and I want to now take the other point of view and kind of say, well, okay, so what are the good things in Scrum that we might lose and, you know, what would we want to be careful about? So, you don't want to throw the baby out with the bathwater. I don't know if you have that saying in Norway, what are we doing in the UK. So, I have come across teams that have been trying to use Kanban, and things are not good. And I have actually been in environments where we have gone back to using Scrum. Now, the kinds of things that were happening for that to be a thing that we decided to do was, and this is with a particular organisation, they were making a news portal, and they had, they'd just been making features as people suggested them. They had lots of features. It had kind of got into this business as usual mode, you know, somebody comes up with an idea, you just build it and release it. And it felt as if the team really didn't know where they were going or what they were working towards. They were, it just seemed like anyone could ask for anything. And so, there was this, and this is something that can happen to Scrum teams as well. It's like you just, you can't see the view outside the sprint. You can't see the big picture. You can't see the roadmap or the where are we going view. And if you can't see that, then it can feel demotivating. It can feel like, you know, I made, you couldn't, and I've experienced this on XP teams as well, is that we just release features and we release features and we're an effective team, but it feels like there's nothing big to celebrate. We're just doing lots of small releases of stuff, and we don't really know where we're going. And you can lose this sense of what is the product we're making or what's the big release plan, you know, where's our product going. So, sometimes, and especially if teams, and I've seen this where a whole bunch of people have joined an organisation and they've just kind of gone along with what's happening. So, there's a big Kanban board and they have a stand-up meeting and then they kind of go away and they don't really know what anybody else is doing. There has been a lack of the meeting coherence because if you think about it, one of the things that Scrum does is it gives, it helps the team establish a goal which binds the team together. If you have a big mass of people and it's not very clear what the goal is, you can end up with factions and with people not getting on as a team. So, that's something to watch out for really is that people are starting to just feel like a cog in a big machine and they're not really feeling accountability, they're losing, it's that big team effect that you end up having. So, I don't know, does anyone recognise what I'm talking about this kind of effect? So, what I've found is actually it can be helpful to get back to basics sometimes. Sometimes it does help to say, right, this is a product we're working on, this is the small team who are working on it, we're going to work very closely with the product owner, we're going to have sprints. But the key thing is if you can do Scrum but do the product increments, has serious product increments and not get into this Scrummerful situation where it becomes this long waterfall Scrum in the middle kind of situation. And I think sometimes when people are new to our job, you get people who are joining an organisation and maybe they said, oh yeah, I did Scrum in my last organisation but maybe they didn't really. And you can get people who are kind of passengers with the process and they don't really feel engaged with it and sometimes it helps to just bring it back to a much simpler, more rule based thing while people are learning. And then once they start to understand how things work, then increase the flexibility for changing stuff and move more towards a Kanban way of doing things. Now, I think I'm slightly early in the timings, I think maybe we've got five minutes left for questions, so have you got any questions? Any questions? Yes. Yes. So you can, well, so you can have a way that I've seen people do, they have like a ticket which represents the user story and then they have like a little tail of tickets which represent the tasks but they are small, you know, they use a mini post-it note things to have a few tasks. That, you have to really ask yourself why are you doing that and you wouldn't necessarily do as you do with sprint planning a session where you say, let's work out all the tasks for the sprint. You're much more, oh, we're about to start this item, let's figure out the task because then we can work out how to share that work out across the team. So you might have that as a triggered thing that you do as you take a ticket into starting to work on it and obviously you wouldn't do tasks for the ones that are small and kind of obvious. Does that make sense? Yes. Yes. Yes. And actually a classic thing people don't show, for instance, is testing tasks. So people kind of go, here's the development task and then we have a column for testing and we don't actually then unpack to say what are the testing tasks. So it very much comes down to the skills of the team and you have to think about when you're creating tickets, what are you really trying to represent, what's your communication, what communications that facilitate. Now, all I would say is that Kanban leaves it open as this is a toolset that you're using. So it's up to you whether that's useful for you to have a triggered event like every time we take a new ticket we do that unpacking into tasks or do we say use the task to represent the workflow so we have columns for them. But it's not something basically Kanban is much lighter and less processed than Scram. And Scram is pretty light. So it's even less. So one of the things that Kanban doesn't have, for example, is roles and it doesn't have any prescribed events. All it's saying is make things visible and limit the work in progress and then reflect on what you see. Try to look to improve your cycle times. And that then leaves it open to try all sorts of different experiments to try and improve your cycle times. Any other questions? Oh, sorry. The question was, and I might not word this question exactly now because it's been a few moments, but it was if you, so you were saying that there are user stories and sometimes the different sizes and sometimes you might want to do a task breakdown. So would you do that in Kanban or not? And you could if you wanted to, but you might not. And I think the other part was that sometimes some of these tasks when you break down an item are actually items in work, they're kind of activities in your workflow. So it might be that you don't have a task representing it because you now have a column representing it. So I don't know, was that a fair representation of your question? Okay. Any other questions? Yes. So I think it very much depends on how you establish them at this cadence of meetings. You clearly want this to be, you have some business people involved, but at the same time you want don't want everybody at all of those stand-up meetings necessarily, you may want key representative, key representatives, you might do something a bit like the product owner kind of pattern in Scrum, but you might not. One of the things you might decide to do is to have, you know, showcase events where you have everybody in the department goes to see those. So there's a bigger showcase. You might have a smaller group responsible for prioritization and it may be that two or three of those people are really sitting with the team actively being part of that system. I think anywhere where you have separation, where you have the people apart from the people, you know, so if what you don't really want is for the columns on the Kanban board to be like departments who don't, you know, who only talk through tickets. So, and then I'm just really remembering that I didn't repeat your question. So your question for the people who may not have known is what, how do you involve the business side in Kanban? Any other questions? Yes. How do you assure that the items have the same size? So you can't and it's through the team kind of going, and yes, you could imagine you've got some item. So the question is how can you assure that the items are the same size? If you get a very big item, it's going to block the pipeline up and it's going to have a long cycle time. It might be that that's a useful thing to release. And so you don't necessarily have to have things that are all the same. But it's just that if you are trying to make predictions about things based on your average cycle time, it helps to have things that are more or less the same size. But you don't, you're not trying to force things to be the same size. Yes. Well so if you had, just imagine, you had a very big item, it would just be in process for much longer. It's not, you're not exceeding your limit by putting a big thing in. It just slows things down. So it's just, that's going to start, people are going, you want to encourage people to reflect on that. It can vary. And it typically does vary. It's just that you don't want it to be very great. Yeah, you would want, in an ideal world, you're trying to break down the items to sort of similar size-ish things. But it may be that if you are really trying to release, you've come up with a minimal marketable feature that you think, right, this is the thing that we want to put live, it may make sense to do a bigger blob of work. There was, now I'm just thinking, my time is probably up. I don't know who was going to remind me about 10 minutes. Did you remind me about 10 minutes? I didn't see you. So I guess if there's any other questions then please come and see me afterwards. But otherwise, thank you.
 Hello everyone, my name is Rachel Davis and I'm going to be talking to you today about  moving from scrum to Kanban. Now this is actually the first time I've given this talk, I've  given lots of different talks and this is when I was talking to the organisers they  said it would be good to have a presentation about Kanban and I thought actually what people  are struggling with is to move or to figure out like if we were already doing some form  of agile, how do we get the best of both or why would we want to change. So a little bit  of background about me, so I started out as a software developer but I have become a bit  post technical so I haven't been writing any code for about the last five years, I did  work in an XP team in 2000 and I was doing test driven development and pair programming  so really the methodology that I know best in the agile sphere is XP. Then I moved into  becoming a coach, lots of organisations are wanting to get started with scrum as an initial  approach so I've been working with scrum teams probably for the last six years and more and  more the teams that I'm meeting are looking at other ways of bringing lean ideas into  the way that they work and Kanban is a particular approach that has been starting to be more  widely adopted and then people are trying to work out do we go that way or do we not  go that way or do we kind of have a scrum band mixture. So also I have written a book about  agile coaching so that's, I don't think it's at the bookstore here, there's a different  one about agile coaching. So please I know that this is Norway and you may not feel like  perhaps I was asking questions but please I do encourage you if I'm talking about something  and you have a question you think I wish she would talk about this, raise your hand, let  me know that you have a question. So my experience is in the industry lots of teams are using  scrum, some people have heard about Kanban, some teams are using Kanban and this talk  is really about how to evaluate whether it's a good thing for you to use and also what  would you need to do to get started. I'm actually going to start by talking about scrum because  I think if you're moving for any reason it's usually because something isn't working.  So let's talk about what are the things in scrum that might not work in the organisation  that you're applying scrum in. So just before we get started in that, who here is using  scrum in their organisation? Okay. Now here's a very simple diagram, this is kind of a  might cone diagram of what scrum is. So it's a framework for developing and sustaining  complex products. The core part of it is that you have a backlog of feature requests and  you're going to work in sprints and you make a little sprint backlog for the sprint that  you're working in and every 30 days or less you're producing a product increment and every  day you're getting together as a team, it's a team approach to kind of work out how are  we going to get towards delivering that product increment. Now, so sprints are really this  time box and this is the key difference between scrum and Kanban is that scrum is a time box  driven approach. Now, this is like how it should work, this is the ideal view. Sprint,  product increment, sprint, product increment, each sprint is like a mini project in itself,  producing something that could be valuable and used and going live and people using it  and giving feedback but it's not really what I see most of the time when people are actually  implementing scrum. So the good thing about sprint is you have a clear goal and if you  were in Esther's talk earlier on, one of the things that brings a team together is you  have a shared goal. So planning a sprint, we all get together as a team, we figure out  what our goal is for this month or this two weeks and then we're working towards it. So  we've got a reason to collaborate and we're not being pulled off onto all sorts of other  different side projects. We've got we're on this sprint, this is our goal and we're not  also doing this and this and this other thing. Now, the upside of that is actually from the  outside, stakeholders know how to engage, they know when to expect things, there's a  sort of rhythm to the development, you have regular meetings where people can see what's  being developed, there should be demonstrations of the latest product increments, sprint reviews  and there's a cycle for people to know when do they need to get their features ready for  consideration for the next sprint. So it's a good coordinating mechanism. Now, let's  talk about some of the downsides of scram and I'm going to ask you also whether you've  experienced any of these. So one of the downsides of sprints is like any deadline. So we have  a date, we have to do stuff by, we may have planned slightly optimistically, there were  the unexpected things that went wrong and so often it feels like that crunch time at  the end of the sprint where we rushing to get things done, things that may be not done  as properly as they should be. There's a little bit of a rush on testing, a little bit of compromise  on design and you often end up with things that didn't quite make it, things that didn't  get finished or even didn't get started. One thing I think is that this idea of having  a time box creates this sort of strange way of packaging up items because the items are  packaged up as bundles that fit in a time rather than sensible bundles of features that  you might actually want to consume and use. So partly you do end up with this kind of  one, we've made a product increment but it's not really what we want to go live with yet  so let's make another one and let's make another one. So I don't know who has come across this  term scrummer fall? Anyone? So there's a guy called Brad Wilson and he, I think he describes  this as the combination of scrum and waterfall to kind of the worst effect. You can see what  I mean, but it is very common in large organisations especially working on large products and you  might actually have parallel teams working on this that you have a bit of a requirements  phase and then the sprints are really seen as the development phase with a bit of testing  thrown in. So you're doing your sprints, you produce a product increment, you put it on  the shelf and then you produce another one and another one and nobody's really that interested  in the product increment you made because it's not really going to go anywhere, it's going  to be stacked up and in six months time we're going to release something. So then it means  that sometimes the testing isn't fully resourced and we don't get round to doing all of the  testing until maybe the fifth and sixth month and maybe we don't have all the people on  board the project and maybe now we're getting towards that end point and some of the people  involved in the requirements are no longer involved, they're looking at phase two. So  you get some of the classic things you would get with waterfall but you are really getting  some improvements through having a good coordination within the team. So the team is more focused  but the general product or product development is still a big lump of software that's being  built. So I don't know, I'm going to ask Sherr of Hans, has anyone seen this kind of situation?  A few people. The thing is it's not wrong and I'm not here to judge or say this is wrong,  it's just that some of the practices make less sense. Naturally the stakeholders just  feel like well I could go and I could go to the demo but on the other hand that's not  really what's going to be released. So maybe I'm too busy right now, I'll go next time  and then maybe they go to the last one and then they're going that's not what we wanted.  So you can get this kind of scrum waterfall situation. There are some other things which  are in scrum which I think teams find challenging. So one of them is burned down charts. So who  here uses burned down charts in their teams? This is often a source of confusion and mystery.  Burned down charts are supposed to make it easy for people to see what's going on but  just purely having a slopey line that's the ideal line and a sort of line that is where  we're at at the moment often doesn't communicate that to people. It's not enough information  because it doesn't kind of say where the work is. It's either things are finished or they're  not finished but you can't really tell within the team what the state of them is. So here  are a couple of pictures of burned down charts. They're just random pictures that I happen  to have on my laptop and one of them and what you'll find is that they don't look the same  for a start and you can work in organisations by different teams or using different burned  down templates and from a stakeholder point of view that's quite confusing. This bar version  has things that were added after planning and things that were removed after planning.  Now if you know about Scrum you know that you're not really supposed to do that but  it seems like this team is kind of doing it. They've adapted their burned down chart to  kind of show well this is why we're running late because we have to do other stuff instead.  So we're not really even using that sprint as a protected capsule around the development.  There's another one I found and on my laptop I had found that I'd named this crazy burned  down chart and it's because it is crazy. It doesn't actually help you know what's going  on. I think what does it tell you? It tells you somebody had too much time on their hands  to do tracking I think and I don't think it really helps to see where the work is. And  so one of the techniques you can use in Kanban is this cumulative flowchart stuff which I'm  going to come on to and that's sometimes a way to get a clear review of what's going  on. Now the other thing that is a bit of a mystical thing within Scrum is product backlog  grooming. Now product backlog grooming is really the art of going through the near items  on the product backlog and trying to understand what they are and get them clear. It's not  really requirements analysis. It's much more trying to figure out what should be in there,  what is valuable, what's the next thing we should really be working on. But people find  that it's somehow invisible work. The team is having daily Scrum meetings and they're  focusing on what we need to do today and the product backlog work kind of always takes  second place. So you end up in this situation where people kind of get towards the end of  the sprint and they're going, ah, we better get some stuff ready for the next sprint otherwise  our planning meeting is going to take for ages. So this is, but it isn't visible work  typically. If you look at the burn down chart that doesn't really tell you where you're  at with your product backlog grooming. And Kanban can help you with that. So there is  one other thing that I wanted to mention and I didn't put a slide on it just because I  thought it's contentious, which is estimating. So one of the things that I see in Scrum teams  very often is a lot of confusion about what units we're estimating in, complexity points,  ideal days, what does a point really mean? You know, people are always constantly thinking,  right, when we say one point we really mean half a day or three hours or, and then there's  a lot of discussion. There's a lot of time that the team puts in in terms of to try and  estimate their product back, to try to get these magical numbers. And yet are those numbers  that useful as an art to predicting things? So, and when you do Kanban, one of the things  that I think people are attracted to Kanban is they think, great, now we don't have to  estimate everything. And that's not necessarily true. You may still want to do estimation  and you may still need to do product backlog grooming, those kinds of activities. But there  is an illusion that people move to Kanban because they think they will get rid of planning  meetings. And I don't think that's the case. So, let me talk about Kanban now. Now, I  also want to know who here is using Kanban. Is anybody already using Kanban? Few people.  Cool. And I should say, I'm not pro Kanban or pro Scrum, I'm kind of pro sensible things  to do that work for the team. So, I'm trying to really say what's in Kanban that you might  be able to use for your organization. So, Kanban is, it's really the Japanese word  for visual signal card or something like that. I'm not, I don't speak Japanese, so I may  be entirely wrong. But to me, it's all about visualizing the work and using visualization  as a way of triggering what we need to do next. So, you need to take some care in thinking  about how we visualize it to make it something that people will respond to. Now, there are  a whole bunch of books that have been written about Kanban for software development. So,  one of these, and I guess one of the main proponents of Kanban is David Anderson. And  he's written this book, Kanban Successfully Evolutionary Change for Your Technology Business,  is his title. There are other books. There's a book about Scrumban. There's also a book  which Henrik Niburg has written. I think there are a bunch of different books, there are  a bunch of different papers. People have been really trying this approach out. But it hasn't,  I would say, it hasn't really settled into, this is what we all agree Kanban is, isn't  just the same as this still debate within the Scrum community about what's the correct  unit to use or the right way to draw a burn down chart. So, you will get conflicting opinions  within the Kanban arena, I guess. Now, what this does is it really uses two techniques  that are really from the lean product development environment, I guess. One of them is making  things visual. And the other thing is trying to focus on flow by limiting work in progress.  So working on fewer things, having shorter lists of stuff, having less inventory in the  process. So a key thing about visualizing is if we can start to really clearly see what  the flow is, we can start to get the rocks out of the way to improve the flow. If it's  too difficult to see what the steps that things go through, then it's harder to really look  at optimizing the end to end flow and people tend to do something called local optimization.  They tend to kind of say, well, let's just get the bit of flow between you and me working  rather than let's look at the end to end flow. And people are very naturally thinking about  it's very difficult to let go of what is the most efficient for me versus what is most  effective as a throughput for the system. So it's something that feels counterintuitive  because everybody feels they should just be busy all the time. But at the same time, if  you're busy, then you may be working too far ahead on stuff that you may not need. And  actually your attention might be better placed into improving the system. So one technique  that you use within Kanban is to just start making the cues of work visible. So you're  starting to make the inventory of work in the system easier to see. So this is just  a picture of wait times at Disney Park. And because it's displayed, it allows people to  make a choice. So what you're really trying to do is not just make the system cues visible  to the people working in the system, but also to the people who are making choices so that  people understand what the typical wait time to get something is. If I'm asking for a feature  and I don't really understand how long it takes between something going on the product  backlog and something actually coming out and being released, which can actually be  weeks and weeks in some organizations, then I will not be making well informed decisions.  So it's trying to make information available to help people make better decisions. And  what you're doing here, it doesn't say how many people are in the queue, it's just telling  you how long will you have to wait before you get something. And what typically you  do in Kanban systems is you move much towards cycle times. What's the date we started working  on something and the date we finished working on something, rather than thinking about points  or what points are to time, those kinds of things. You're looking at cycle times. Now  here is a picture just from a scrum team. And this is their initial steps towards Kanban.  So they are starting to make the work visible. Now I don't know if... Can you make any inferences  from this board? Anything that you would... observations you would have about it? Can  you see what's going on? Easily. It's a bit messy for a start. And actually if you're  going to get into making things visual, you have to take care that things are easy to  read, that it is clearly set up, that column headings are clear to understand. For example,  this board has a kind of a blocked area, kind of towards the top here. But it's not really  clear what's in the blocked area, where the blocked area ends or how things get in there  or how they get out of there. And if you took a closer look at these tickets, so they kind  of started with good intentions. They thought, well, what will you use something to print  out the tickets in our defect tracking system? Because that's what they're using for their  planning software. But the thing is that the program that they're using, the main thing  it prints in big, big letters or rather numbers is the reference number. So if you look closely  at this, it's just a whole, all the big bold text is some long reference number. So in  the standard meeting, people are saying, well, I'm working on issue number one, two, three,  five, six. And that's not an easy thing to communicate. The other thing that it may not  be clear from this board is there's two teams. They work, once they're both writing software  to run on internet enabled TVs for the Olympics. And the team at the bottom is using a particular  browser. The team at the top is trying to do a HTML version. But actually what you'll  see is there's a blank area in the top team. And that's because that area is ready for  test. What they're doing is they're working in one week's sprints. And then at the end,  they kind of go, put everything over ready for test. And then nothing gets tested in  that one week's sprint. And everything carries over to the next. And so they're kind of got  a, sprints are being used to build stuff but not build and test. So there's no meaningful  product increment. And actually also then, the kind of demo that they have isn't a normal  sprint review. It's kind of a management walk around where people show things working  on the TVs in their area. So again, there's no real accountability to this is what's  working and tested. It's more and more like, you know, here's some stuff. Look how cool  it is. And then, so it's not an integrated team in terms of the development and the testing.  So you need to do a little bit more than just make the work visible. You start needing to  just try and sort of focus on, let's not have too many things going on at once. So Kanban  is used in the Toyota production system. This is really going back to more lean manufacturing,  lean production. And if you go to a Toyota factory and look at the production line,  they're also used in multiple ways to control the flow. So each order for a car has a Kanban  card that goes with it, that goes through the production line with it. Also, the stock  around the different cells on the production line have their own systems of cards so that  you don't have, you know, 100 wheels, you just have a stack of 20. And then as that  gets used, you pull in another 20. So they keep the supply chain, the supply levels low  so they're not building up batches of stuff. So they don't on Monday make a batch of red  cars and on Tuesday make a batch of black cars. They have to change their paint system  so that they can make a red car, follow a black car, follow a white car. And that's really  improved the flow. So they're using Kanban to be the ticket for the order and they're  focusing on how can we improve the flow per order through the system.  Now so this is, I guess, a little bit of a sketch of something that's really a bit like  the team we were looking at before. They've got some stuff that they're about to work  on, there's the stuff that they are working on, but they don't really have anything ready  for release because they're really thinking our real release is to make something available  for the Olympics. And these mini one week sprint product increments, well they're not  going anywhere so we don't really care about them that much. So one of the things to do  is to start focusing on releasing stuff. So to have fewer things in the pipeline and actually  get that all the way released. And when you start limiting the work in process, so you're  perhaps doing less product backlog grooming now and you're now focusing on what's the  next thing to release and what's stopping us from doing that.  Now as well as having boards that visualise this flow, you can also use a technique called  cumulative flowcharts. So I don't know, is there anybody here using cumulative flowcharts  to represent what their board information is? Maybe I should also ask, is anybody using  a board that looked like that board I showed you with columns and cards on it? A few people.  Now who is not using a physical board but they're using an electronic board? Now there's  absolutely nothing wrong with using an electronic board. The same principles apply, it's just  easier and more tangible to explain it with the physical cards. And I think when you have  the limits of a physical board with physical cards on it, you start to realise that you've  got too much work in progress more quickly. When you're using an electronic system, it's  often easier to keep adding and adding and adding rows and tickets and then it starts  to be a lot of things that you're discussing when you have your daily scrum meeting.  So cumulative flowcharts, I think I see them really as being a more useful version of a  burn down chart because what you're trying to do is trying to make not just the general  trend line visible but actually the view of how many items are in each of the columns  of your board. So I'm just going to go through a few examples. So here's a very simple one  and I've just tried to keep this simple so that you can get the basic principles. So  you'll notice that the vertical axis is not points, it's not ideal days, it's number of  things. So it's just number of items in any one state which makes it quite easy to create  it because you just look at the board and go one, two, three, five, okay, and then on  the next one and you usually do this in a spreadsheet. I haven't been using planning  software to generate these, I've been using spreadsheets. This is a very simple process,  it only has three states. So it's like there's some work that's on the product backlog that  we haven't started, there's the work we're actually doing and there's the work that we've  released and what you'll see is that the green stuff is gradually increasing at a steady  rate and you can look to see how many items are in process at any time and you can look  across ways to see roughly how long does it typically take and you'd start to look at  what average cycle times are for things. It does assume that items are roughly similar  sized so that's not that you know and if you've got odd shaped items your flow will be a bit  more ragged. Now if you're doing scrum then what you'd see is really this kind of slightly  stop start, you know you release some stuff, you do another sprint, some more stuff released,  you do another sprint and if you use Kanban you're not using sprint so Kanban doesn't  have the idea of wait until the end of a time box, you really are releasing as you go. So  as soon as something is finished release then the next thing release. So it works very well  with a continuous deployment setup. Now just to illustrate what Scrummaphore would be like  if you used a cumulative flow chart you probably have a lot of different states and notice  that many weeks go by before you actually have anything ready to release. So it's you're  not generating the value, there's a long cycle time there before you get your value. Now  what these charts can help you see and what the boards can help you see are bottlenecks  in your process and bottlenecks the definition from the goal is any resource so that's a  person or a thing or a machine that their capacity is less than the demand placed on  it. Now it could be we've got six developers and one tester, that tester then becomes the  bottleneck. Now if we added six testers the bottleneck would normally move somewhere else,  it's normal in a system to have some bottlenecks and typically what people do to cope with  bottlenecks is they create some buffers in their system. So what if you know that you  have a bottleneck what you don't want to do is have a situation where that person is  waiting around not doing anything. So you just think about the classic thing you might  do in scrum where the development team is busy developing stuff and they haven't made  anything available to test and then they say oh right the last day of the sprint is everything  to test, that person really can't then cope. You want to level the workload and have some  buffers they've got some stuff ready to test that they can pull through the system. So  what you start doing when you're using Kanban is you first of all have some basic columns  and then as you start to understand your workflow better you start introducing some buffers  to try and smooth out the flow so you get a better throughput. Now yes. Yes, yes, yes,  I'm coming to that. So I'm not yet talking about how you start doing it. I'm just trying  to explain roughly what Kanban is and then what other steps that you would take. So yes,  I agree with you. Yes. Any other questions just before I move on? Yes.  Yes. Yes. Yes. Yes. So that's an interesting thing is that Kanban is a technique from  a production line. Knowledge work isn't a production line. You're creating unique things  every time and actually in software development the items are very much different sized. You  can get something very, very small like change some text on a page or you know, great build  this new component or you know, improve this performance and reliability of the system.  They kind of different sized items and so one of the challenges really is that Kanban  works best for similar sized items. So typically what teams might do is have columns where  you're trying to break those down. So visualizing that product backlog grooming activity so  that you're breaking things down into similar sized features so that then you can start  to use this kind of flow based approach. Yes. Yes. I think that's actually a challenge  for Kanban. So for instance, non-functional requirements or quality attributes, they are  things that you have to be checking all the time rather than you can't say, oh well we've  done the architecture because you keep changing it. So to some extent or you know, you can't  say sprint one, we've delivered performance because you're going to keep having to keep  checking that it's keeping to a level performance. So I agree. But I think that's an issue with  both Kanban and Kanban. You have to figure out a way to do that and being clear about  the measures that you have and the way that you're going to inspect for those measures  is part of the answer. So I'm going to move on a little bit now. So this cumulative flow  charts, I showed you some kind of ideal ones which are a little bit smoother. Typically  what you start to see is that these bands start to expand where there's somebody who's  blocked and waiting. And so what people start doing in a Kanban system is they introduce  these whip limits. Whip is short for work in progress. And so what you're trying to  do is impose a limit of how many things can be at a particular state. And what you're  doing is that the way you operate those limits is that supposing you are a developer and you  see that there are three things that are already in development, if one of them gets blocked,  you can't start another one. You have to try and figure out how to unblock the thing that  is blocked or go to help somebody else where there is a further upstream activity that,  downstream activity that needs to flow through. So I've got some text to write that out because  I think sometimes that gets confusing. So how do we operate whip limits? This is some  text from David Joyce who's been running some Kanban teams at the BBC. So the limit governs  the maximum number of work items that can be in any state at any instant. And if I haven't  reached the limit, I can pull more work in. I can start doing some more stuff. But if  I've hit my limit, then you can't start working on some more stuff and you actually have to  either wait, focus on process improvement stuff, or try to help unblock the system.  And that really relies on team communication. And it isn't helpful if everybody tries to  help too much, if you see what I mean. So if you probably want to in your team kind  of go, oh, we're blocked on this, right? So maybe you and you, we're going to work to  try and block it. And you and you, let's try and look, do some look ahead work and perhaps  not focus on the making more stuff. What we're doing instead is we're thinking about how  we can improve things, maybe looking at tools, ways of, you know, improving the way that  we work. Now, this is kind of a very ideal picture. But really, this is where you've  got quite narrow work in progress limits. And what you'll see is that the flow of items  is happening more that you're getting things out of the system very soon. So almost as  soon as you finish something, it's going live, soon as you finish that something, and you're  just focusing really on keeping that cycle as short as you can. Now, I'm going to flip  into talking about how you might get started with Kanban. So the very first thing I think  is you start with a technique which is called value stream mapping. Now, to formally do  value stream mapping, as in the kind of leading textbooks, you really try to follow the work  and use examples and look at how specific pieces of work, how long they actually take,  where do they wait around. So if you imagine, you might write a requirements document, and  then it might be waiting to be signed off, and you might have to wait for the steering  committee to get together and then wait for a team to be formed, and there could be all  of these different steps. Now, it's helpful to do these practical examples where you actually  follow a piece of work and look at how long it really takes to get through, but often  in terms of setting up a board for a team to use, you may be better off to start just  sketching out what is it we think our workflow is, and so what happens in this picture? There  is a little stick person, and he's starting to create a book of work. So he's working  in a bank, and he gets traders asking him for stuff, and sometimes he says to the traders,  no, and other times he says, oh yeah, that sounds like a good idea, yeah, let's put that  in our book of work, and so that's your first cue of work starting to form. And then you  start working with the team to figure out what would it take to do these things. Then  needs to be a bit of analysis to understand what the impact is, where the piece of work  will have to be done in the banking system, so you're doing some of the sort of analysis  work, and so then what you're doing in this team is really discussing what is the flow  of items, and this team, so I mentioned about estimating, this team do choose to do estimating,  they say, well, we want to do some t-shirt sizing just so we can decide, like if something  is too big, we might need to actually have some meetings to break it down. They also  started at the, I don't know if you can quite see, but at the bottom here, they start having  some definitions of done around the columns, but not a definition of done at the very end,  but is this ready for us to move forward to the next? And then there are some little buffers  starting to appear. Now, this is just what it looks like, it's a sketch, it's what they  think they might do, it's a future sketch, it's an illustration, it's not a precise  process definition, but it helps to have that conversation and start talking about what  the process is, what the states that the work goes through, and where does it wait around.  But practically, the team is only going to know how does this system work when they start  operating it. So this initial thing, get the sketch done, then try it out. So step two,  the team is now based on their whiteboard sketch, they've started to make a board design.  They have some names at the tops of the columns, they haven't put their whip limits on yet,  and that's partly because they want to get used to this new way of working. So, but notice  that they have really tried to make it easy to read, make it clean and tidy, they've got  super sticky post-it notes that won't fall off, they have, you can't quite see it, but  they have some magnets that they have bought to represent team members, they haven't put  those on yet, and they've started, those definitions have done that they had, they printed them  out and they put them at the bottom of the columns. Now, that's, this is a board of just  representing where's our work at the moment, then they start using it. And in Canman, you  typically do have a daily standard meeting, but what you do in your daily standard meeting  is you are looking to see, is the board representing work at the moment? Are there blockers that  are not being dealt with? Do we have any bottlenecks? Is anybody kind of blocked or too busy?  And you're typically, and this is different than a SCRAM standard meeting, you're focusing,  you tend to focus from the, I'm just trying to think of how this looks to you, from the  done column end first, you're looking back to say, pull the items this way, you're not  stuffing more things in, so it's a pull system. So, you're typically, when you're looking  at the work, you're not looking at what's the next thing that we should work on, you're  more normally thinking what's blocked that needs to be moved forward. And you tend to  run this meeting, looking at, talking about the work, not a person by person. So, it's  not driving out this kind of commitment, you know, what did you do today? It's much more  saying where is this piece of work? And if you're not working on any of those things  on the board, then you might not actually say anything. So, you're really trying to  shift this into, does the board represent what we're doing, and do we need, does the  board tell us that we need to do something different? Now, as you start doing that for  a while, you can start to get a sense of what would be sensible whip limits for us to try.  Again, this is our initial whip limits, we may need to reflect and add more columns,  we may need to change our whip limits. But, I think, I'd be right in saying that David  Anderson normally recommends start with high whip limits and then gradually tighten them.  So, if you've just got a whip limit of one thing per person and then one thing gets blocked,  you're running into blocked quite soon, so you might want to have slightly more relaxed  limits to allow people to have something to do. So, now, this is the team after they've  been going for a few weeks, and if you look, you can see that there's too much stuff on  the board, and they haven't really been following the whip limits. So, this is a team that's  still learning, and this is what you're trying to do with the whip limits is to become more  aware of when you exceed them. The way that they've designed their board makes it quite  easy for you to put another post-it note in, because, so you can see how many post-it  notes are crammed into the prioritised backlog column, there's too many things there. One  technique that I've seen teams use is actually design your board so there are literally only  spaces for the amount of tickets that you're allowed to have, and then put a kind of a  cross thing so that you can't, you're very conscious, oh no, look, we're going past  our limit. So, you may want to think about that, but more crucially, what this prompts  is we need to reflect on what's going on. So, this is a picture from a retrospective,  and it is a picture of a cake that is shaped like a bug, and it has a number on it, which  is 1133. This bug took many weeks for the team to sort out, and somebody in the team  made a cake like the bug, and they ate the bug, but they also used it as a way to celebrate  we've killed that bug, but how did it really happen? Why did it take us in this direction?  Why was this so difficult for us to fix? A lot of that came down to not having the knowledge  in the team, and they needed to expand their understanding of the other systems. This was  a, something that was very difficult to replicate, that was happening in one of the databases,  and it was difficult enough to replicate, and really, really difficult to figure out  what was going on. But it was worth having a retrospective literally just about that  thing. And what you want the team to do is to become more responsive to noticing what's  happening, what's slowing them down, and thinking, how do we make sure that doesn't happen again?  So, yes?  Yes?  So, that hasn't, it just hasn't been my experience that that's happened, but I can imagine it  might happen, and if that is happening, it might be an indication there's too much stuff  in going on. If you're finding that the meeting is kind of getting bloated, that's possibly  too many things to discuss, we probably are trying to do too many things at once. So,  my reaction would be maybe to, to kind of do less, have fewer blockers, and then have  a smaller focus. Now, a question that a lot of people worry about when they're moving  towards this approach is they worry about where do all our meetings go. So, I mentioned  retrospectives. Now, normally in Scrum, we have those at the end of the sprint, and you  know, like you have your release, or you should have your release at the end of the sprint.  And so, in Scrum, the meetings are pinned to the time box, and the release is pinned  to the time box. And what you're trying to figure out when you move to a Kanban approach  is really, what's the real frequency that in your organisation, how often does it make  sense to get stakeholders together, how much does it make sense to get the team together,  do you need to have some meetings or some events that are triggered by hitting a limit.  So, there are, when people move to use, when teams move to using Kanban, they're not throwing  everything away. It's just they're starting to realise that they don't all have to be  kind of bolted to this cycle, that you can have different frequencies for different things.  So it's not that, you know, retrospectives disappear or go away. Now, I'm getting towards  the end of the time, and I want to now take the other point of view and kind of say, well,  okay, so what are the good things in Scrum that we might lose and, you know, what would  we want to be careful about? So, you don't want to throw the baby out with the bathwater.  I don't know if you have that saying in Norway, what are we doing in the UK. So, I have come  across teams that have been trying to use Kanban, and things are not good. And I have  actually been in environments where we have gone back to using Scrum. Now, the kinds of  things that were happening for that to be a thing that we decided to do was, and this  is with a particular organisation, they were making a news portal, and they had, they'd  just been making features as people suggested them. They had lots of features. It had kind  of got into this business as usual mode, you know, somebody comes up with an idea, you  just build it and release it. And it felt as if the team really didn't know where they  were going or what they were working towards. They were, it just seemed like anyone could  ask for anything. And so, there was this, and this is something that can happen to Scrum  teams as well. It's like you just, you can't see the view outside the sprint. You can't  see the big picture. You can't see the roadmap or the where are we going view. And if you  can't see that, then it can feel demotivating. It can feel like, you know, I made, you couldn't,  and I've experienced this on XP teams as well, is that we just release features and we release  features and we're an effective team, but it feels like there's nothing big to celebrate.  We're just doing lots of small releases of stuff, and we don't really know where we're  going. And you can lose this sense of what is the product we're making or what's the  big release plan, you know, where's our product going. So, sometimes, and especially if teams,  and I've seen this where a whole bunch of people have joined an organisation and they've  just kind of gone along with what's happening. So, there's a big Kanban board and they have  a stand-up meeting and then they kind of go away and they don't really know what anybody  else is doing. There has been a lack of the meeting coherence because if you think about  it, one of the things that Scrum does is it gives, it helps the team establish a goal  which binds the team together. If you have a big mass of people and it's not very clear  what the goal is, you can end up with factions and with people not getting on as a team.  So, that's something to watch out for really is that people are starting to just feel like  a cog in a big machine and they're not really feeling accountability, they're losing, it's  that big team effect that you end up having. So, I don't know, does anyone recognise what  I'm talking about this kind of effect? So, what I've found is actually it can be helpful  to get back to basics sometimes. Sometimes it does help to say, right, this is a product  we're working on, this is the small team who are working on it, we're going to work very  closely with the product owner, we're going to have sprints. But the key thing is if you  can do Scrum but do the product increments, has serious product increments and not get  into this Scrummerful situation where it becomes this long waterfall Scrum in the middle  kind of situation. And I think sometimes when people are new to our job, you get people  who are joining an organisation and maybe they said, oh yeah, I did Scrum in my last  organisation but maybe they didn't really. And you can get people who are kind of passengers  with the process and they don't really feel engaged with it and sometimes it helps to  just bring it back to a much simpler, more rule based thing while people are learning.  And then once they start to understand how things work, then increase the flexibility  for changing stuff and move more towards a Kanban way of doing things. Now, I think  I'm slightly early in the timings, I think maybe we've got five minutes left for questions,  so have you got any questions? Any questions?  Yes. Yes.  So you can, well, so you can have a way that I've seen people do, they have like a ticket  which represents the user story and then they have like a little tail of tickets which represent  the tasks but they are small, you know, they use a mini post-it note things to have a few  tasks. That, you have to really ask yourself why are you doing that and you wouldn't necessarily  do as you do with sprint planning a session where you say, let's work out all the tasks  for the sprint. You're much more, oh, we're about to start this item, let's figure out  the task because then we can work out how to share that work out across the team. So  you might have that as a triggered thing that you do as you take a ticket into starting  to work on it and obviously you wouldn't do tasks for the ones that are small and kind  of obvious. Does that make sense?  Yes.  Yes. Yes. And actually a classic thing people don't show, for instance, is testing tasks.  So people kind of go, here's the development task and then we have a column for testing  and we don't actually then unpack to say what are the testing tasks. So it very much comes  down to the skills of the team and you have to think about when you're creating tickets,  what are you really trying to represent, what's your communication, what communications  that facilitate. Now, all I would say is that Kanban leaves it open as this is a toolset  that you're using. So it's up to you whether that's useful for you to have a triggered  event like every time we take a new ticket we do that unpacking into tasks or do we  say use the task to represent the workflow so we have columns for them. But it's not  something basically Kanban is much lighter and less processed than Scram. And Scram is  pretty light. So it's even less. So one of the things that Kanban doesn't have, for  example, is roles and it doesn't have any prescribed events. All it's saying is make  things visible and limit the work in progress and then reflect on what you see. Try to look  to improve your cycle times. And that then leaves it open to try all sorts of different  experiments to try and improve your cycle times. Any other questions? Oh, sorry. The  question was, and I might not word this question exactly now because it's been a few moments,  but it was if you, so you were saying that there are user stories and sometimes the different  sizes and sometimes you might want to do a task breakdown. So would you do that in Kanban  or not? And you could if you wanted to, but you might not. And I think the other part was  that sometimes some of these tasks when you break down an item are actually items in work,  they're kind of activities in your workflow. So it might be that you don't have a task  representing it because you now have a column representing it. So I don't know, was that  a fair representation of your question? Okay. Any other questions? Yes.  So I think it very much depends on how you establish them at this cadence of meetings.  You clearly want this to be, you have some business people involved, but at the same  time you want don't want everybody at all of those stand-up meetings necessarily, you  may want key representative, key representatives, you might do something a bit like the product  owner kind of pattern in Scrum, but you might not. One of the things you might decide to  do is to have, you know, showcase events where you have everybody in the department goes  to see those. So there's a bigger showcase. You might have a smaller group responsible  for prioritization and it may be that two or three of those people are really sitting  with the team actively being part of that system. I think anywhere where you have separation,  where you have the people apart from the people, you know, so if what you don't really want  is for the columns on the Kanban board to be like departments who don't, you know, who  only talk through tickets. So, and then I'm just really remembering that I didn't repeat  your question. So your question for the people who may not have known is what, how do you  involve the business side in Kanban? Any other questions? Yes.  How do you assure that the items have the same size?  So you can't and it's through the team kind of going, and yes, you could imagine you've  got some item. So the question is how can you assure that the items are the same size?  If you get a very big item, it's going to block the pipeline up and it's going to have  a long cycle time. It might be that that's a useful thing to release. And so you don't  necessarily have to have things that are all the same. But it's just that if you are trying  to make predictions about things based on your average cycle time, it helps to have things  that are more or less the same size. But you don't, you're not trying to force things  to be the same size. Yes.  Well so if you had, just imagine, you had a very big item, it would just be in process  for much longer. It's not, you're not exceeding your limit by putting a big thing in. It just  slows things down. So it's just, that's going to start, people are going, you want to encourage  people to reflect on that. It can vary. And it typically does vary. It's just that you  don't want it to be very great. Yeah, you would want, in an ideal world, you're trying  to break down the items to sort of similar size-ish things. But it may be that if you  are really trying to release, you've come up with a minimal marketable feature that you  think, right, this is the thing that we want to put live, it may make sense to do a bigger  blob of work. There was, now I'm just thinking, my time is probably up. I don't know who was  going to remind me about 10 minutes. Did you remind me about 10 minutes? I didn't see you.  So I guess if there's any other questions then please come and see me afterwards. But  otherwise, thank you.
Rachel_davies_moving_from_scrum_to_kanban_0_923.png Rachel_davies_moving_from_scrum_to_kanban_924_1475.png Rachel_davies_moving_from_scrum_to_kanban_1476_1535.png Rachel_davies_moving_from_scrum_to_kanban_1536_2423.png Rachel_davies_moving_from_scrum_to_kanban_2424_3059.png Rachel_davies_moving_from_scrum_to_kanban_3060_4055.png Rachel_davies_moving_from_scrum_to_kanban_4056_4355.png Rachel_davies_moving_from_scrum_to_kanban_4356_4859.png Rachel_davies_moving_from_scrum_to_kanban_4860_4907.png Rachel_davies_moving_from_scrum_to_kanban_4908_5303.png Rachel_davies_moving_from_scrum_to_kanban_5304_5627.png Rachel_davies_moving_from_scrum_to_kanban_5628_6227.png Rachel_davies_moving_from_scrum_to_kanban_6228_7127.png Rachel_davies_moving_from_scrum_to_kanban_7128_7991.png Rachel_davies_moving_from_scrum_to_kanban_7992_8219.png Rachel_davies_moving_from_scrum_to_kanban_8220_10031.png Rachel_davies_moving_from_scrum_to_kanban_10032_13451.png Rachel_davies_moving_from_scrum_to_kanban_13452_13511.png Rachel_davies_moving_from_scrum_to_kanban_13512_13559.png Rachel_davies_moving_from_scrum_to_kanban_13560_13607.png Rachel_davies_moving_from_scrum_to_kanban_13608_13955.png Rachel_davies_moving_from_scrum_to_kanban_13956_14603.png Rachel_davies_moving_from_scrum_to_kanban_14604_15911.png Rachel_davies_moving_from_scrum_to_kanban_15912_16343.png Rachel_davies_moving_from_scrum_to_kanban_16344_16883.png Rachel_davies_moving_from_scrum_to_kanban_16884_18599.png Rachel_davies_moving_from_scrum_to_kanban_18600_18683.png Rachel_davies_moving_from_scrum_to_kanban_18684_20711.png Rachel_davies_moving_from_scrum_to_kanban_20712_22247.png Rachel_davies_moving_from_scrum_to_kanban_22248_24503.png Rachel_davies_moving_from_scrum_to_kanban_24504_26255.png Rachel_davies_moving_from_scrum_to_kanban_26256_28703.png Rachel_davies_moving_from_scrum_to_kanban_28704_33767.png Rachel_davies_moving_from_scrum_to_kanban_33768_35735.png Rachel_davies_moving_from_scrum_to_kanban_35736_36839.png Rachel_davies_moving_from_scrum_to_kanban_36840_37283.png Rachel_davies_moving_from_scrum_to_kanban_37284_37559.png Rachel_davies_moving_from_scrum_to_kanban_37560_38507.png Rachel_davies_moving_from_scrum_to_kanban_38508_38663.png Rachel_davies_moving_from_scrum_to_kanban_38664_39059.png Rachel_davies_moving_from_scrum_to_kanban_39060_39431.png Rachel_davies_moving_from_scrum_to_kanban_39432_39731.png Rachel_davies_moving_from_scrum_to_kanban_39732_41759.png Rachel_davies_moving_from_scrum_to_kanban_41760_42611.png Rachel_davies_moving_from_scrum_to_kanban_42612_43163.png Rachel_davies_moving_from_scrum_to_kanban_43164_43415.png Rachel_davies_moving_from_scrum_to_kanban_43416_44351.png Rachel_davies_moving_from_scrum_to_kanban_44352_49895.png Rachel_davies_moving_from_scrum_to_kanban_49896_50387.png Rachel_davies_moving_from_scrum_to_kanban_50388_51671.png Rachel_davies_moving_from_scrum_to_kanban_51672_53687.png Rachel_davies_moving_from_scrum_to_kanban_53688_54371.png Rachel_davies_moving_from_scrum_to_kanban_54372_54431.png Rachel_davies_moving_from_scrum_to_kanban_54432_54551.png Rachel_davies_moving_from_scrum_to_kanban_54552_54611.png Rachel_davies_moving_from_scrum_to_kanban_54612_59207.png Rachel_davies_moving_from_scrum_to_kanban_59208_60599.png Rachel_davies_moving_from_scrum_to_kanban_60600_62747.png Rachel_davies_moving_from_scrum_to_kanban_62748_63887.png Rachel_davies_moving_from_scrum_to_kanban_63888_65579.png Rachel_davies_moving_from_scrum_to_kanban_65580_67523.png Rachel_davies_moving_from_scrum_to_kanban_67524_69611.png Rachel_davies_moving_from_scrum_to_kanban_69612_70859.png Rachel_davies_moving_from_scrum_to_kanban_70860_71519.png Rachel_davies_moving_from_scrum_to_kanban_71520_75851.png Rachel_davies_moving_from_scrum_to_kanban_75852_77723.png Rachel_davies_moving_from_scrum_to_kanban_77724_89429.png