Exploring Velocity Podcast

Podcast Ep. 135: Exploring Velocity: What is it? How Do We Measure it? How Can We Leverage it?

Exploring Velocity Podcast
Share on facebook
Share on twitter
Share on linkedin
Share on email

Episode Description:

This week, Dan and Sam are discussing an important metric to agile teams: Velocity. If used correctly, velocity can be an incredibly helpful tool for teams to leverage to forecast future Sprints and understand what it is that they can accomplish in a given amount of time. If used incorrectly, however, it can wreak havoc on a team’s ability to work together and deliver value incrementally.

In this Scrum-centric discussion, Sam and Dan take a look at what velocity is; how to measure it, why it is important to teams, leadership, and the organization; how we can effectively leverage it to improve a team’s output (rather than damage it); and key takeaways to keep in mind.

Listen on Apple Podcasts

Key Takeaways

  • What is velocity? Why is it important?
    • Velocity is an output-based metric that measures what the team typically does/how much they do over a certain period
    • In Scrum, velocity is usually measured within Sprints
    • Velocity is history; not what you hope for (i.e. it is a past measure)
    • Velocity is a great tool for teams to understand what they typically do in a given Sprint and use it as a measure to know what they could do in a future Sprint
    • Scrum teams who are truly self-managing can use velocity as a way to think about what they might do in their upcoming Sprint given what they’ve done in the past
    • Velocity is similar to the term “velocity” used in physics (i.e. in physics, velocity is not just speed; it’s speed and direction) — If your teams don’t have direction, the speed at which they do things is meaningless
  • How is velocity measured?
    • There are a number of ways you can measure velocity (from story points to a “number of items completed” approach, etc.)
    • Though velocity is often expressed in “points”, it isn’t needed to measure in points (velocity is simply how much stuff you have done in whichever way you want to measure it)
    • Points are not a forecast or the capacity that the team is expected to hit
    • The pressure to measure in points can actually be more effort than it’s worth (if you’re already measuring in days, why use a conversion cart of days = points? Use what the team already knows and is working by)
    • Measure in as small of pieces as possible (the tinier something is the more accurately you can assess how long it is going to take)
  • Velocity anti-patterns:
    • Velocity can be one of the most abused metrics in all of software development if the wrong person in power gets a hold of it
    • Sometimes when leadership gets a hold of velocity metrics, they punish or put pressure on teams when they don’t meet the same markers that  they did in the previous week/month/Sprint
    • Some organizations see the Scrum Master’s role as making sure that the team is constantly increasing its velocity
    • Assigning “points” to people on the team (velocity is a team measure; not a measure of individuals)
    • Just getting stuff done that isn’t moving the product forward may make your velocity look great, but really you’re spinning your wheels and not going anywhere
    • You shouldn’t be managing velocty; velocity should be helping you manage other things (such as what teams can do to forecast)
  • Why can measuring velocity improve your teams?
    • As a Product Owner, you can use velocity to forecast beyond the next Sprint
    • You can use it as a measure to revise and adapt each Sprint
  • Key takeaways to keep in mind:
    • When you change the team composition, the velocity will be affected and most likely drop (even if you are adding someone because they need time to get used to working together)
    • Velocity is not about precision (through craving certainty, we want to apply a number measure to velocity) but teams begin to beat themselves up and spend too much time in refinement activities to have a stable velocity (rather than actually doing the work)

Mentioned in this Episode:

Transcript [This transcript is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]

Intro: [00:03] 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] Welcome to this episode of the Agile Coaches’ Corner podcast. I’m your host Dan Neumann, and joined today by AgileThought principal trainer and Professional Scrum Trainer, Sam Falco. Thanks for joining and Sam.

Sam Falco: [00:28] Always a pleasure.

Dan Neumann: [00:30] It is. You looked around for a second, like maybe there was somebody else joining.

Sam Falco: [00:34] Well, you know.

Dan Neumann: [00:38] You were hoping, but no, Hey, but if they did, they do it quickly because the theme of today is exploring velocity.

Sam Falco: [00:48]
Ah, velocity the early form of the bicycle.

Dan Neumann: [00:55]
We’re not doing velocity. It’s strictly the big wheeled bicycles.

Sam Falco: [01:00]
It’s actually a generic term for any wheel. So technically a bicycle is a velocity, uh, but typically associated with those, yeah, those gigantic, uh, wheel with a little tiny wheel in the back, uh, types of things.

Dan Neumann: [01:14] But the common thread here is they too wanted to go faster much like they did absolutely measure velocity. So, um, why don’t you give us a little crash course. What’s this velocity thing anyway, how did that come from this story?

Sam Falco: [01:27] I actually don’t know the history of that particular term. I do know that I, I believe it is one of the most abused metrics in all of software development. Um, this is, oh man. When I first encountered this, it was, it was purely a, essentially it was a tool to abuse developers with.

Dan Neumann: [01:53]
And how have you seen this manifested in, in, in abuse? We could see if we’ve seen the same horrors of velocity. Yeah.

Sam Falco: [02:01]
There’s so many different ways. When, when we first encountered, when I, my first Scrum team, we now we were starting out, uh, and we very quickly understood that we were doing it wrong basically and fixed it, but it was like you did 25 points last Sprint, you knew darn well, better do 25 points or more this Sprint, or we will know why. Um, oh yeah. Uh, that kind of thing, not quite as harsh, but very much like, oh my gosh, you know, it’s failing. Uh, and then I’ve also seen, I see this in job descriptions that the Scrum Master is part of the, the role is to make sure that the team is constantly increasing its velocity.

Dan Neumann: [02:43] Let’s back up for a second. Cause I think we’ve dived into the horrors of velocity. Like those movies, where they show you the awful thing that happens and then they back it up three months earlier. Let’s back it up just a little bit. And then three months of, uh, three months earlier, velocity, what, what is, what was it intended to be or how would you define it for folks who are maybe, um, familiar with it differently?

Sam Falco: [03:10] And you know, I really tempted to go off on another velocity rant right now, just, just to get your goat. So the idea behind velocity is simply to measure what the team typically does measure. It’s, it’s an output based metric. How much stuff does the team do over a certain period of time when associated with Scrum? Obviously it is usually sprints I suspect, but do not know that it emerged separately from Scrum. And so it might have been some other unit of time and then Scrum, just sort of, as it does absorbed a practice that was helpful, but in a nutshell it’s how much stuff does a team do.

Dan Neumann: [04:00]
So a measure of output, and I do most often see it with Scrum teams, like you were describing for Kanban teams they usually are more specific about things like throughput or they’re counting items. So they use a different term than right save velocity. So yeah, a complimentary practice to the Scrum framework in a lot of instances.

Sam Falco: [04:23] Right. And then that leads to, it’s a great tool for teams to say, Hey, here’s, here’s what we typically do. What do we think we can do this Sprint? Given what we know about our past performance, it becomes a horror show when other people get ahold of that metric and start using it. But yes, Scrum teams who are truly self-managing and allowed and encouraged to be so can use velocity. As I said, just as a way to think about what they might do in their upcoming Sprint, how much stuff do we think we can do given what we’ve done in the past and what are our current situations.

Dan Neumann: [05:06] So teams in sprint planning? So Scrum team and sprint planning, they often will come up with a prospective sprint goal. They will select some backlog items that aligned to that. And one of the ways the team might go, we have too much, we have some more room. We’re not sure, or we feel pretty good would be to look at their historic performance in the past, we’ve delivered a velocity that looks like X, Y, or Z or X plus or minus or whatever, and compare it to what they’re forecasting for the current Sprint and use that as a way to build support with the product owner about whether do we have a reasonable plan and a reasonable pile of work.

Sam Falco: [05:53]
Right. Could we do more or did we just pull too much in, if you only look at velocity that causes a problem because what some teams will do is pull up a chart that shows usually it’s a bar chart that shows their historic velocity for the past. You know, X number of sprints worked with one team that had been together for a while and they had a really lengthy amount of time on theirs and then do some sort of math and say, this is our number, but it’s also worth looking at, so what’s going on in our team in the next sprint. Do we have people on vacation? Are we onboarding a new team member? Are we working with some stuff we’ve never worked with before? And we want to reign, you know, reign it in. Do we have, uh, trainings coming up? Are we all going to be out at a conference? Really looking forward to being back at conferences soon, I had to go out and buy t-shirts with my own money recently. And it just ticked me off.

Dan Neumann: [06:54]
You can sign up for a nice 5k and get yourself a pretty t-shirt that way. That’s another, that’s another way to do that virtual now. But for velocity, I think of what you were describing, the metaphor of running comes to mind as, as I like to do sometimes. So you do a race, you know, how long is it going to take to do a mile? Well, um, I don’t know, eight minutes, let’s say, oh, the next mile is uphill in sand. Probably going to be slower. So the fact that my past average was X doesn’t mean that I can be expected to do that predictably forever into the future.

Sam Falco: [07:38] Right, right. Um, someone and I’ve lost in the midst of, of, of my memory told me, uh, compared velocity to the physics term velocity and pointed out that in physics, philosophy is not just speed. It is speed and direction. And that if your teams don’t have direction, their velocity is meaningless. If they’re just doing a lot of stuff.

Dan Neumann: [08:04]
I’d love that. And want to pause on that one for a second, because yay. We did 50 points of what yeah. Who cares? Yay. You know, but when people get excited about, oh, we have to hit the number or patting themselves on the back solely for having a velocity number, but they’re not talking about business outcomes or impact or what value has been delivered. What a waste of time.

Sam Falco: [08:35] Yeah. I watched a team do that. Got so intent on delivering the velocity that they had been informed they should have, which is, uh, we’re gonna, we’re gonna come back to that, that they were, they were going through the product backlog. This was a massive scaled effort and picking stuff that they, they knew they could do. And delivering these little petty things that were scattered throughout the product backlog, maybe for epics, that hadn’t even begun yet, just so they could say they got stuff done. It wasn’t actually helping move the product forward. Great. Your velocity is high. No, it’s not. You’re spinning your wheels. You’re not going anywhere. So the, the danger where you, we talked about the horrors, the danger is then that, that velocity becomes a metric, which we are managing toward rather than a metric that helps us manage other things that helps us manage what we can do to help us forecast.

Dan Neumann: [09:47] So the horrors, these you’d mentioned in anti-pattern or somebody other in other, in the organization gets a hold of the, the thing that’s easy to quantify. And then expects that to be the constant pace that team maintains at least, and then at least, and managing for that metric versus business value or something else. Right. And then, uh, now that we’re three months later, we can go back to the job posting you saw where the Scrum masters job is to generate ever increasing velocity.

Sam Falco: [10:20] Right. I think we’ve talked about this or touched on it in some past podcasts, because I think I’ve mentioned it that, yeah, that was a w I want all the teams to be increasing their velocity by 10%, every sprint. Well, they got that because the teams, just, anything that had been one story point became two story points and look, we’ve, we’ve increased our velocity and it was not quite so blatant because they would actually do the math. Okay. Well, last sprint, we had 50, we need 55. So these five, one point story are now twos, or this two point story is going to become a five. And this other one is going to become a three and et cetera, they would actually they’d sit there. And game-ify a game this out, rather than I gamify a game this out, what, what would get them the number that would keep people off their backs.

Dan Neumann: [11:08] Let’s talk about. So we’ve talked about points a little bit is velocity just points, velocity.

Sam Falco: [11:15]
Well, it’s like you can have velocity of those miles per hour. You can have losses kilometers per hour, or you can have velocity that is expressed in light years. The unit can vary very often. I see it described as a function of story points. Usually just truncated two points. And the whole part of it being associated with user stories gets lost. I hate points. I absolutely hate points. And I try to coach teams if they have to use points to not take them very seriously, to get to a point, no point, no pun intended to get to a circumstance where they can say these 10 or 12 items are about the same size or this item will fit in a sprint with a dozen of its friends. And don’t worry too much about the points and if the organization’s requirement to put points for some points on it, and don’t worry about it.

Dan Neumann: [12:14] So shifting towards more of a number of items completed, right approach.

Sam Falco: [12:18] That’s perfectly acceptable velocity, uh, metric. I think you mentioned the last time we talked a function points as a way of measuring teams outputs. Like I suppose you could do that. I don’t do that. But my point is, if I say 0.1 more time, I think I’m just going to just smack myself on the head with my iPad.

Dan Neumann: [12:44] So your point is.

Sam Falco: [12:45] My thesis is. My argument is don’t sweat points points. Aren’t velocity. Often velocity is expressed in terms of points, but they’re not the same thing. Velocity is just how much stuff have you done. However, you want to measure that as, uh, our colleague Steven Sladoje often says he borrows a term from an old star Trek episode. How many quatloos does this team do? And people look at what’s a quatloo. And he says, exactly. Yup. So don’t get too hung up on that.

Dan Neumann: [13:31] This is not a forecast. It’s not the capacity of the team, a number they’re expected to hit. Right? Right.

Sam Falco: [13:39] Yeah. It’s just, it’s just, here’s what we’ve, we’ve done. It helps them in planning. It can also help. They realize we’re making this free Scrum centric, but Scrum of course, is what so many people say they’re doing.

Dan Neumann: [13:52] Um, so, uh, we are making it scrim centric, but let’s, um, it is a complimentary practice to Scrum. It’s not in the Scrum guide.

Sam Falco: [14:01] Product owner, uh, is where I was going with that it product owners can also use velocity. Yeah. It’s not mentioned in the Scrum guide at all. It’s just a complementary practice that many, many Scrum teams use, um, product owners can use velocity as well to forecast beyond just next sprint. They can be really careful to not say, well, my team’s velocity is on average 25, so they’re going to do 25 per sprint. So in 10 sprints will be 250 points farther along in the product backlog, whoa, there fella. That’s not true. We need to look at something a lot more subtle than, than just that simple mathematical formula. But, um, you were saying.

Dan Neumann: [14:43] Yep, well, I will. Yes. And what you’re saying, so looking at an average is one way of then forecasting into the future in a very crude way. I also like then creating bands with, you know, what’s, what is an example of some of the faster your team has moved and using that as a way of looking forward, what are examples of some of the slower, lower velocity Sprints in the past and use that. And so maybe they’ve had some real stinkers that were 10 points, sprints, average, 25, some highs that are 35, well you multiply 10 by 10 and the three 50, 35 by 10, you get a band from a hundred to three 50. So your next a hundred points are probably pretty safe unless you’re going to lay 10 eggs worth of sprints that are low velocity historically in our row. And you can, you can forecast and set expectation that way.

Sam Falco: [15:40] And you’re going to revise your forecast. The very next sprint take. That’s another factor that gets missed as people say, oh, we’ve laid out this plan for the next 10 sprints. And they forget that you’re going to know more than the next sprint. So when you get there and you can say, well, we laid an egg again, because servers went down and this, uh, you know, we didn’t do as much because for whatever reason you don’t say, well, then we have to make up that those points we have to make up the velocity. No, you just have to look at what you’re going to do and recalculate where you might be. Maybe the teams will get a burst of speed, but you cannot count on that. And that goes back to the, we’re going to tell the team, the velocity we expect from them. You only did 10 last sprint. You normally do 25. So we needed to add, you need you to add five more points for the next three sprints to catch up. What? That’s not how this works.

Dan Neumann: [16:34] Yeah. And it’s not how that works. And I think this is another reason why we would advocate not to slot stories into future sprints based on an anticipated velocity, because now you’re anchored, but you have the forecast. You don’t have to actually assign stories into sprints, but your forecast can be more easily revised. If you are keeping the backlog, keeping aware of the pace, the velocity at which you have demonstrated an ability to perform and using that to quickly and easily revise the forecast.

Sam Falco: [17:07]
Because teams will also look at their, like, let’s say they have a velocity chart bar chart that shows, and they might look at it and say, okay, yes, on average we do 25 and I’m trying to pick numbers that I can do in my head cause English major. Um, but Hey, look, look back at sprint six. See that sprint where we only did 12. What happened there? Oh, well we had to bring in new servers, uh, and things went up, oh, don’t we have to do, uh, an exchange server upgrade this sprint. Should, is that going to impact us? Oh, you know, it might let’s bring in less or conversely, Hey, what happened in this sprint where we were, we did 35. Oh, that was because we found this new workaround, et cetera. Uh, oh, well, I’ve been researching this new tool and I think we’re going to be able to go a little faster and it’s going to make a lot of things a lot easier. So maybe we bring some more in keeping in mind, as I always harp on teams are committing to a goal, not to scope. So let’s say, you’d think, you know what? I think we’re going to be able to do 50 and you bring in twice as much as you normally do. And three days into the sprint, you go, well, that was a mistake. So you renegotiate the scope as long as your product and your, a sprint goal remains unaffected.

Dan Neumann: [18:27] Are you ready to get edgy Sam?

Sam Falco: [18:29] Let’s get edgy.

Dan Neumann: [18:30] What about a scenario where we have points for people on the team? I mean, does that sound like a good idea to you Sam?

Sam Falco: [18:40] If I could reach you. I would hurt you. No, it’s a terrible idea. Velocity is a team measure. It is not a measure of individuals. First of all, we, especially in Scrum, it is the team works as a unit. Not everybody works on their own little scope. Um, I have seen that be done that, you know, so-and-so is a, is a five point developer and so-and-so is an eight point developer. And then they get compared and the worst, uh, example of this, I, I ever saw this, uh, I think I wore some enamel off my teeth, grinding them when this, I can’t remember what his title was, but it was Scrum. They, they called it Scrum, but it wasn’t anything like Scrum. Um, but he said, well, uh, we need, uh, Lakshmi to work on something. So we’re going to steal a little of her velocity for this other project. And then we’re going to steal a little velocity from Nico as well for this other product. And I’m like, that’s oh, any, any DC comics nerds out there going to get one I’m about to say, but there’s a concept in, in the flash where you have the speed force and you can steal speed from somebody else. Like that’s is that what you’re talking about? And, uh, he did not have a DC comics background. So he just kind of looked at me, frog, like, and blinked at me, but it stopped him long enough for me to say no, that that’s not going to be an effective way to manage this, uh, velocity as a function of how a team works together. And so you cannot chop it up and say that Anthony is a five-point developer and Ebony is an eight point developer. And so we’re going to put Ebony on the hard stuff. No, you’re going to work as a team and they have a velocity together. And before I forget, you also have to keep in mind that when you change the team composition, your velocity is going to change. In fact, it’s going to drop, even if you add somebody, because they’ve got to figure out how to work together, there’s a human side to this. So don’t think that you can outwit, uh, is it Brooks law adding late?

Dan Neumann: [20:47] Uh, it was the mythical man month guy. Yeah. I forget people do a late project. Only makes it later. Yeah. Um, I think it was Brooks, but uh, and then there’s uh, yes, it is Brooksville. Oh, you ruined it. I was going to say, there’s always, there’s always Kohl’s law fuel calls, laws. It’s a cabbage shredded carrots all mixed up coleslaw. Yeah. All right. So bringing it back though, I have a kindred spirit actually, to what you were talking about with teams and individuals, which is sizing stories based on who’s going to get them. Right. Oh, it’s a, which I think is all an example of really equating points, a unitless measure of relative effort to days or hours or, yeah.

Sam Falco: [21:37] Yeah. I mean, if you’re going to, if you’re going to measure in days than just two days, I’ve also heard that like, we’re kind of veering off the topic onto estimation, but they’re so tied together, velocity and estimation, but I’ve heard that where an organization will say, well, we’re agile now. So we can’t predict how big a project is based on hours or days anymore. Now we have to do it in points. And so they will come up with a conversion chart and you can tell everybody, everybody in the PMO is still thinking days, but they’re going okay. I can’t say days anymore. So these days multiply, this is 733 points. Might as well just use the days because everybody knows what they’re talking about.

Dan Neumann: [22:25] That could be fine. Nine estimating days is a legitimate approach. I did not see that forbidden in the Scrum guide, there are human difficulties with forecasting, the future where we tend to be optimistic and think things are going to run well. That’s part of the problem and a reason to do, uh, the reference class forecasting using points, Hey, we did a thing. It looked like this. The new thing that we, it looks a lot the same. They’re probably about the same effort.

Sam Falco: [22:56] Yeah, of course. In software development, that’s often a losery too. This thing looks, it looks similar. And then we, you know, we open it up and there is a avoid inside that that sucks us in. And it wasn’t at all. Like the other thing that’s not up, that is not a problem that you solve by coming up with a better estimation technique. That is a problem you solve by making good ensure you break things down into smaller and smaller pieces, deliver tiny little pieces of value because the tiny or something is the more accurately we can assess. How long is this gonna take? Or what’s it gonna take to get this done?

Dan Neumann: [23:36] Let’s pull on another thread. Okay. Let’s be, let’s be edgy again. Okay. There’s this, there’s a certain popular framework for scaling that advocates, normalizing story points as a way of getting started. When your teams don’t have a historic velocity and they assume a number of points per person per day, what do you think Sam?

Sam Falco: [23:57] On the surface, it’s not a terrible idea. You’ve got to make a guest somewhere. It’s not terrible. That was actually the answer.

Dan Neumann: [24:06] That was the answer I was going to pick. That’s a terrible idea. Um, I’ll give you my alternate plan.

Sam Falco: [24:13] You’re going to have to make a guest no matter what so sure. The problem that happens is that formula then becomes inevitably baked in that’s our formula. That’s, that’s what we tell the team. You have six developers and you are doing two week sprints. So that’s six people for 10 days. So that’s 60. So do 60 points if I got the math. Right. God knows. Um, and then, then that becomes, okay, well, we’re, we’re a 60 point team because we have this. And again, it’s not a per person measure. Um, if you can, if you can say, well, let’s just throw this number out there and see, I guess it’s not, I know. I surprised you by saying that sometimes I like to be contrary, even with myself, I actually don’t like that idea. I think it’s terrible. Um, I’m just trying to see things from another point of view.

Dan Neumann: [25:00] I see why it’s attractive because it’s simple and it solves a problem. We don’t know what the velocity of these teams in a multi-team program is going to be. We don’t know how to compare teams. We don’t know how to do all these things. And I would rather take the stance. If it’s a brand new team, by the way, this doesn’t happen very often where you literally start from scratch. So it’s a problem. You have to solve once, right size, relatively sized, some backlog items. If you want to guess what your philosophy is going to be, you could mock plan them a couple sprints in and play a little game of let’s imagine. And then you iterate. And in two, three, four sprints, you have two, three, four samples and you now have a actual empirical measure of how your team’s performing problem solved.

Sam Falco: [25:51] And you said something there. We were trying to figure out what our velocity is going to be. Velocity is history. As I said, the beginning velocity is history. It is not what you hope for. Um, it is a past measure. So yeah, you don’t know what your teams are going to be able to do until they get started. So why not let them guess on their first sprint, how much they can do. Remember we are committing to a goal, not a scope, let them realize they’ve put too much in or too little in or however that’s going to work and adjust things. And then as you said, build some, build some data that they can then make some educated guesses with. I coached the team a couple years back and they were really caught up with, oh, what should our velocity be for my first, for our first sprint? And I said, how about this? Put one item in your, in your sprint. Just one, this is what you’re trying to do. I also had looked at their one item and thought, that’s enormous. Put one story in and see what you do. And they got in and they started realizing this was huge. Talk to their product owner, renegotiated the scope of that, busted it up into a bunch of different things, delivered one thing by the end of the sprint and in the next sprint, they said, okay, we have a pretty good idea of what we can do. And now we took that one item and broke it down and we think we can do three of those. And they did three of them. And that worked for a little while until unfortunately, someone outside the team said, what’s your team’s velocity. And didn’t like three or four items per sprint because while we don’t know how to forecast with that, how are you supposed to tell people when you’re going to be done?

Dan Neumann: [27:30] So let’s, uh, we’ll come in on the, uh, the glide approach here to finish. I don’t know if there’s a bicycle example, we’re going to coast through the finish. There we go. Our velocity, we’re going to coast the philosophy to the finish line here. Let’s touch on expectations that the velocity will be precise, 51 points per sprint, or that it will somehow stabilize or normalize or take on some other predictable, easy for an English major to do the math type of type of structure.

Sam Falco: [28:04] Thank you for that. It’s again, it’s not about precision people see the numbers and they think it means something that it doesn’t and we crave certainty. So we have the illusion that we can, we can apply a number. It means something and it means this. And so then we can get precise and teams start beating themselves up. That’s when you’ll start to see them spend way too much time in refinement activity, for example, cause we gotta, we gotta get the estimates right so that we can have a stable velocity. All right. And are you actually getting anything accomplished as far as delivering value while you are spending way more time than you should in refinements, maybe you should not sweat that you’ll get to it when you get to it. You’ll, you’ll figure out what you can do.

Dan Neumann: [28:49] It is a good enough estimate for the purpose it’s trying to serve.

Sam Falco: [28:54] Absolutely. When I go by lumber for a woodworking project, I don’t sit there in the lumber store and do math in my head. Well, because we know that I can’t do math in my head. I don’t rip out my phone and bring up the calculator and start going. Well, you know, the, the, the cuts are going to be this many at this length and I’m going to have this much curve left. And so no, I go, all right, I’m going to need a three, two by fours for this. And I’m going to want a sheet of plywood and I may have done some of those calculations ahead of time. But yeah, the point is I’m not looking for, well, you know what? I only want to buy a 92 inch piece of pine instead of the 96 inch. No I am going to buy a two by four. If I have a little waste, I have a little waste.

Dan Neumann: [29:37]
I love it. I don’t want there’s in there, but we will close before we go down a rat trail of waste. So velocity is a historic measure that can be useful for forecasting.

Sam Falco: [29:54]

Dan Neumann: [29:55]
Yeah. How do consultants make money with something that’s simple.

Sam Falco: [29:58] Because people don’t listen.

Dan Neumann: [30:00] Oh, that’s right. Well, and I think it’s because a lot of these other things are attractive. Let’s expect it to be stable. Let’s expect it to normalize, let’s drive a team to have, you know, increasing velocity that the opportunity to abuse such a simple and powerful thing is, is just, it’s really easy. It’s just right there. So you can encourage people to avoid that.

Sam Falco: [30:26] And it’s that desire for certainty in an uncertain circumstance that, yeah, it’s comfortable, right? We want that comfort. You need to learn and organizations need to figure out how to handle the fact that we are not engaged in a certain endeavor. We’re just not. And if you want that, go get involved in construction. We’ve been building houses for a long time as a species. We know how to do that. Pretty well. Software development, no.

Dan Neumann: [30:59]
In that point, the construction of things that have been constructed a lot in the past, you know, there’s new edgy types of construction that are more risky, more unknown, perhaps, but for sure, yeah. Sam, thank you for the exploration of velocity. And hopefully people are able to use that in the uncertainty or to help navigate the uncertainty that they’re experiencing in the complex endeavor.

Outro: [31:23]
This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views, opinions and information expressed in this podcast are solely those of the hosts and the guests, and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips for this episode and other episodes@agilethought.com/podcast.

Stay Up-To-Date