 It's after lunch. I know you all want to fall asleep. This is the worst time to be a presenter So you're going to have to give me a little bit of slack and try and stay awake As part of that, this is going to be an interactive workshop Now what most of you probably didn't expect is that I'm actually going to be asking you to do some mathematics through this course So your brains need to be activated. I need you to think. I need to be able to do a basic arithmetic But it is coming be aware. Those of you sitting on tables of one who are actually participating, please move into another table. We're going to be doing this in groups. This is a workshop I will try and limit my rambling to a minimum as possible so Let's start with a fairly quick show of hands. Who here is using Kanban? About half of you, okay? Of the people who didn't put your hands up. How many of you know what Kanban is? Not too bad. All right How many here has you don't really know what Kanban is? You've never used it You're here to learn from the very beginning. A few of you, okay? So For those of you who are starting from the very beginning, I am going to go very quickly So if you have questions about some of the core principles and some of the core ideas Which I'm over looking and you're unsure, just pick your hands up interrupt me And I'll be happy to like go into a little bit more detail and address some of those issues All right. Now this talk is a little bit different to the majority of Kanban talk. Can we be a bit louder? So this is going to be a little different to the usual Kanban talks that you've probably heard I'm actually not going to talk about Kanban until towards the very end Why? Because Kanban itself is a tool for visualizing and tracking flow But what is your flow? What is the process flow that you're undertaking going through? Now each organization, every division department in the organization Interacts with hundreds of processes on a daily basis. Each one of these processes, each one of these Ways of working is in itself what we call a value stream It's called a value stream because at the end of the process You have created something that creates value for the organization. If it doesn't create value Then you probably shouldn't be doing it in the first place Does that make sense? So that's the value stream in the value stream map Now the second part which you need to understand is when you are creating those values changing and defining these process flows We're only really interested in Common processes. If you do something once It's not repeatable. There's no points in tracking or visualizing it These are these are activities that you do over and over again Another thing to note for those of you who are a little bit more pedantic This is a model. This is an abstraction of reality You cannot and it is impossible to fully define a reality-based process Process of reality is by its very nature chaotic Business by its very nature is chaotic things occur which outside your control the value stream map is defining the flow in an existing Baseline process and abstraction and a and a simplification of reality Remember that do not expect that you're going to do every little choice and option in different way in terms of the modeling Makes sense All right, so with those caveats Who am I for those of you who haven't met me yet? My name is Evan Laborn I currently am based out of Singapore, but originally come from Australia So I'm particularly happy with the cricket scores from yesterday So to be honest, I was expecting to be not let into the country But apparently you guys are fairly forgiving about that sort of thing My speciality is about agile outside it. I take agile businesses I take it functions and I improve the interfaces to HR to finance and To the extent where I like to take a finance division a HR division of sales and marketing division and turn it into an agile organization That's me. That's the sort of stuff. I do and you probably don't care. So I won't go into much detail What you do care about is this All right, who knows what this is seven principles Lean yes, who here has heard of the agile manifesto, please tell me it's more than half of you You're at an agile conference. You should know the agile manifesto. These are some more principles Okay, agile and lean like that principle. These are value statements that tell you why we're doing the work that we're doing Have a read of the Understand them. This is what Kanban and lean Is built upon this is the predication of how it all works If you can understand these core principles, then you're half of the way to actually understanding why we're working the way We're doing now. This isn't to talk about values. This isn't to talk about principles So you can read you can understand them as best you can Where the principles apply? I will call those out, but just be aware of what they are and how they work This is a value stream map This is a value. Can you tell me what this value stream map is for? manufacturing no, it's not a manufacturing a Value stream a value stream map is for optimizing the flow. Yes, but what is this value stream map for? What kind of software development? Waterfall software development. I've used an agile lean process a value stream map to define a waterfall process Why because we can any repeatable process that has a value at the end of it Which they all should is a candidate for a value stream map So let's talk about some of them primary components of the value stream map and what you're seeing Okay This is the input a Request comes in and says this is what we're trying to do. Okay. It's a wish list in a project sense This is the output. We're producing something of value to our users These boxes here These are our states. These are the activities that a process a System will go through in order to deliver value every single every single one of those boxes adds value to the process If it doesn't add value to the process It is a candidate for removal as in get rid of the process step all together Who can tell me what this is value at a time. Do you said duration? Someone said duration. Congratulations. It is duration. This is not efforts. This is duration Okay, these are time-based measures. These are averages where you have a process that has a Deviation of absolutely massive deviation from process to process. It can be very hard to define a lot of this information We're really looking this kind of map is really looking at consistent processes where the deviation is plus or minus 50 percent rather than plus or minus a thousand percent But what about this here? Who said waste? That's it. That's the word you want. It's called non-value add time. It's time spent in between process steps Okay, value add time plus non-value add time equals total time Does that make sense? This is this is fairly simple basic stuff. I want you to understand it any questions about this Good now there's one other piece of information in here This your efficiency and your throughput Now efficiency is not necessarily what you think it is And it's not necessarily something that you want to have a very high efficiency There are cases and I will explain this a bit later where a low efficiency is actually better more beneficial And I will explain that a bit later in the course But efficiency is very simple and this is where I said you're gonna have to do some mathematics in this course But the efficiency is the value add time divided by the total time Yep So requirements so in this process, okay? Let me talk you through this specific process a business unit raises a request it goes into a wish list It takes them a day to raise that request It then takes about six months for this For the business analyst realistically to pick that object off the wish list and begin analyzing it It goes through a funding process that funding process looks at are we actually going to fund this? Yes, we are if we're not we kick out of the value stream because it's not going to proceed Okay, it takes about a month from being funded to the requirements being started Requirements analysis in this case once again be talking waterfall takes about six weeks in those six weeks You provide a solution build summary of a couple of hundred pages it then takes six months from Writing the SPS to getting the developers or getting the contract with the offshore team to actually write the code Development and testing takes about three months a two month waiting period where we were waiting for a release window in your production environment Where it goes into or to your staging environment It goes to stage it takes about a week to deploy to staging and in three weeks later. You can deploy into the production environment Does that make sense? This is a waterfall based process I think we all know that this is horrible and we probably all experience this at one point or another Process efficiency by the way is 30% in this example Make sense? good So what exactly are we doing for a for a value stream map? The key word here is as is We are not defining a an ideal state. We're not defining what we want the process to be We're defining what the process is right now There's a term When you're doing a value stream that's called walk the shop floor it comes from the manufacturing where you would take The first piece that you start at the start and the manager would be there with a little clipboard or the Or the value stream consultants or six sigma consultant We walk through and literally walk the shop floor and follow this piece of this widget Step by step as it was touched who touched it. How long was it touched for what did they do to it step by step until? Whatever started those raw components came out to the end as a car or whatever it is that you're building Okay, now I should also note. This is a fairly standard value stream map flow But really it actually doesn't matter what it looks like Why because you're defining a process flow your process if I've seen value stream maps where they've got a floor plan of a Factory and they've just drawn arrows of where all the components come to where they flow That can be very valuable So respect about value to add time. This is the time spent adding value to the process and Of course non-value add time Is time spent waiting now we talk about in lean? We talk about waste and there's there's a I won't go into detail. There are seven wastes Okay, transports inventory and so forth if you want to know more about that Read the weekly read the Wikipedia page. It should explain it relatively clearly now Let's take a little bit of a Break and we're gonna start doing this You're all in teams. Those of you who are sitting at the back who aren't on a table Please come forward and find yourself a table because this is gonna be a workshop What are we gonna do? We're gonna start to build the value stream map now before you start here are the rules This is this is the workshop. This is an exercise Okay, so a couple of things for you to be aware of number one. I Only want you to define the process steps. I do not want you to define the You don't want you to find value adds I don't care about that right now right now. I want you to find the process steps How is it gonna flow? in those so but You may ask me what am I going to draw what value stream am I going to draw and the answer is it's actually gonna be up to you and Up to your table. Why because it's got to be an as is process It's got to be something that you all understand Okay, so some examples You could draw up your iteration process from sprint planning through to review and retrospective You could draw up a project management cycle You could draw up the The process it takes to hire a new staff member What steps you need to go through to recruit someone? Okay, you could draw up a funding cycle How do you get budgets and funds to actually proceed with a piece of work? It has to be something that is repeatable Has to be something that adds value, but it has to be something that in your Teams your table teams is something that each of you on this table team can contribute to so I'm not going to be prescriptive I'll give you some examples All right, what I'm gonna do is I'm gonna give you about five to ten minutes now Start by doing three things one come up with a team name because every team needs to have a name to Talk to one another share business cards if you want understand what each of you do understand what your expertise are three Understand or find that common value stream find that common Process that you can draw up and from there that for I lied there are four steps for it just the steps Okay, we do this then we do this then we do this then we do this any questions No, all right. We've got about ten minutes. I'll give you about I'll give you a 90 second warning and then we'll close up Because this isn't a competition. We're not here rushing. We're not gonna race I'm not gonna mark you down if you do something wrong. We're here to learn So who would like to stand up and give us a bit of a talk about your value stream map You would lovely start with you guys Sorry, can I get her? I'm Ruhi Srivastava. I'm from Fidelity Investments. My name is Rajendra. I am from Hexagon I'm a Krishna Kumar. I'm from Saber So you want to tell us about your value stream map Sure, so here in we have seen full cycle of product development as well as distribution We like to concentrate on increasing the brand value of the cake in India or maybe any other country, but then yeah So we have Analyze the all the steps and we found out nine value ads which we can make in this whole process number one Yeah, total nine steps. So Number one is finding the current market facts. So obviously as a rookie when you go to the market Obviously, you'll not have any product idea or you'll not start turning out a new company in the market first You will study the facts. So current market facts Checking out how the current current companies are working out there Second is about collecting the data out of it and then analyzing the data Third is finding out value add which we can make so first we analyze the current data And then we know that what are the pitfalls which current processes are having wherein we can stand out and we can make Value addition to the customer. It's not for the profit But then thinking from the customer's point of view that what value it can have Also, what is the process of creating the product? So here in baking process is the product making process So we'll also study analyze the current baking product and see what all Steps are there which can be automated So if that's a big step because right now it's a we saw that there is a big line of There is a big production line so we can automate and reduce waste out of it Obviously, these are common value adds which anyone, you know can think of and make apart from that Some other value adds can be like analyzing the payment options So is everyone providing the same payment options or is there any value add I can make my company can make and Finally when the product will you know, this is all about the product generation and payment But in the last about analyzing the delivery that how the delivery is happening Okay, so I was gonna say that that's actually a fairly good value stream. It's looking at a Product development cycle is a fairly large value stream and it's going to the cadence of that is going to be probably measured in months if not years certainly months and but One of the problems with the actually who can tell me what one of the problems with the value stream like that might be It's it's relatively clear High level is fine. You can actually have Hierarchical value stream you can do high level and you can have value streams within value streams. So high level isn't too bad Measurement and realization of value can be difficult to define But the actual issue with that is it's going to be from an estimation and from a timing perspective your value add time You do it once you're gonna have one set of time to do it a second time a third time a fourth time I think your variance is going to be quite high with this team like to have a go Someone here Yeah, the team name is mad Agilis. So short Majel Okay Myself Maruthu just go through the yeah, so the agile coach from HP Just just go through the stream. Okay. Okay. So we have chosen the order Online ordering so we'll get into the value stream of ordering to the product. I mean actually when he gets the value So the product selection then adding it to the cart payment Shipment then delivery then we can eat or use the product eat the cake Okay, so that's a fairly straightforward product ordering process now in and I'll actually come back to that one because there's an interesting Issue with that process flow which you'll discover when you start doing the Value add timings and the value and the non value add timings and we'll talk about that one a bit later So, let's just move on then we'll go through some of the others. Did anyone have any questions about this? Excellent, thank you. Okay, so most of you have gone through and defined a series of steps process flows of activities that are Have a value. I put three up on the board. Okay developing a feature Develop so you design develop test deploy highly simplistic. Obviously Hiring start right position description Advertise the position interview the candidates select the candidates. Okay fairly straightforward Third one a help desk request A request comes in you triage the request high medium low how critical is it it gets assigned to someone to resolve? It gets resolved. Hopefully, and then the ticket gets closed Okay, does that all make sense? These are fairly common So what I want to look at is look at the value add and non value add times So here Developing the feature. Okay. This is in days Two days to design Half a day from design to development a day. This was our eight days for development a day to waste four days to test Then ten days to deploy fairly long that could be ours just as easily. In fact, it probably is ours Hiring start a day to write position description Ten days from writing position description to interviewing the candidates. Why because it goes out into the market You have to and it go that step of Advertising position takes no time whatsoever. It's a you write position description You press a button and it's instantly on available online You have to wait two weeks to get let the resumes come in Interview the candidates for about two days and then you select a candidate. That's a pretty fast hiring process I think we can all agree but for the sake of this conversation. Let's just use that and help this request This is now in minutes Okay, five minutes to triage two minutes to assign an hour to wait from the assigning to begin it Two hours to resolve ten minutes and five minutes to close Okay, once again highly simplistic not necessarily correct, but good enough for the sake of this exercise Does everyone does that all make sense? Okay We'll do that. Actually, I'll talk about this now. Once you have these numbers Okay, then you can start to calculate the efficiency Value add 14 and a half days non-value add 11 and a half days efficiency 55 percent Value add for non-value add 11 just count them up 1 plus 2 plus 1 is 4 10 plus 1 is 11 Efficiency 27 percent remember efficiency is calculated Value add divided by the total so 4 divided by 15 All right value add a hundred and thirty minutes non-value add 70 minutes 65% efficiency now let's Let's go back to our workshops and we're actually going to stand up with some numbers against this So before you put it, let's just explain once again three things. I need you to do first of all Figure out what your value add is go through each step and go Sorry, actually zero step figure out your cadence your your scale. Are you talking? minutes hours days or weeks Or months or years how whatever your cadence happens to be okay figure that out on each of you is going to be a different okay? Yours ordering a process is in minutes Yours which is in hiring people is going to be in days minimum okay Figure out your value add sorry figure out your cadence figure out your value add then go through and figure out your non-value add Then go through and calculate your efficiency your process efficiency It doesn't have to be accurate once again remember how would we do this in reality? Walk the shop floor in reality you would actually follow this process through and get actual times We're not going to do that here But because we're not going to do that. We're just going to take an average an estimate Okay, think about how long you think it normally takes and go from there any questions Yep, okay, so that so the question was can you make clear what is that these people? Can you make clear what is value add and what is non-value add? Value add is the time the duration spent in one of these boxes How long did you spend designing? How long do you spend developing testing and deploying non-value add is the wait time the time in between? So if there's a handover it could be zero But if there's a handover between the design and the developers You calculate what that it's effectively if you look at the total process flow What time is being spent not adding any value whatsoever make sense? That's a very good depends on the process, but in general meetings are probably non-value add Exceptions of things like workshops which are actually doing design and actually progressing towards that All right, I'll give you all between five and ten minutes. We'll see how you go away you go attention, please Magics Magile, sorry Okay, so you all now have a Value stream map and an efficiency rating That efficiency rating is something that's a little bit interesting and it doesn't necessarily Have a Low efficiency isn't a very bad thing and a high efficiency isn't a very good thing because there can be waste inside your value add steps And we'll talk about that in a second, but before we get on let's actually talk to some of And actually look at some of what you've got Majors can we get you just kick off? I would you just finish okay? Who else would like to actually the HR team over here? I will go with this team here first because I should really interested in what they will have to say Stand up and talk about your value stream map Good afternoon. Do you need the name of the team as well? Give us the name of the team. Yeah We are the selectors Our use case is hiring So cadence is defined in days right like to recruit as soon as we can as soon as the job description is up there the system so the steps are defining the JD and Then we have a interaction with HR make sure it's in as per the Organization format and can you give us the timings? Okay defining the job description and the HR is three days Then the next step is publishing it out externally we do have an internal step, but we are ignoring that for now So between do you need the time between these two phase? So the time between these two from the time the JD is described To the time it's getting published externally is three days again And then the publishing aspect publishing part is just less than a day. So we just said day cadence and then the next step is Recruiting agency which is external is is starting to identify Based on the JD the candidates right so that takes So between between publishing externally and the recruiters getting started we average Wait period is two days right so that we get the right recruiters working on the skill sets we need Then the recruiters itself take three days at least and They are a very repeated firm. So hopefully they have a backlog of Resumes ready. So they take three days then between the recruiters and the next step is the HR involvement That's just to make sure that it goes through the HR. So that's instantaneous zero days Then HR itself is fairly fast it take they take a day then HR contacts the hiring manager and So that between availability of hiring manager his priority on other words They could be a delay of two days and then the hiring manager himself goes through. Let's say it's what One So one resume it just takes less than a day just to give you obviously that's not a practical case we get like 10 resumes maybe so we said for 10 resumes it could take close to three days But our use case is for one. So we just said one day You want to see end-to-end mapping for one recording one person. So between the So HR the hiring manager taking it. What was your overall efficiency? Okay, we got a value-added items at 49 and non-value added to that 16 So efficiency seems to be fairly good 75 percent Okay, 75 percent efficiency for a HR department. Do we all agree that that seems about right? Now this is why efficiency isn't necessarily the measure that you really want to be focusing on Efficiency can be a measure, but a highly efficient Very bad process is actually not something you want to try and avoid. All right. Are you guys ready? All right? Let me just scoot over So we have and products elections takes five minutes adding to cut. It's very fast Payment five minutes all and the product delivery is 10 minutes and product use is 20 minutes So those are the main value-added Yes, and Where the time we spent more is in the waiting the product. So it's a 60 60 minutes we said and Once we did you get the delivery of the product and when we first time start using the product means we have selected camera so So learning to you know camera how to use and all and first time we take a picture So we consider as a product usage. So that time takes around say 20 minutes or so So our product process efficiency comes around 19 percent. Okay, so I'm a little bit confused about that one Your process is to order and ship a product, correct? Yeah, and Propagy's a camera. Yeah, okay. It doesn't matter what it is. So What was your non-value add time for shipping? Yep How was like what how long did you think it was going to take you to ship? Same day delivery. Okay. So here's the problem. So if that was one day, okay, let's make that eight hours eight times 60 all right, so Your efficiency was actually more like three percent Fair enough it depends on your assumptions and and the project that you're doing But the problem and I said there was a problem with that one is that they're effectively have two sets of cadences They have one process flow to get a unit ready for shipping and a second process flow for actually accepting and receiving All right, you created that as a single process. And so you're when you look at that as a single process Yes, you've got a shipping activity in the middle that shipping activity is like measured in days Everything else is measured in minutes. Okay, so your actual flow is misleading So you for that you would actually break it into two flows. There's a flow of Preparing and and taking the order as a prop and you may even have a shipping flow Now you also mentioned when I was talking to you earlier that Sometimes the context changes the difference value add and non-value add if I'm a shipping company Then that shipping activity is a value add activity If I'm the user then the wait time that that shipping occurs to me is non-value add So always remember that just because you think it adds value doesn't necessarily mean it does Okay, so just always keep that in mind as well Okay, does that all make sense now there was a common question that got asked which which I'll actually address and Tell all of you and that was what happens when you have an iterative cycle or that you have a split or that you have multiple activities which sort of happened simultaneously and There's sort of two answers to that and the first is this is a simplistic value stream map It's a single linear flow not everything necessarily has to be linear and in those instances what you would do is you would actually You can create forked or complex value stream maps But the other thing that happens is often your Misunderstanding where the value creation lies if it's an iterative process Then the value is being created at the end of an iteration So your value stream map is from the beginning to the end of the iteration And if you have further activities beyond that then then you're you're mixing levels The value is being created in the ration and you might have one level above that where you have one box Which says iterations and then there are activities which occur along that value stream So value streams can also exist in a hierarchy Likewise when you're doing activities simultaneously Then the value that's being created is actually happening at the same time So in those there's you can have complex value stream maps or you can just consolidate them together into a single Process step or you've actually misunderstood the value stream and they're actually two different value streams That are occurring does that make sense? so there's different ways to visualize and understand the point is and this is why walking the shop floor is very important because you Start from the beginning of where something occurs and you follow it through to the end of that process Each step does not necessarily mean a change in person. It can be the same person working on each of the steps It's just where that value is being created Let's look at a couple of things then All right, there we go. I told you this Kanban is in the title of this talk. All right, so what is Kanban? Kanban is at its very simplistic simplest form a way of visualized, sorry a way of visualizing and tracking measuring monitoring Managing the flow of activities the flow of work through a process Through your value stream So what you've actually created there are the columns on your Kanban board Okay, did anyone figure that one out? When we started that's actually the intent of a value stream or one of the intents of the value stream map We can now use this to understand and actually start tracking the flow of work through this process And then use the information from the Kanban board to then optimize our process We can say you know what we're spending three days waiting for the HR manager to get back to us Maybe that step can be refined or optimized in some way because it's acting as a bottleneck to our throughput Sure, our efficiency is high, but the process is flawed in the first place So these are the the sort of core principles around Kanban. You can read them as well as I can Have a read and have an understand of that now I asked at the beginning who here has used Kanban and that was about half of you Those of you who are new to Kanban just a couple of key points Kanban boards, you've got your columns. You've got your cards that go through the process flow Every square you've got there acts as a column on that You can put a post-it note going through every single square and track one unit of work and Your unit of work is an order Your unit of work is HR your unit of work is a new product It doesn't actually matter what the unit of work is you can track one years of work through that process make sense Now here's where we want to start limiting work in progress Yes Your traditional Kanban board is not the only way of visualizing a Kanban board What you if you have to have a forked value stream and they are fairly rare You really have to actually start looking at how you're going to be tracking the activities that go through that and how they're going to merge Together so it doesn't have to be linear. I've seen Kanban boards, which are circles Okay, because the work activity actually never ends the board. It just continues to go around So the flow and the structure of the board is actually not relevant It's as long as you can actually have that post-it note that card, which is Kanban That will flow through each stage in that process some things will fork and that's why often when you're forking You're actually it's not one process flow. It's multiple process flows and that's something that needs to be considered So, how do we now turn what you have there into a Kanban board? It's actually really simple. Okay? merge the zeros Okay, where you have an activity which is zero and zero zero non-value add and zero value add or in fact Just zero value add to be honest You basically merge that into the proceeding or the subsequent step. Why because if you're tracking work and It's instantaneous in that in a state. There's no point in tracking it through that state you merge it So if you you have product selection five minutes add to cut zero minutes So if you're going to track something through that state you would have product selection add to cut as one step followed by payment because You can't track something in the instantaneous state now the next two steps are Kanban the normal stuff that you're doing Kanban. Okay Define your board policies. What are the rules that each of those steps are defined by? Okay, what are the criteria for entry? What's the criteria for exit? We're agile What's our definition of done? Make sense Lastly calculate whip whip work in progress. This is the most critical part of Kanban and lean You want to have the smallest lowest whip possible or sorry reasonable Not too small that it artificially creates bottlenecks But not so large that teams can choose to multitask Multi-tasking is one of the worst crimes a developer can do Okay, very simple example if I have ten activities each activity takes a day All right, if I do them at the same time It will take me ten days to finish all ten activities make sense Fair enough, I'm it may take more because there's inefficiencies and there's lag time and lead time and all sorts of other issues I'm being simplistic here Okay If I do them all at the same time if I'm one developer and I pick tasks one through ten And I start work on one and then I get bored. I move on to the second one I won't finish any of those tasks until the 10th day Or more if I do them however now in series one after the other after the other It will still take me ten days to do all ten activities But I'll deliver the first one the first day the second in the second day the third in the third day And so on and so forth So I am delivering sooner Does that make sense Now this also gives me option to remove activities. This is all agile stuff. We know this this is why we have iterations We're allowing that product backlog to change This is the same principles but now applied at a micro level okay to flow to activities We want the lowest whip possible Does anyone disagree with what I just said? No Okay Repeat after me multitasking is bad Good. Okay. Are you gonna multitask? No, you probably are I do This is actually something that I struggle with to be honest right right now. I'm running a startup. I have paying clients I'm writing a second book. I'm writing articles for a newspaper so for a magazine and plus I have every all the other little things which I'm doing Speaking writing papers to speak at conferences if I was limiting my whip All right, I'd be focusing. Okay. I'm just gonna spend the next three months. I'm gonna get this book finished I'd have that book. I would have had that book finished two years ago Okay, as opposed to like I would have published my first book get okay I'm just gonna write my second book and I would have been out in three months rather than two years later going I still have to finish that research. I'll do it on the weekend. Okay limiting whip means things get done Not limiting whip means things get will get done much later make sense so now I'm gonna show you how calculate your whip First things first, please. Please be aware. What I'm showing you now is How to start? How you continue is to measure to watch you will watch the flow on your Kanban board and You will go, you know what we need to decrease that whip because things are moving too quickly through there Okay, we need to increase as we need to increase that whip because there's a consistent bottleneck Okay, so whip is something that you're constantly re-evaluating and changing. So how do we do it first through? What is your throughput? Okay, now your throughput depends on your unit of work your unit of work Usually in a software context depends on team size Okay, so if I'm a software team Writing software and my unit of work is a feature My throughput is in features which is limited by the size of my team Okay, does that make sense for you? Your throughput is a product Okay, and you might have 20 people working on a product So your throughput is actually at that is that that group of 20 not that group of one to figure out what your throughput is And most of you your throughput is The same is your team size one person working on one activity makes sense any what sorry Planly, uh, no, no, no. This isn't a planning activity for the next three months This is your your average throughput. How many of these are we going to do and Planly and things like plan leave don't really factor in at this point in time That's more the Mac the micro planning in iteration by iteration This is more we just want to figure out what our what our usual work in progress limits are So let's look at our total whip. This is the whip for the board. What's our throughput divided by our efficiency? okay, if our team is Seven seven plus minus two and our efficiency is 55 percent Then our throughput is 13 as it's sorry, then our whip is 13. What does this mean a team of seven? Given the fact that let's say it's 50 percent Meaning 50 percent of the time is wasted 50 percent of your time is adding value Because it's 50-50 I can do two activities develop two features in the same time As I could develop one Does that make sense? Okay, so my throughput I take my team size also might my throughput my team size divided by my efficiency to give me the total number of simultaneous Units of work I can work on at the same time In this case it's 13 Yes, you do you just figured it out if you don't have your efficiency Then what you that and you can't walk the shop floor as it were than yes You're going to make an estimate So you make an estimate of what your efficiency might be and then you measure and then every single day You measure that and go you know what we were wrong and that's okay usually If you're pairing you divide that by two Yeah, well so if your efficiency is a hundred percent seven divided by a hundred percent one is seven So one person working on one activity is your maximum whip No, I'm assuming that one person is working and that's why I was talking about you have to figure out what your unit of work Is your throughput all right it if you have designers developers test of the players and they're only working in these Context in these spaces as opposed to working across Then then this doesn't necessarily work because what's happening is that your throughput isn't your team size your throughput is the features How many features can you put through this system? I'm saying it's equal to team size Where there's that constant flow or you have the appropriate mix so if Where you have seven people wait where you have seven people to design a light like one designer three developers two testers And one deployer for example Those seven people if they equal one consistent flow one consistent throughput, then yes, you're it's effectively the same Capability it's only where your throughput is something other that is not related to the team It's I've got 20 people working on the one activity going through this So what is going through how many people are working on that? What is my throughput? That's why we're using word throughput not team size. Yeah, I'm using team size as just an example here The real answer is what is your throughput? the next yes How do you defend that? So the question is the lower efficiency allows more multitasking. Yes So the whole point of this process is to identify those inefficient steps and then try and remove them from the process flow Okay, so where you have a 55% because you're waiting 10 days between testing and deploying All right, then what you would do is you would then go all right? Let's actually we're going to streamline this increase our efficiency and that's going to lower our total lip By defining the value stream that you can you're proactively defining how this all flows okay, no well if you're using cumulative flow diagrams, then you'd be able to see the Balances and the and the jagged edges which actually show that that flow All right, otherwise you're looking for blockers if you're just looking to come bundle it reducing cycle time can be one example of how you're going to reduce Improves your efficiency, but I can just as easily spend more time here and less time here All right, but my total throughput doesn't change but my cycle time. Sorry My cycle time might change but my total throughput wouldn't So cycle time can be a measure, but sometimes it depends on where the changes lie So for example actually here's a good example. What would if I changed my development time to two days? Two days to deliver the same outcome the same feature What would happen? Well my efficiency would go down, but I'd still be delivering faster Is that everyone agree with that statement? So Ultimately you actually want to bring your cycle time down. You absolutely do want to bring your cycle time down But cycle time isn't a one-to-one measure for efficiency All right, so let me just quickly look at my timing. Yep. I've got enough time Here now we actually want to try and calculate. What is our whip limit by state? We know our board whip. We know that this board Because our total throughput was 14. Okay, so let's look at this testing What is our total whip? 13 What is the percent effort? for If we look at our total value at 14.5 days, what percentage is testing? Well, it's 28 percent We're spending 28 percent of our value add time in testing agreed 13 times 28 percent roughly equals 4 Okay, makes sense So what is our? We can have a value a whip limit for a team of seven in testing of four and So on and so forth. Okay, two in design seven in develop four in test now point five We can't have a whip of zero So we make that one Because I divided four by 14.5. Can you go back one? I'll put all these slides up online. So you don't need to write these down, okay? They'll all be up on the conference website and I'll put them up. I'll tweet the link Or if you come and get my business card after this, I'll send you the Peter the PowerPoint slide Sorry, no, no, it's about flow forget iterations forget sprints. This is about flow. What is your simultaneous? capability how many units of work can you do simultaneously and In this example we can because we have a 50% efficiency We can do two things in the same time as we can do one Because of that wait time we are distributing those 13 into those different buckets. Yes We have a whip of a total whip of 13. So we distribute them proportionally across each of those states so in this example all right Our cross-functional team Okay, we can do two things we can design two things Develop seven test for and deploy one Simultaneously, oh, oh, that's not something that's actually That's our with that's our work in progress limits. That's how we're going to control that flow now Here's the thing about multitasking Because we have seven people but a total whip of 14 Okay, because we've had to turn that zero into a one So it's gone up a bit because our total whip is 14. It's effectively meaning that yes, our developers are doing two things simultaneously Why? Because there's this massive weight here if we got rid of that weight. Okay, then our efficiency would go up to 90% For efficiency was up at 90% there's almost no multitasking allowed So in which case these will drop down to Well a cumulative whip of about seven Okay, one design three develop two test one deploy you could never have a whip of zero. Just remember that What do you mean? I'm assuming that there's a flow. So it's not about interdependencies or Or overall overarching architecture I'm saying that we have a process flow for one unit of work. This unit of work is designing a feature Okay, also, sorry developing a feature Because of that the start of that value stream is to do the design and the end is to do the deployment If you have a highly interdependent Activity then it's unlikely that you'll have a value stream map at that level because you're because you because because it's interdependent You have to bring it up a level to to do it like a master like an architectural design level And that's where you would actually start to do some of that you track your whip at that level Other questions because this is actually quite important You're talking about a fairly you're talking about an inconsistent flow. I'm a value stream map is about a consistent flow process When you automatically have an inconsistency or known bottlenecks Then that then you would need to adjust the value stream map and thus the Kanban accordingly So because because you've got this bottleneck in terms of testing They only work four days a week or whatever it is and and you know that there's going to be Like a build-up of activities waiting to go into testing Then you would need to plan and adjust accordingly and your whips would go up by its very nature because of that massive waiting time well in the same way you would resolve it in in any process flow, it's okay Think back to us at the beginning. This is an Simplification of reality that we're abstracting what is actually happening into a model that we can track Reality is chaotic So this is because there's a simplification and a model by its very nature all those extreme cases are going to be smoothed out and ignored So this is not going to work for every case. There are going to be exceptions. There's going to be bottlenecks They're out of your control where however and we Deming talks about common causes and special causes in terms of Exceptions and deviations where a deviation is common. It's occurring all the time Then that's when you will need to put in place processes and mechanisms to control and manage that if however Your exception your deviation is caused by something random and unusual Then that's a special cause. We don't actually react to special causes or we shouldn't why? if you saw Snowden's talk in the morning because those reactions are actually inappropriate to the behavioral change that you're trying to embed so when you're looking at those deviations common causes fix them special causes Be aware of them and fix them in the commons in the specific sense But don't necessarily adjust your whip your flow or your condon because of an exception Makes sense. So you know I'm not creating both Can anyone actually answer that question the question was am I creating bottlenecks because my design is too and my Develop is seven why is that not true because of actually the pipeline of work is actually correct Look at how much time I'm proportionally spending on development to design Okay, because I'm spending four times as much time on development They am on design then I can do I can do four designs in the same time I can develop one feature and because of that ratio the ratio of resources doing that work is also Proportioned accordingly, so yes, I might create a bottleneck, but only because my measurements were wrong Okay, if these are wrong then this will be wrong Cycle time Which is the time it takes to go from here the start of design to deploy Lead time, which is the time it takes for an idea to be created to being a deployed and time in state How long it takes to go effectively these numbers two eight four point five because they show us the flow Inside the states those are probably the three key metrics that you've got there are others I'll leave it to you. I'll get look at the Wikipedia page for statistical run charts and cumulative flow diagrams Those are the two primary visualizations graphical visualizations of Process flow through Kanban the Kanban board isn't of itself a visualization But if you want charts and graphs to see long-term trends, it's the statistical run charts and the cumulative flow diagram Kaizen Kaizen just means inspect and adapt Kaizen is the lean equivalent of the retrospective Yes, absolutely when if you're using scrum or any of the other agile practices and you're holding your regular thought-mightly weekly Retrospective then this is the this is the opportunity to reevaluate you would look at your Kanban board and you would go You know what? We've got to fix this wait time. Okay, it's causing so many issues for us Like we could deploy much faster if we didn't have to wait for the next deployment cycle It and that's the whole point of Kaizen all those retrospectives is actually looking at ways of how do we inspect? How do we look at what we're changing and adapt change it to something that is better? And that's why I say things like whip limits of value streamlapse are actually living documents That they're living processes every time you look every time you will use this You will use this to actually Visualize and continually reevaluate how good you are. Don't just look at efficiency I don't like the word efficiency because it has a efficiency makes it sound like you want high efficiency Sometimes that's bad sometimes. I actually want to reduce how long it takes me to develop Okay, that will reduce my efficiency, but will overall increase lead time and so I decrease lead time and cycle time So it's actually still beneficial So efficiency is one way of improving so is improving the productivity within those value-add steps as long but Remember the word value This is what we're producing. We're producing value at the end something of value has been created That's why we're going through these steps and it's part of Kaizen as part of inspection and adoption We're actually going to look at and go, you know what that step adds no value. We're going to remove it Okay, the HR example brilliant example, you had a lot of steps in there, which you could just completely remove and Because because even though there were steps there were activities. They actually weren't adding value So not any value. Why are you doing them? Okay, so the question is in terms of if your resource load is fixed yet Efficiency. Yes, if you have a team of seven You can do those efficiencies in terms of okay We're going to improve so on and so forth to get better at our throughput But if they're not cross-functional if for example All right, we're saying that our developers Okay They're dedicated developers dedicated designers dedicated testers This is causing a bottleneck. What do you do? You know what? we actually need another developer our team size is going to go up to from seven to eight and The way to resolve that bottleneck is to increase that developer and remember we're trying to reduce weight We're trying to reduce waste and as part of that you can actually get rid of people you could say, you know what? Our developers are bottleneck So what we're going to do So our designers are designing faster than our developers can develop we're going to get rid of designer What does that do it reduces your total throughput? But because you're reducing your waste because you would then have less bottlenecks. You're actually going to develop faster No, sorry not faster sooner Let's be clear sooner not faster After absolutely the actual steps themselves like you may completely throw out this value stream map after three months and go You know what we're going to find a different way of working because this isn't working for us Absolutely the value stream map is as is as I said at the very beginning This is only looking at the as is processors as to right now today How is this working and tomorrow we're going to remove steps add steps change them get rid of them entirely Eliminate waste actually let's actually I'm gonna because I'm out of time now Let me give you the Six steps. This is the Toyota production system. This is these are their six rules to Kanban This is where you need to think about How you manage your process low how you manage your value stream map how you manage your Kanban board your whip limits This is the rules to the board To how to run the board All right. I've got five minutes left I've been answering questions for the last ten minutes, and I'll just keep answering questions until you guys are done Okay, so you're asking what parameters what metrics you're going to look at here's the question That's sorry. Do you know if I use the word vanity metric? Do you know what I mean? Okay, a vanity metric is something that you measure that if you improved it if you made it from seven to ten would have no substantive bit Benefit to the value outcomes So when you're looking at parameters when you're actually looking at things to measure you have to be very careful that what you're measuring and what you're actually improving has Has a subsequent benefit to the process and to the steps that you're undertaking So I can't tell you what the standard parameters are because it will really will depend on your process But just always be aware the difference between a real measure and a vanity measure or a vanity metric How do you make sense of a community flow diagram? Come and talk to me afterwards I'll actually show you a cumulative flow diagram and I'll put it up on the screen and I'll she show you how to Have a view it. It's probably some it's beyond the scope. I can talk about there So not pairing Yeah, so here My team size so if I have a cross-functional team if I'm think of it in terms of I'm Through-put isn't the team size. I'm using that as an example Okay, to simplify this if I have one person working on one feature Then yes, my throughput is going to be the same as my team size I've got two people working on one feature then obviously my throughput is going to be half my team size, so that's why If you're pairing and it's cross-functional and so forth, and that's going to be reduced by there's going to be half Because the thing how you set up your board in JIRA. It's been a couple years since I've used JIRA you should be able to there should be metrics to show When things are marked done and if you have whip limits configured It should show you the time it stands in each state and the time it spends waiting to enter a state because that state is full and And and and that waiting time in between states. Oh Look JIRA has a Kanban board in it. It should have all that for you Sorry two more three more questions, and then we'll call and we'll close it Correct. Yes, you can use Kanban and scrum together. It's colloquially known as scrum ban Some people thinks it it's actually a bad idea I think it's actually very good because scrum is actually at a macro iteration level Whereas Kanban can be used within the iteration to track your flow in iteration Really advanced agile if you talk about continuous delivery if we talk about and here's a great Amazon deploys to production every thing on who you ask between 7 and 11 seconds. That's a continuous delivery approach All right, that's pure Kanban activity goes in It gets deployed at the end of that at the end of that cycle So that's the more advanced but standard agile using scrum or other iterative incremental processes Yes, you can easily wrap if you can write a value stream map. You can use a Kanban board So we we are taking an average and that's what we're saying at the very beginning Whatever because we're taking an average because we're looking at the If a process has a major variance, okay So one process might take a day to design another might take 12 days And you just have these massive variants that it's very hard to actually have that smooth flow So in those cases Kanban and those lip limits aren't going to work very well because you can't actually have a consistent flow Where you've got a like a p50 plus or minus 50 percent to in terms of that variance this works much better Yeah That's a common sorry, that's a special cause If things are going wrong things are going wrong and you just need to fix them Anyway times up. Thank you very much. If you have questions come and have a chat with me at the front I'm happy to talk if you want to copy the slides come and get me. I'll give you my card