In today’s episode of the Agile Coaches’ Corner podcast, host Dan Neumann is joined by Daniel Vacanti. Daniel is the co-founder and CEO of ActionableAgile, the world’s leading provider of predictive flow analytics for agile processes. He is also the founder and CEO of Corporate Kanban, the premier Kanban training, coaching and consulting partner who show developers how to use their current software delivery processes to shorten software releases. They are among the world’s leading experts in applying lean software solutions for all types of enterprises.
Today, Dan Neumann and Daniel Vacanti will be talking all things Kanban. Daniel explains exactly what Kanban is, what it looks like in practice, the data side of Kanban and how it aids in making better decisions, the process of collecting data through Kanban, and the overall benefits of using Kanban. Daniel also gives a thorough walkthrough of how exactly to get started with Kanban starting right where you are.
Intro: [00:02] Welcome to the Agile Coaches’ Corner by AgileThought, the podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach and agile expert, Dan Neumann.
Dan Neumann: [00:17] Well, thanks for joining today. I am Dan Neumann, your host for the Agile Coaches’ Corner Podcast and I’m super excited today to have with me Daniel Vacanti, who among other things is an originator of Kanban for software development and the creator of the actionable agile tool which I’ve seen in use. Gives you some nice ways of collecting and visualizing that data. And I’m sure there are many other things we could throw on the frontier, Daniel to, you know, make it sound as awesome as this is. But thanks for joining.
Daniel Vacanti: [00:47] No, no, my pleasure. I really, really, really glad to be here. Go ahead. Back to the invitation, uh, to, to join yourself. I’m really looking forward to it.
Dan Neumann: [00:54] Fantastic. So we’re going to be talking about Kanban and these will be our opinions and nobody else’s, no other companies or people,
Daniel Vacanti: [01:03] Right? Yeah, no, nobody. Nobody else’s opinion really matters anyway.
Dan Neumann: [01:07] It’s true. Everybody has one. So maybe a place to start, Daniel. I know a lot of times I go to companies and their notion of Kanban is you throw to do, doing and done up on the wall and yeah, you’re pretty good there. And that’s sometimes that’s where it stops too. So if that is a place to start from a conversation standpoint about what Kanban really means, but maybe you could, uh, give a little bit more thorough kind of definition for folks who are new to it.
Daniel Vacanti: [01:39] Yeah, I get that all the time. Right? I go, I go into a company and teams are like, Oh yeah, we’re putting posted notes up on a Whiteboard, you know, of course we’re doing Kanban, we’ve got, we’ve got a workflow that’s to do, doing, done, you know, of course we’re doing Kanban. Right. Um, and you know, I think a lot of people don’t realize really just how much more to it than that there is. Um, not to honestly though, not to say that there’s anything wrong necessarily with the to do, doing and done workflow. Um, but a lot of times, you know, if we can more accurately reflect the reality of what’s really going on in our process, there’s so much, so much more information, so much better decision making that we can, um, that we can make if we get that, um, you know, so its things like, like understanding your, what you know, where, where are the handoffs in your process, you know, where, where are Qs building up in your process. You know, what, what, um, what really are those different steps in the knowledge discovery process that need to happen between, Hey, I’ve got a good idea and, um, I’ve actually delivered customer value. Um, you know, so you can map all of those things out like up, like I said, um, you, you’re just so much better off at a, at being able to make, make some better decisions
Dan Neumann: [02:45] One of the things I like about Kanban is that it’s an invitation to start where you are, make it visible, figure out what your WIP limits are, your work in process limits and then continue to pursue improvement.
Daniel Vacanti: [03:01] So I have to say, so, yeah, I mean that’s, I, I know, I know that there are flavors of Kanban that espouse those types of principles. I have to say that I’m, I’m not necessarily in 100 percent agreement with all of those things. I mean, if those things work for you, great. I think that’s great. Um, but a lot of times, even even like the start with where you are now thing, um, I, I would say that every, I think I can say this, every Kanban implementation that I’ve been a part of, we have not started where we are now. Right? We just, we just haven’t. In fact, a lot of times it’s been the team starting with, like I said, a blank sheet of paper or a blank whiteboard or whatever and saying, coming together and saying, it’s trying to decide, okay, how do we want to work? How do we want to work together? So that’s valid too. Um, and also I think it’s a bit of a, I think it’s very, very disingenuous of people when they say pursue evolutionary change in, you know, on one side of their mouth and the other side of the mouth talking about little work and progress, you know, so you know, if you’ve been to any company that’s never limited work in progress before and then you all of a sudden go with your limit work in progress, I’m sorry to tell you, that’s revolutionary change, right? That’s not evolutionary change. That’s relevant no matter how you, no matter how you slice it, that’s revolutionary change. So, um, I guess my point here is there, there are many, many different ways that you can go about this. You know, which you talked about is one is one way. If, like I said, if that works, that’s great, but I just want people to know that there are other options out there as well.
Dan Neumann: [04:24] Let’s go. Oh, so he’s now the consultant tongue in cheek. Well, it depends, right? It kind of depends on where you are. But that’s cool. So it’s good to know that there are some, oh I dunno. Some, some different ways to get started, right? It’s not just hey here is the one path and I, I think you are onto something there. When you say limiting work in process is pretty revolutionary at a lot of places. Cause you know, I’ve, I’ve seen that where it’s like, oh, but we can’t not work on everything. We have to work on everything because somewhere in the organization a big boss has said so and we’re expected to deliver all that. That’s cool for me. And for your expertise, obviously an expert on Kanban. But one of the things that got me excited about oh, like have to get Daniel on here, it was your keen interest in the data side because I think a lot of, a lot of agile, a lot of Scrum specifically even with Kanban it gets to be really subjective about are we doing good, what’s high-performance look like? Are we on track, et Cetera, et cetera. And I, I love the data side. So maybe you can talk about the data side of Kanban and how it, it helps.
Daniel Vacanti: [05:37] Yeah. Well I think so much was the first time. I mean, we’re, we’re talking about, you know, agile is interactions with humans, right? I mean, that’s just, that’s just what it is, right? And unfortunately, or fortunately, depending on how you look at it, um, interactions between humans can be very, very subjective, right? You know, you had your view of the world. I have my view of the world. And it’s not to say that either one of us are wrong, it’s just we have our subjective view of how things are, um, and how they’re going. And I guess to me, the thing that I like about the, the metric sides of things, it’s, it’s a way to try and bring some, some object objectivity, um, into otherwise very, very subjective conversations. Um, and like I said, the, the, the goal, the goal, at the end of the day, the goal is hopefully to make better decisions. It’s, you know, it’s, it’s to be able to, to manage risk better. It’s, it’s a way to deliver value more efficiently and effectively and predictably, you know, et cetera. Um, and so that, that I honestly, like I said, that’s, that’s why I’m really drawn to the, uh, to the metrics side side of the equation. So, you know, anytime that we can bring some, some objectivity in into our decision making, I think, uh, I think we’re doing that much better.
Dan Neumann: [06:42] I would agree too. And like you said, there’s lots of different perspectives, but at some point it would be nice to, to have some specific things that we are in agreement of as far as as metrics.
Daniel Vacanti: [06:52] Yeah, yeah, yeah. And, and, and if I can, I mean, it’s, and this is, I dunno, this is going to sound like Scrum bashing, but it really isn’t, but I mean, Scrum, Scrum is built on this whole idea of empiricism, which I think is a wonderful thing. Right? I’m never going to disagree with somebody who says, I want to bring more and you know, and empiricism into my process. I will never disagree with that. The problem is, is that most people don’t know how to go about doing that. Right. They don’t know how to, you know, think empirically or act empirically or, you know, behave empirically. They just, they just, they just don’t know how to do that. Um, and in the absence of all that, they, they normally gravitate it seems like to all the wrong things, you know, things like, you know, Oh dear God, story points and velocity and stuff like that. So, um, if, uh, I kind of see it as my purpose in this world to kind of stamp all that stuff out and, uh, try to get people to understand, you know, there’s, there, there, there are better ways that we can, we can act empirically. You know, there’s better data that we can gather, um, and uh, and use it to influence, um, how we, how we just improve over time.
Dan Neumann: [07:56] So imagine if you will, that somebody listening to the podcast might be using story points and velocity and they’re like, wait, what was that? There’s a better option. So we don’t need to bash Scrum. I mean, I think a a, so one of the things I’ve, I’ve kind of been saying more lately is like the velocity, the story points. It’s not actually in Scrum, it’s a general acceptance Scrum practice. Maybe it’s useful in some instances, but it’s not a Scrum thing. So let’s, um, let’s tap your expertise and give some better options for folks who might want to compliment or displace their story points and velocity.
Daniel Vacanti: [08:39] Yeah. And if, if, if I can retreat into my consultant speak for just a second here, you know, I don’t, I don’t know if I necessarily want to use the word better, although it depends on how many beers you get into me, whether I want to say it’s better or not. But, um, uh, you know, certainly things like story points and velocity are working for you. Um, I don’t want to sit here and say that those things don’t work. I’m not, who, who am I to say that? Um, I will say though that if there is a method out there that can give us more accurate answers with a lot less effort, um, then why wouldn’t we do that? Why, why wouldn’t we explore those things. Further, if we could get those more accurate answers with less effort and speak the language of the customer. Even better. Right. So, I mean, how many times, I say this all the time. I mean, if you, you know, if you go to your customer, if you go to your product owner, I mean a product owner hasn’t been maybe trained in Scrum, but if you’ve got a product owner, if you’ve go to a CFO, if you go to an actual end user and say, Oh yeah, that thing’s gonna that thinks about five story points, they won’t, they will not know what you were talking about. They just will not know it. But if you say, you know, hey, you know, I think I’ve got a pretty good chance of getting that done in eight days or less. Um, now that’s something that they could really understand and they can get their minds around and they can start using that information, like I said, to make better decisions on their end about what, you know, how they’re going to prioritize stuff, how they’re going to pay for stuff and you know, et Cetera. So I don’t know. I don’t know if that, if that helps cause I don’t want to necessarily say that what I’m advocating is better. Um, but I do believe there is a lot of evidence out there to suggest that we definitely can get more accurate answers with less effort and we can make our customers happy at the same time.
Dan Neumann: [10:17] Yeah. I think there’s an anti-pattern of Scrum teams since we’re talking about Scrum a little bit, going to folks outside the Scrum team and talking about things like velocity and story points and when the customer doesn’t really know, then we, well, we’ll, we’ll let me tell you about the sprints and the Scrum Master and all the other funny things going on in the Scrum team as opposed to shifting to even their language. Hey, it’s going to be in two sprints and you know, we should have this done or see there I go again, two sprints, two weeks, maybe in a month it’ll be done. So just really speaking in language that they understand. So then in order to give more, uh, more obvious answers, like there’s a high probability or an x percent chance that we’ll have this done within eight days. How do we go from, we’ve got our value stream up on the wall and you know, we have a limited work in process, let’s say, and now we need to collect some data on those things.
Daniel Vacanti: [11:14] Yep. Um, it’s a lot, a lot more simple than you might think. Um, or than most people hope we might think. And that is so, you know, you start with a great point and those assume we’ve visualized our, our, our value stream, like I said. Um, and so we’ve got some, some understanding of workflow to our process. The, the, from a metrics perspective, and to be honest with you, I would argue you need this for a value stream perspective anyway, but what you really need what every team or of your organization or whatever it needs to do is to say, you know, what does that, what’s that clear, clearly defined point at which we consider work to have started. And what is that clearly defined point in which we consider work to have finished. Now there might be several of those. We might consider, you know, several different starting points or might consider several different ending points. But we can maybe talk about that, the nuances of that a little bit later. But just as long as we know there’s a point at which we can start measurement and a point which we can finish measurement, that is key. That is, I mean you, you can’t get anywhere without having those two things. Once you have those two things, that just opens up all kinds of, um, all kinds of doors for us. So when we have that, that start point on that endpoint from a data perspective, really all you need, all you need is that timestamp at which an item crosses that star point and a timestamp at which the item crosses that end point. Once we have those two things, we can start calculating things like a work in progress in cycle time and throughput and start making predictions about our ability to get, you know, a single item done or several things done or you know, do release planning or sprint planning or whatever. It seems a bit ridiculous that those are the only two pieces of information that you need to get started. By the way, there might be more data that you want to collect later, but to get started there was a really the only two, two pieces of information that you need.
Dan Neumann: [13:01] So one of the places maybe where Kanban and Scrum have got together, at least with Scrum.org trainings, there’s a Kanban with Scrum training. And so I might think if I’m a Scrum team, the start might be when we begin to do some code on it within a sprint and then the end might be when the product owner is given a thumbs up within the sprint. And so that might be an example. Or if you’re doing something that’s a, a ticket based system, maybe you’re doing a help desk thing from the time I pick up the ticket off the queue to work on it until the point where the end user has said, guess you have resolved my issues. Those might be a couple of examples of a start and an end where you, you’d capture the, the uh, the begin time. The end time.
Daniel Vacanti: [13:43] Exactly. I mean, yeah, exactly right. I think a lot of, especially from a Scrum perspective, I think a lot of Scrum teams get hung up on this idea that, uh, you know, the second that we put it on our sprint backlog, it’s considered started. Well, you know, maybe, maybe it is, but maybe not. You know, because that was the whole idea of the sprint backlog is it’s, you know, what, what we put on there is really just don’t forecast of what we think we can get done. You know, that’s, that’s one thing I love about the Scrum guide is I’ve gotten rid of that, that commitment word.
Dan Neumann: [14:10] Yeah, it was such an abusive thing. It got used for abusive purposes. All commitment thing. Yeah.
Daniel Vacanti: [14:16] Commitment at least as a, you know, as, as it is used for planning. So just because it’s on the sprint backlog doesn’t necessarily mean that the team is quote unquote committed to getting that thing done. So to your point, yeah. Um, it might, it might be not, when we might not start measuring from when the thing gets on the sprint backlog, it might start measuring until we actually start, like you said, pulling in and actually start working on it. And then we don’t necessarily want to wait until the end of the sprint to close all of our PBIs. Right. And hopefully we’re closing them and getting feedback from our product owner. Um, you know, as, as we go along. So, you know, you’ll see that I think initial, you know, from Scrum teams, likely they open all their PBIs at the beginning of the sprint and then they close all their PBIs at the end of the sprint. And once they start to understand flow and the impacts of these metrics, um, you know, for them to manage their flow a little bit better, that’s what we start seeing I think a little bit more, dare I say mature behavior. Um, like what you were describing.
Dan Neumann: [15:09] Yeah, well, so let’s, so we’ve got the start time, the end time for the thing regardless of of whether they are all open at the beginning or all opened at the end. And so the, I think the easiest number, the first one that you’d start with, would that be cycle time, the time from start to the end or where, where do you start with trying to get some numbers that are useful in making decisions?
Daniel Vacanti: [15:33] Yeah, probably. I mean there, there are several different schools of thought on this. Um, and just from a, from a nomenclature perspective, I mean I am going to call that total amount of elapsed time between start date and end date cycle time. Um, you know, I know there are a lot of, a lot of dogmatic religious battles out there in terms of really what this, these things should be called. And from my perspective, I think most of those conversations are academic. You call the time between those two things, whatever you want, call it, cycle time, lead time, flow, time, time in process. I really don’t care just as long as you have those two things defined. But yeah, I think I, you know, a reasonable, a reasonable place to start is, is something like, um, cycle time, which is that total measure of a lapse time. And that’s, that’s the key point. A lapsed time. We’re not subtracting out weekends, we’re not subtracting out holidays. Um, we’re not, we’re not only measuring time that people are actually working on something it’s total amount of the lab style. Again, we’re speaking the language of the customer because that’s what the customer sees.
Dan Neumann: [16:31] If their duration, it’s the duration of the thing. Okay. Whether I took me an hour or two weeks of human effort, it’s the duration.
Daniel Vacanti: [16:41] Yeah because the customer doesn’t care. You know, at the end of the day, if it took us 30 days to deliver something to the customer, you can’t go to the customer says, well yeah, you know, it took 30 days but I really only had to work on it for two hours. You know, that’s, you know, the customer doesn’t care. Right. So, um, so that’s maybe a whole different podcast in terms of how we’re measuring things, what we call them, you know, et cetera. But, but yeah, if we, if we can just agree for now that, you know, that’s, that the cycle time is a good place to start. And the great thing about cycle time is now that gives us an understanding, like you said, from the customer’s perspective, how long does it take for an individual item to get to our process? So once we have that data, once we’re measuring that start time and end time for each item that moves through our process, we can take all of that data and we can start now to make some reasonable forecasts about when we pick up the next item, when we pick up the next PBI, when we pick up the next user story defect or whatever it is, how long is it going to take for that individual item, uh, to get through our process, right. Um, which now if, if, if I can start asking myself questions and answering them, maybe you just go off and, you know, go have a coffee break or something like that.
Dan Neumann: [17:51] I have a coffee here, but you’re on a roll.
Daniel Vacanti: [17:55] But now the question becomes, well, once we have that data, what is forecasting and how do we do forecasting and how do we communicate forecasts and things like that. Can we, can we go there or did you have something else you want to do?
Dan Neumann: [18:06] Oh, I want to stop for just a second because something you said is, is often where I see sometimes heads explode, which is, well we’ve, we’ve got the, we’ve got the cycle time or the time in process for this thing and how can I forecast other things based on it because they’re not all the same. You know, this was a little one. That’s a big one. They’re all different. They’re all coming through so I can see people going, wait, no you can’t because they’re all different.
Daniel Vacanti: [18:30] Yeah. Uh, again, this is, a whole other podcast episode. I don’t know what the rest of your calendar looks like this year but we’ve got a lot.
Dan Neumann: [18:41] I’d be happy to have you back on that because I think because I, you know, and that’s where I think a lot of teams struggles they throw to do, doing, done up and then they’re like, ah, what now?
Daniel Vacanti: [18:52] Yeah. Yeah. So what you’re hitting on, what you’re touching on is, is the fact that so once, once you head down the flow path, if you will, once you start considering flow, so much about flow is counter intuitive. So much about flow goes directly against what we as humans believe or what we have intuition about or whatever. And this is, this is kinda when I was talking, uh, alluding to earlier when I was saying, you know, people really don’t know how to behave empirically, you know, cause you’ll hear things like, um, well of course obviously you know, the more things I work on the more I am going to get done, right. That’s just the way I am, and that’s not true, right? They say, well of course obviously the sooner I start something, the sooner it’s going to get done. Well that’s not true either. Right. And then you’ll hear the next thing like you were suggesting was, well obviously the size of the item you know, is going to directly affect how long it takes to get it done. That’s not necessarily true either. Um, and so that’s what I’m saying. You have to throw a lot of this intuition out the window. Um, and I’m trying, I’m trying to figure out the best way to answer this question. Like I said, without taking up the next 30 minutes, um, to, to explain, but, um, you know, basically when, when, when we start talking about forecasting and we start talking about how do we take this data and, um, make a, a reasonable, accurate forecast about how long it takes for things to get done. The first thing that you have to recognize is that we’re, you know, forecasting is, is we’re, we’re predicting the future. We’re essentially predicting the future. Right? And, um, I don’t know about you, but my skills for predicting the future are terrible. Right? I mean, if you’re, if you’re good, then you’re in the wrong totally in the wrong business. Right. I’ve got, I’ve got tons of other work opportunities for you. Um, but so the second that you knowledge that we’re predicting the future, we all know the future is full of uncertainty, right? I mean that’s just, that’s just the way it is. There’s, there’s all kinds of uncertainty. And the second that you recognize that the future is all about uncertainty, now we’re at the next step from an empirical perspective, the next step that you have to take is well predictions with predictions. We have to start taking a probabilistic approach to predictions and not a deterministic one. And that’s honestly mostly why I’m against, I shouldn’t say mostly, but that’s a big reason why I’m against story points and velocity is because a lot of times those things are communicated deterministically and what, so if I can complete the circle, um, once we, uh, once we acknowledge that we’re taking a probabilistic approach, then what you’ll quickly realize is things like the size of a particular item has almost no bearing on the overall probability distribution of the things that are going through your, your process. You know, it doesn’t matter that this one is one story points and this one is five story points. From a probabilistic perspective. Um, they’re probably roughly going to fall within a certain range of, of getting done anyway. So, I don’t know. I, I don’t know, this is a podcast so people can see me waving my hands wildly or whatever. But, uh, I hope that helped.
Dan Neumann: [22:17] Well, we’ll see what we can do to, um, maybe come up with a like a visualization or a nice little summary of something then for, for the show notes perhaps. Um, and as you were saying, you know, we’re, we’re forecasting in the future if we were really good at that, highly predictive gated approach is like, you know, waterfall would have worked just fine, but we kind of stink at forecasting as a species and as a profession. Yeah. Okay. So let’s see. Uh, thank you for pursuing that as, like Squirrel, right? Off we go. I thought, I just, I thought we might lose people. Like the BS alarms might go off and they’re like, oh, but okay, so we’re going to suspend our disbelief on that part. So we’ve got the, the cycle time and now we’re, we’re just using that as a forecaster.
Daniel Vacanti: [23:03] Yes, yes, yes. we’re using, we’re using that to do a type of forecasting. So we kind of, we kind of jumped ahead a little bit. Um, when we talked on those, it was my fault, not yours. Um, when we talk about just, uh, forecasting in general, especially when I think specifically we’re going to be talking about answering that question, when will it be done? Right? That’s what we’re gonna be talking about. Um, and, uh, there’s, there’s some subtleties to answering that question. When will it be done? Because there are multiple flavors of the question. When will it be done? So far we’ve been talking about when will it be done for a single item, right? So I picked up the next PBI off my backlog. Um, how long is it going to take me to get this PBI done? That’s a forecast for a single item. That’s what I call a forecast for a single item. Um, there’s also the when will it be done of, hey, I’ve just filled up my, or I think I’ve just filled up my sprint backlog. Um, do I think, do I think I can kind of forecast reasonably getting these, these number of items, these total number of items done within that sprint? You know, the sprint planning, um, that’s a forecast for multiple items. So, and there’s also things like, Oh yeah, I’ve got this release date coming up. How many items kind of get done by this release date? I’ve got, you know, well, whatever those, those are all, those are all forecasts for multiple items. So when you’re doing your forecast for single items or a single item that’s going to use the full metric cycle time that we just defined. But when we use the, we talk about when will it be done from multiple items, you know, sprint planning, release planning, whatever that’s going to use the full metric of throughput, which we haven’t defined yet. Um, and throughput we’re going to define as, so remember I said you have that well-defined point in which stuff is completed. Throughput is simply a measure of the number of items that complete that cross, that completed line per unit of time. And the per unit of time can be whatever time unit you want. You know, it could be one PBI per day, you know, five PBIs per week, 3 PBIs per month. Those are all measures of throughput you can say 16 PBIs per sprint. That’s another valid measure of throughput. But their cabinets, they’re not story points, they’re not ideal hours, they’re counts that are just literally counts of items, discrete counts of items per unit of time, that’s throughput.
Dan Neumann: [25:21] And I, and, and that seems like a pretty simple thing to collect. You know, with the begin time and time you’ve got like some dates, but hey, how many things got done this day, week, sprint, month. That’s pretty straight forward math.
Daniel Vacanti: [25:33] And that’s the beauty. Like I said, that’s the beauty of just starting with the start date and end date is just with those two pieces of information. Like I said now and now we’ve just got, we’ve calculated both cycle time and throughput with the same data. Um, no, the team hasn’t had to go out and do anything else. They haven’t had to collect more information. It’s the exact same data and now we’ve got two pieces of information that we can use to forecast in two completely different scenarios. It’s kind of magic. I think.
Dan Neumann: [25:59] I do agree. So I think maybe folks would be like, okay, I see that you’re telling me I can forecast. How exactly am I going to forecast? I don’t know if this is another thing where it takes a lot of math and a hand waving. I sat in a, an interesting session at the agile2019 conference on Monte Carlo simulation using past performance to predict future. And I was, I was a, I don’t know if I’m afraid or not. I was like, is that, is that where we go or are there simpler ways to do the forecasting.
Daniel Vacanti: [26:36] That um, that is an I’ll say again, that ox as an option. Um, I’ll be honest with you, that is my preferred option when we, when we’re talking about forecast for multiple items, forecast for multiple items world. My preferred option is to use throughput in a Monte Carlo simulation. Um, and I hope we’re not scaring people off by saying fancy words like Monte Carlo simulation cause it honestly is much, much easier than than what I think most people might think. Um, but when we’re taking, when we’re talking about a forecast for a single item that potentially can be much, much easier. My preferred tool for something like that is for that is something called a, um, a cycle time scatterplot. Um, and again, I wish, I wish maybe we did have visuals for this. Um, for this cause it’s, it’s fairly difficult to, uh, to kind of describe these things without, uh, without real pictures.
Dan Neumann: [27:27] Yeah. And so in my head I’m figuring I could or we could some, I’ll probably take a snapshot out of actionable agile, which does the scatter plotting for you. It takes, I know we’re using Azure DevOps for several initiatives and that then has some of this data in there. And so it’s essentially free to get the data and to create the visualization. The not free part the part where humans, um, need to make some decisions is looking at it and going, okay, what do we want to do about the high or low probability of delivering this item by a particular point in time?
Daniel Vacanti: [28:02] Yup. Exactly. Exactly. Yeah.
Dan Neumann: [28:05] So if we have, I’m trying to think if we have a scatter plot of that.
Daniel Vacanti: [28:08] Oh, okay. Yeah. Yeah. So what’s I mean, so once you have your scatterplot, again, remember the, the goal is to come up with what, what is our probabilistic view of the world that gives us the best understanding of the risk. So is what we’re really using is probability, hopefully to quantify risk. Um, and so answering the question, when will it be done is really a function of trying to understand, well, how much risk are we willing to live with, you know, um, are we okay? Are we okay being wrong 50% of the time? If you’re okay being wrong 50% of the time, then you might be okay with just forecasting using an average, which you know, is something that kind of makes me cringe. And I just died a little bit inside, but I mean, if you want a forecast using an average.
Dan Neumann: [28:50] Is that because you, you’re, you’re not okay with the flip of the coin? Probably like, yeah, yeah, we might, yeah. And I don’t know many business people that are like, if you say, hey work, there’s a 50/50 chance, we’ll give you what you’ve asked for on time. Eh, I don’t know. I don’t know many business owners to get excited about that.
Daniel Vacanti: [29:08] And they shouldn’t. And that’s, um, the, you know, these single book that I hand out hand out to people to help them understand that exact concept is a book called, “The Flaw of Averages,” by Dr. Sam Savage. So that’s for everybody listening as your homework is to go get the flaw of averages. And the basic premise of, um, of, of Dr. Savage’s book is if I can crudely distill it down into one sentence is plans based on average fail on average. Right? Um, so that’s, that’s, that’s, that’s kinda the basic premise and you’re right, I don’t know many business people that would be excited about our ability to fail on average, right? So we probably need, we probably need a little bit more confidence in our estimates. And that’s really what you would do in your scatterplot is we’re able to segment that scatterplot into different percentiles. You know, what did I have a chance of being 70% right? What’s our chance of, or sorry, what, what, what’s the range? We need to be 70% right? What’s the range? We need to be 85% right, to be 95% right? We can take the scatterplot and we can segment it into those ranges and then now we can communicate the forecast in terms of that range and that percent competence, right? So I, I believe we have an 85% chance of being done in 12 days or less. Right? And again, remember we’re talking about predicting the future so that that forecast has to be communicated probabilistically. You know, we, we have that range and we have that probability of, of falling within that range and that’s the best you’re going to do. Really. I mean, that’s just the world we live in.
Dan Neumann: [30:41] Yeah. And it allows the conversation about what do we want to do about it to happen? You know, I was at a place, they made a product that needed to be on the shelf for Black Friday. Like you don’t miss Black Friday. So they would need a very high probability chance. There was a place that was trying to avoid, uh, a compliance-related violation that would be expensive. You don’t miss that. And so now it’s like, I like tying that back to the principle of maximizing the amount of work not done in agile. It’s like, okay, what don’t we have to do to achieve this goal and start pulling that out. And you can watch that, uh, prediction that forecasts become a higher and higher likelihood of achieving the goal.
Daniel Vacanti: [31:24] Exactly. Right. And that’s, and that’s the point. That’s, that’s the risk management side of things is once we can, again, once we can put this more hopefully objective number associate, that more objective number with risk, now we can start having these conversations about, all right, how much risk are we willing to live with and what are we doing to, to, to manage that risk in a way to get the outcomes that we’re looking for. Exactly. Right.
Dan Neumann: [31:47] So Daniel, I really appreciate that you, you’ve kind of taken us on this journey of, of Kanban exploration that we’ve just kinda started to scrape the surface on some of these metrics things. For folks who are kind of curious about how do I get going? Like, okay, I get that predictability is something I would want and probability, but like, how do I, how do I get started?
Daniel Vacanti: [32:07] Yeah. So, um, how we get started is, you know, I think exactly a as how you introduced the podcast. Um, you, you start first with just a basic understanding of, uh, of your workflow, you know, of your value stream or however you want to call it. First, you have to have some understanding of how work is done. Once you’ve got that, within that workflow, within that value stream, you need to find a point in which you consider work to have started and a point at which you consider work to have finished. Right? Those, those clearly defined points. Um, and then just to start taking a type, just take a timestamp for every single item that goes through your process. Take a timestamp at and a start point and that end point. Once you’ve got that, once you’ve got that data, now we can calculate cycle time, throughput at work in progress with calculate all the flow metrics so we can start putting them into all the tools that we’ve talked about, cycle time, scatter plots, Monte Carlo simulation, et cetera. Um, but hopefully it really all starts with first understanding of your process and that first basic measurement. So that’s, that’s really, really good. Sorry if I could just say we haven’t even talked about the most important metric and that is, that is work item age. But, so you have to have me back to talk about work item age.
Dan Neumann: [33:20] I would be happy to. I’d be happy to. So we’ll put a, we’ll put a pin in work item age and we’ll compare to some calendars and see about getting that on there. And it’s such a rich topic and actually, so maybe start a yes/no, with a very short explanation. Do you need a data nerd on your team to pull this off? Like somebody who’s just religiously going to track this?
Daniel Vacanti: [33:42] No. You said you wanted one answer, so no, no, you do not need one.
Dan Neumann: [33:47] No, you can elaborate. Okay. So, so I know tools will do it for you, but if you’re a sticky note person, it’s somebody with a spreadsheet.
Daniel Vacanti: [33:53] Yeah. Yeah. I mean cause just try, if you’re using stickies, just literally, I’m not, I did this for years. Just, just handwrite that the dates aren’t right on the sticky and the yeah, put it in a spreadsheet, but lots of, lots of spreadsheet tools out there. Um, and go for it.
Dan Neumann: [34:07] Cool. No barrier to entry. And we’ll, uh, we’ll put some links to the different concepts we talked about. I know we, we threw out Monte Carlo simulation and didn’t give any explanation of that. Uh, for people who have anything with stocks or ever talked to a financial planner. There’s a good chance the, whether you have money left before you die, they probably did that with the Monte Carlo simulation.
Daniel Vacanti: [34:26] I hope they did.
Dan Neumann: [34:32] And then are you reading anything that’s got you inspired? I know you gave a reading list of the flaw of averages to folks, so that’s one homework item for people, but are you kind of, what’s your learning edge looking like?
Daniel Vacanti: [34:43] My learning edge right now is actually, it’s a very serious bent toward behavioral economics. Um, and getting people, you know, understanding how humans are just, we’re programmed to be flawed at decision making. That’s not a bad thing. That’s just how we are. Right? Um, and understanding how, how our, um, our are misbehaving so to speak. Those of you who know Richard Thaler, um, know, the book misbehaving. Um, we misbehave in predictable ways. Um, and so harnessing guy that, that understanding to, uh, to nudge people in the right way with using these metrics to make better decisions. That’s, that’s what I’m most excited about right now.
Dan Neumann: [35:20] That’s super cool. And the one I’m starting to consume is called Thinking in Bets, which also takes some of this behavior you called Annie Duke. Yeah, yeah. Yeah. So I’ve just started through that, but my, a reading list keeps growing more and more.
Daniel Vacanti: [35:36] So chapter 6 is wonderful in, in Annie Duke’s book. Chapter six is just, it’s wonderful. Alright, make sure you get there.
Dan Neumann: [35:41] I’ve got a long drive to the upper peninsula of Michigan for a marathon this weekend. I think I’ll be able to get at least through chapter six, so. Fantastic. Hey, thank you very much for joining today, Daniel, and we’ll look forward to a follow up conversation.
Daniel Vacanti: [35:53] Absolutely. My pleasure. Like I said, I was honored to be asked and a very, very glad to be here. Thanks again for the invitation and hope we get a chance to talk again very, very soon.
Outro: [36:04] This has been the agile coaches corner podcast brought to you by AgileThought and get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.
Contact us to share the challenges you’re facing and learn more about the solutions we offer to help you achieve your goals. Our job is to solve your problems with expertly crafted software solutions and real world training.
For a better experience on the web, please upgrade to a modern browser.