Mapping a Value Stream to a Kanban Board

so what we're gonna do here is we're gonna explain how you convert a value stream map into a Kanban board but kind of why as well and how you relate that to now I imagine not everybody listening to this knows what a value stream map is so I want to actually start with the right way or a way of building a value stream now and basically when you do a value stream map the intention is just to map the way you're doing it now not to try to improve it while you're mapping it but map it first then you can study the map the flow and see how you might improve it and all the value stream map does really is give a graphical representation of how you go from when you start an idea until you actually get it completed in this case we're gonna start with a software where we get a request and we deploy it and as you can see in the slide we've got the different steps laid out so this is the actual very first step is you go from basically a customer request until you can deploy it to a customer so value stir map should always be customer to customer in this regard so we've listed that in this value stream that we're mapping that there's a request approval requirement sign-off etc until deployments first step fairly straightforward but then we want to look at how much time do each of these steps take and our first way of looking at it is the calendar time so in this example we have like the approval takes a day so we're gonna use eight hours a day 40 hours a week is the way we do this the request just kind of comes in so that takes just a half an hour to log it things of that nature so each of the steps we kind of think of what is the calendar time but we don't want to stop here with this time because one of the things about lean is that suggested we look at how much time you spend working on something versus how much time we actually are kind of involved in it like that hundred and sixty hours interest in doing requirements we may have been working on average only like sixty of those hundred and sixty hours and we took an average because we kind of really are interested in also how much the later is so this means that however many people we had they spent sixty hours on average working on it and a hundred hours working on something else this is a little more dramatic and say the code where we had eighty hours or two weeks of work over seven weeks of work now part of the reason this is important is we have to remember Valley Stream Memphis for a particular piece of work so although the coders may have been very busy working on lots and lots of things this represents that probably the coders were working on maybe three or four projects at a time so they only spent 80 hours on this one they spent another couple hundred hours on other projects in overhead time and things like that so from a time perspective we had a fair amount of delay and that's the idea we're trying to see how much we're working as a percentage of the time how much something are we actually working as a percentage of the time you're spending on the project we don't just have times when we work in other words in the code where we had seven weeks of coding of two weeks of actual coding on those seven weeks there was also waiting time in between the different steps for example here we had a request but then it sat around for eight weeks until it got approved and then it set around for two weeks until we started requirements why because people were busy on a lot of things see what we're trying to do in lean is not just like to see how busy people are but we're trying to actually see how are they working on one thing we're trying to see how the flow of their work is over one piece of work so anyway we've got now the amount of calendar time spent the amount of waiting time between the steps so we've also got inside the box the amount of actual time spent on a per person basis there's still actually one other thing we need to calculate sometimes we have rework like after review or testing we might find we made a mistake and we've got to go and you know recalculate that now if you think this is a flow chart it kind of is it's not a bad way to think about it but it's not a flow chart of action as much as it's a flow chart of time timing is really what's important we put the labels up there because we just want to see what the time is of the steps but we're really interested in the time so we want to calculate what's called the process cycle efficiency basically the percentage of time I'm working and in this case it's 14.9% this isn't that unusual time I've seen it as low as point one I've seen it a size about point five point six or rather I'm sorry point one or fifty to sixty percent it's the size that in agile projects it tends to be a little higher because you're kind of swarming things anyway the way this is calculated is we take those times where we're working and that becomes this average time work as you can see and we also take the times waiting which is the time in between the steps we're not just waiting time but the actual calendar time excuse me so that's like 3400 hours and that's the total cycle time cycle time being from request to deployment now there's an interesting observation before I actually show the map now we have a value stream map and that observation is basically to ask where are you going to get a better return is it going to be getting better of what you do you know like can a code faster can ID bug faster can I do requirements faster or perhaps eliminating delays between what you do so this is actually kind of an interesting observation if you look at that 3400 hours and you ask yourself that represents about a year and 3/4 what would happen if we drop that down to 2,000 what would happen to the 509 hours would it go up would it stay the same or what it'd go down most people agree it would either stay the same or go down and why is that well just consider one example if the time between code and test went down but you still spent the same 80 over to 84 code or 40 over to 44 test you shortened that cycle coders after they actually wrote the code and we're told of errors they probably remember what they did better and therefore would solve the problem was faster and I think this is true in general the longer things are between when you're making air until you find the error the more time it takes to fix it because you've kind of kind of have to recover that information in your mind also requirements can decay and therefore take longer so one of the interesting things about lean is it suggests instead of working on how to improve the time actually work now we're not saying this isn't a good thing to do but we're saying it's actually more productive to look at the delays the times are actually just spending calendar time and delays between things that trying to shore these hours is actually a lot better a lot more productive so when we have a Kanban board this is one of the reasons we want to have not just where the work is we want to have waiting times in between where the work is for example between requirement sign off we have 320 hours so how do we do this well Kanban is going to suggest that you want to eliminate delays and manage your work in progress that's what wit means work in progress and that you should get an improvement in quality and lowering cost by doing this so how do we take this map and put it in a Kanban board well let's take this step by step and show you how so the first thing here I had is the request which is kind of in this case outside of the system and that comes in so I'm going to take these first two and say this is the very first column this is where I'm waiting for approval I'm not the the requests coming in is goes into the waiting for approval so fast it's really not worth having a thing on the board for that because it's just kind of in would immediately be in the waiting for approval and I'm putting this under the product managers because this is actually part of this process of trying to actually you know get this thing approved so the next step is the approval so I have working on the approval and then that the life step in between is basically when I'm ready for requirements I'm just kind of in the value stream map I'm just kind of waiting but here we need to put a sticky or a card to show that so then the requirements would be well I'm working on requirements and then the delay after that would be I'm ready for sign-off then I have the sign-off itself which is fairly short but I'll have it up there and then I can continue to go through the rest of the value stream out by just you know save time I'm not going to go through every single step but it's the same thing I've been doing now you may have noticed these numbers on the bottom they're just there for reference so don't worry about I'm just adamant I ham in there because I want to talk about how does time on a value stream map relate to pink stickies on a Kanban board so imagine we're gonna put now stickies what we would actually do is put stickies on the board and we would do this by where the work was actually at the time we do this mapping in other words if you've done this at the beginning of a project everything of course there would be anything on the board but let's say we actually have a lot of work taking place right now then we could just say well what's in play now and what column does it go on and we would map these stickies and what we should expect to happen is if we've got like 320 hours in waiting for approval that's it I might have a lot of stickies there because there's a long wait you know but yeah well we have something waiting for approval that's like takes a day I might not have anything in there because it's just kind of once we have the meeting there's nothing in there it's just immediately goes to ready for requirements but we'll have less there because it's only got a two-week wait and basically this is how the rest of the board gets populated you'll see this again you're populating what you actually have I'm suggesting if you've had a value stream map with a lot of time in it you'll see that you have a lot of stickies in those columns so you really map to what you really have but I think you'll see this relationship in other words long delays between steps will translate typically into a lot of work waiting between those steps that's just kind of make sense it's like you know if you go into a queue yourself as you're waiting on lines like in airport security if I says all airport security man it took it took an hour to get through that well you can imagine it took an hour to get through that because there are a lot of people waiting in line ahead of you if I say in airport security it was a breeze it only took me two minutes to get through well that's probably because there were just a couple people ahead of you so it's the same thing here and what we've seen then is that in in in a value stream map lean-to suggesting you limit the time between steps Conrad is actually saying the same thing but instead of time in a belt like you see in a value stream map Kanban do you have the size of the queue so it says limit the number of items being worked on any step by managing your work-in-progress so how do you do that well one way is you could of course add extra resources where you're kind of bottleneck but this is an expensive way of doing it are there other ways you can do it well maybe you can manage your people you know manage them so they can help each other out things of that nature maybe when people are working and they're not really busy people who are like who are working but are not the kind of constraining person then maybe you can have them help others you know it's hard sometimes to do this because even though you'd like to have people who can do everything that's not always possible you know we like to have two cross-functional teams and when you can but sometimes skill sets make that impossible for example if you've got someone who does stress test analysis for an airplane I mean know if you these people they have a PhD in eight years experience that sometimes difficult or some people know certain domain knowledge which can also be difficult to to replicate or even some of the toughest is if you were around ten years ago when this legacy system you know I have was written I don't know any way to reproduce that unless you can get a time machine go back ten years go through the process again so of course I'm kidding so sometimes it's literally impossible to have the everybody be able to do everything so if some person is blocked because they're overwhelmed then you've got to you've got to ask how to do that so just adding people or managing people doesn't always do it but a third way is actually to improve the process that might be in other way so let's take a look at the example we had before we had we're test was one of the bottlenecks and in this case I'm showing the board that actually shows where I've got a test fly and I'd ask myself well how can I improve that I could hire more testers but in this case we actually took a different approach we said very often there's a long delay between code and test because there hasn't been the acceptance test specification made early on acceptance test test-driven development is a very useful thing we actually have webinars and and articles on this in on our website under net objectives calm we also have a chapter on in our book lean agile software development achieving Enterprise agility but we do suggest that you could say let's change your process let's actually make our test specification in other words answer the question how we know we've done this before we start our design so we've introduced these two new columns here this is important we're not following the board the board is rather a reflection of how he does think our work should be done so we've had a conversation that we think our work should be done better if we write acceptance test definitions so we've actually said oh well let's have the board reflect that and that's what we've done here and hopefully doing that you would see things smooth out now I'm not saying that will always happen or but but this is the idea the board reflects the best way you know how to do your work then you the board is used to manage the work but if you get a better idea you just change the board to reflect a better idea for more information you could go to net objectives comm and register for our site this will get you a couple newsletters a month but we never sell the mailing list and this will announce new lightning webinars like this one so I hope you've enjoyed this and would like to know of others as they become available it also gives you a lot of access to our resources page which has literally days of information on it if you register if you want to contact me please do so there's my email address and my Twitter tag thanks for watching this lightning webinar brought to you by net objectives we're committed to helping our clients with effective business driven software development methods so they can be more successful please let us know how we could help you visit us at

Channel: Net Objectives Thoughts

Views: 100,555

Rating: 4.9052134 out of 5

Keywords: Lean, Agile, Kanban, Value stream, Shalloway, NetObjectives, visual control, Scrum, TDD

Id: LejHPwrqGvE

Length: 14min 15sec (855 seconds)

Published: Wed Mar 09 2011