AA117 - You Should Do Time-Based Estimates (Article Review)

We're gonna try not to rant on this podcast. We won't. I'll try that hard though. I came across this article, I was doom scrolling LinkedIn as, as one

00 AM and I saw a post put up by an, an individual that I will not name cuz we're not trying to blow this individual outta the water. That basically was, saying the opposite opinion of the Roadmap podcast that we did where the position I was taking was I don't give dates, I would rather focus on outcomes and knock out the outcomes in order of their priority to the business and their value to the business. And this, article, at least at first glance, maybe I'm wrong. So that we're gonna dig into it here and find out, this article seemed to take the opposite stance. Om has not read, read the article yet, so we're gonna read it together. I have not here on the podcast. And, again, I've cut out the names to protect the innocent, but like not that innocent. The, yeah, the innocent may or may not be. let's dig straight into the article, okay? Okay. Like I said, I'm not trying to blast the author, not naming names. That's, that's part of our working agreement. He introduces this article with a shot across the bow, it's the equivalent of opening up your, sorry. Like, I guess I'm monologuing and before we even start the, no, I see this as a cry for attention, honestly. Well, that's, I mean, it's like any YouTuber who opens a video welcome everybody. Like it's this, it's the equivalent, like he's opening the article with the equivalent of that Like that should be the opening of this podcast, by the way. Really? Yeah, it's true. I agree. Yeah. anyway, he says, I hear more voices saying there is a little point in doing time-based estimation on how long building software will take, and thus we should just stop doing it. Quote, let's just use story points and estimate complexity, but not the time. End quote, end quote. Let's just try hashtag no estimates. End quote. I, I like that he's throwing shade on no estimates in the first two, two sentences. Mm-hmm but that's only because I, I think it's funny that like, yeah. All right. End quote, no estimates, our suggestions. People around me recently brought up, I'm personally skeptical of both approaches. While I do think that doing time-based estimates is really hard, it comes with so many benefits for those who keep doing it. unintelligible sneeze-like sound. Sorry. Oh no, you got, did you sneeze? I don't know what no, no. I know. I just called it BS right there. I mean, yes, time-based estimates are hard cuz you don't foresee the future. You don't know when things are gonna happen. However, asking people to do that just like he's doing. Ishk. Who knows? Who, whomever, whomever it is, whomever it is that is advocating this, please stop doing that. What a great start that was. Yeah, it was. That was, it was even, it was too sassy for me. And that's how you know, That we are on the right track. All right. The next piece of the article, I attribute much of my success in engineering to giving. Oh boy. Here we go. I knew you were gonna say that when you read. Oh boy. Read that part. Boy. It's coming off a little arrogant, but I'm gonna keep reading. I attribute much of my success in engineering to giving estimates on software complex projects. He means complex software projects. Oh, okay. Was he drinking when he No, no, no. That's let's just give him the benefit of her, the benefit of the doubt. It says his success in engineering. It sounds like he's had a lot of it from, or she Sure from what they're saying, and they're saying they give estimates on complex software projects. And then also delivered to those timelines. All right. Here, we like, let, let me read on, when I was working on Skype, I was part of the Xbox One Xbox One is not, they, they, they really screwed up that branding. If I have to say so myself because one xb. One XBONE?!? Come on guys. Oh, I know, I know. Like you think of all the logos that you can come up with. XBONE. Come on. Some good and some really not the opposite of that. But Xbox One launch team, microsoft finalized the Xbox oh one launch date based on estimates from the 100 plus teams working on XBONE including ours a year later a year later, we, we launched on the pre-announced day without significant hiccups and without major fanfare and with, oh, you haven't, is that true? Xbox One launch Without significant hiccups. Yeah, without significant hiccups and with major fanfare. I don't think that's true. Okay. All right. Well you know what, everything I read on the internet is true, so let's continue. Of course, AF After XBONE, I worked on launching Skype for Web. Here we ended up beating our original estimates leaving more time for experimentation before the worldwide launch. When when I joined Uber, we had an internal deadline to rewrite the launch of the new Uber Rider app By the end of 2016, we also pulled this off after a few months of development hitting our previously set launch date. Let's stop right here for a second because when I originally read this article, I thought he was lobbying against the outcome driven roadmap, like for an output driven roadmap. I thought he was lobbying for that, but now that I've read his paragraphs like I've, I've kind of softened where he's just being dictated milestones and he's not talking about any scope or whatever but he's providing those milestones like x X XBONE one, for example, like when they launched XBONE one, like it had tons of problems Oh, sure. Tons of problems. I can be like Cher and turn back time right quick to, to, to go and Google problems with the original XBONE launch, you're gonna find many pages, I'm sure. I'm gonna find tons like games that won't even play tons of stuff. Sure. That backward compatibility, they didn't even do. Like, I know I'm gonna find a bunch of stuff and I'm sure that if I were a product manager and I were applying product management practices to say, what can we cut to hit this date? If that's where he is going with, this, I don't think it's as significant as I expected it to be when I wanted it to be a subject for this project. Yeah. But I haven't seen that yet, so I haven't seen any notion of just, just to focus on the the here and now, the V MVP kind of thing. Right. What I've seen instead, this is my take at least, is. We gave him dates and we met him. That's what I'm saying. Yeah. So, so I you say, well, he was dictated dates. No, I think he's dictating the dates, is what I'm saying here. You know, I gave him a date and we hit that, and then we had time to experiment later. I don't know if one, that's what I'm saying. it sounds great from the purpose of like getting your name out there on, on the internet with like a hot take. But The, the issue is like I have just as much experience as this dude does working on software development teams, and I know that the one person doesn't just sling out a date and everybody's okay with it. Unless you're a dictator, of course. No. Yeah. I mean, that, that could happen. But the, the majority of times you have to settle on a date. It's a sort of a negotiation again, unless your management's coming down and saying like, we've set the launch for January 1st, 2025, and you've got until that time to figure it out, and whatever's in is in, whatever's out is out. I get So those people are these the, the people that are suffering? Yeah, I get that, but I, I'm not seeing that at least thus far in, in the article I'm seeing. This guy's saying I forgot the date we met him. That's what I'm seeing. Yeah. And, and if he did great, right? Maybe he got lucky or she Well you know, the, again, we can read on, maybe we should just, yeah, we should read on, just get through this. But software estimation, even when you're doing hour based estimation, which I have done in my career, doesn't work this way. One person doesn't just sling out a date outta the air and then the whole team comes along with it. Now, you, he may be rewriting history a little bit to say the team picked the date together, but I committed it as part of the team and oh, we all agree that this was a date. Al, although the alternate that may be happening here is I have had development managers pick a date because they're under pressure from the business, and then they come to the team and they say, this is your date. the old project management, the padding thing of like, sure, you have to deliver it this week because next week we are meeting with the client and then the week after that they're gonna roll into production. So I need a little padding in case you go over by a couple days like that, that type of thing yeah. Number one, that was, that was my number one scenario. Which, so there's two scenarios. This might be a third scenario. This might be, and I've worked for people like this, is they throw out a date and then when the team doesn't hit the date, they just throw the team under the bus. And then because they're in a leadership position or a management position, management position, or a lead position of should know better. Because they're in some sort of elevated position from the typical worker on the line they can go to management and say, it wasn't me, all these people, or that it was that person. Blame that person. And there are some people that are, are in several development teams who have made a, a pretty good career off of this type of operations. whenever something goes bad, I blame somebody. Whenever something goes well, I take care. I did it. Bingo. Absolutely. We've all seen that. We've all seen that in any work of life, right? Any kind of work that we do, we've seen people like that. Mm-hmm. So yeah, they, they're out there. Right I don't know. Let's, let's go back and read on a little bit more, because I'm still on the fence about whether he was dictated dates or he actually dictated dates. Yeah. Have you noticed how Apple ships most of their Big Bang projects at WW d c a date that they commit to far ahead. How Facebook unveils many of the features at F8, how Google launches products at io. All these launches are date driven because that's a great way to grab people's attention and extensive press coverage. Let me read the rest of this before we dig in. Yeah. Publicly traded companies plan and budget based in quarters. They also decide how much to invest in projects and people after asking, how long does it take to launch private venture funded companies try to get new features out in time to help with the new fundraising round? Yes. Some businesses are not very date different, but they are rare, private, profitable lifestyle businesses, and some governments are perhaps the best example of entities that don't care as much about dates. That's interesting that he's going down this road governments are the most date driven. That's right. I was just gonna say. Yeah. Yeah. They're the most out of any of these I would say every, every example he just gave apple, Google, Facebook launches they're working on the top priority and it, it, they, they get as much done in the time given on that priority until it goes to launch. It's funny. People used somebody had used this example again on LinkedIn about apple delivering to dates. They, they were, it was a similar example, but it wasn't exactly this example. And they were talking about the original iPhone. And I was like, this is such a funny example, because the original iPhone, in the original demo, the original iPhone, Steve Jobs had a bunch of, he had a bunch of iPhones sitting on the table and he, it was like a little shell game of, of, I'm gonna use this one to make a phone call and I'm going to make use this one to browse the internet and I'm gonna use this one to do whatever. Because the, the technology just didn't work together. So the, the teams working on those had to create a phone that only did that one thing, and it was only some, some magic in front of the press. Same thing happened with Nokia, by the way back then. Yeah, I agree. This is kind of what we covered in our last podcast, where we're talking about agile purists and, and the detractors and what, what they try to pin on purists and whatnot. This is like, People know a little bit about how software development teams work, so they're trying to bend reality to fit their viewpoint. And it's just like every example given here is these companies aren't doing oh you're gonna do this by this date. And then when you're done with that, you're gonna do this by this date. And when you're done with that, I got another thing for you and a date already picked out. These companies don't work that way. They don't. And, and you know, sometimes you'll see companies that say, we're gonna deliver these features, but in this release we're only delivering these features. These other ones will come later. Mm-hmm. Right. That's very, very common out there. He doesn't seem to, or she doesn't seem to acknowledge that. Right? Yeah. So it's not like they are date driven so much as a launch happens. Right. And what's in the launch is completely flexible based on what the company has ready at the time, what they wanted to do. Sometimes they communicate upfront. And these are what I like to call forward looking statements as the finance companies call them, right? Yeah. Right you'll see that whenever you see any financial news, they'll say in the next quarter we will be blah, blah, blah. These are all forward looking statements. When I was editing the, the roadmap discussion where I said, well, you should you should only do outcome-based roadmaps. Right, right. When I was editing that discussion, I thought to myself the, the valid case we didn't talk about was sometimes, sometimes someone will go to a project manager and say, Hey, I'm thinking about involving us in this software project. I'm thinking about it. I've not committed any money, I've not committed any whatever. But if I'm gonna go lobby for a budget, I need to know how big a team I should hire, how many how much money I should ask for, how long should I ask for the timeline? And, and there are some things that, that Agileists truly would have difficulty just conjuring out of thin air. Yeah, yeah. Using their conjuration magic while playing lizards and wizards. That's right. Yes. I like Liz and Wizards Any agilist worth their salt would never say this can be done by this state. They would say it can be done between X and Y. Ah. So they always provide a range otherwise. Ah, but that they're gonna be wrong, but they're not, they're not looking for promotions, you know? Yeah. Well that's true too. which is fo for another podcast. That's right. What do organizations reward? That's right. And those are the behaviors they get. Right. So maybe we'll come in come into that at, at a different date and time. I so look for that. I offer into evidence a real exchange from my experience as a member of development team. Is how long will this take to get done? I think it'll probably take a month. A month? Really? A month? I don't know. I think you can get that done in two weeks. Okay. Well okay. Two weeks. I mean, whatever you say, like we'll do it. Mm-hmm. Okay. Like that, that's, that's the estimates he's talking about right now. That's so, yeah, I agree. First of all. Right. Secondly, I wanna say this to, to your anecdote spot on. You could do it in two weeks. You can do it one week. What quality are you getting? Look, we make the date. Yeah. There's some little loose ends over here and there, and some rough edges. We'll take care of that later. Aka, tech debt later never happens. Sure. Right? So you have all this crap on the backlog that you know you need to get to at some point, but you won't get to it because you keep rinsing, repeating the same thing over and over. Until some customer that says, this stuff is terrible, it's hurting us, right? And we're gonna stop paying you. That's when you pay attention to TechNet, which by the way, all of that is avoidable if you did the thing right to begin with. I rest my case. the defense rest. Let's see if we agree with anything in his article. All right. He says, good communication is more important than good estimation. I have missed many of my estimates and it was rarely a big deal. I, I, listen, I, I kind of agree with that. Let me read the rest of it before we responded. Yeah, please do. While people and businesses are date driven, delays are common in any part of a company. If you think delays only happen in tech parts of a business, talk with people in operations, marketing, recruiting other functions, regardless of the org and function, people tend to be overly optimistic in their estimates for work they've not done before. Ever heard of building construction, project overrun a government initiative to be late, Brexit being delayed again. Where there are people, there are delays hang on, I think we need to stop there because, okay. All right. Yeah. What he's saying is it's, it's rarely a big deal. The problem is this, whenever you provide an estimate, it is misconstrued upon delivery the problem, which is when they hear it as a commitment. Right? So the word estimate is just that it's not a guarantee, it's an estimate. It's a best faith effort of when we're trying to do something, which is why I say people that are savvy will never give a a point in time date. They'll say between this date and that date, right? Because they will weigh in the risks, right? That lie in delivering that, and therefore they're guarding themselves a little. But in most cases like this or others, even when people say, here's an estimate, I'm saying it's an estimate, but what leadership management, our hearing is, Oh yeah, you're gonna deliver by then. So when that doesn't happen immediately, it's, you failed. That's what happens. I it's, it's never not a big deal, by the way. It's always a big deal I'm trying not to dig into the privilege that's being exuded from this article. When you work for companies that their biggest problem is where are they gonna put all the cash? You know, because they've stumbled into a market sale. Like you weren't there at the beginning, you just happened to join them at some point, you know? Uh, and, and their issue is, what are we gonna do with all this success? My goodness, we're growing so fast. What are we gonna do with all these people? How are we gonna scale so quickly? it reads a certain way. You know, it reads a certain way is like, oh, everyone else was scared to give a date. And I gave a date and I was so successful in that. I mean, really. Were you successful cuz you didn't write anything in here about how your team members or even whether the fact that you worked with your team members to come up with that to come up with, or did you just shoot from the hip? I would also argue no new ground has been broken at this point. Everything he said is like, well, there was this big yearly event. Well, I mean, I can hit a yearly event. I mean, even in the, the podcast we did about roadmaps that we keep talking about like we talked about, like regular regulatory compliance dates. Sure. Like, cool, just put it as a little mile marker, milestone marker at the top of my roadmap. Mm-hmm. And I'll hit it. I'll hit it a hundred percent of the time. Super easy. Like, I know it's coming up. I'll put my team on it when, when I need to, and then we'll hit the date and we'll be compliant and we'll move on to the next thing. He's not pointing out any smoking guns to me, is what I'm saying. I, I agree. Absolutely agree. It's kind of underwhelming really. It, it really is. I'm, I'm, I'm actually kind of, I'm getting disappointed let's, let's read on to see if I can get excited again. Sure. That's what I'm trying to say. I need to get excited. Yep. If only I had more ice how, how and when the delay is communicated matters far more than the delay itself. The other issue with what he's saying now is like, n none of the dates matter. All the dates are made up. Everyone misses dates. Who cares? Why, why you, and the way you display your evidence of why you missed it is paramount, is what he's saying. And I, I, I don't know about that because I know of people that will just simply say, But you said uh. Yeah, but look, what he's saying here is like, that, that, that's trivial. He, he, he's basically trivializing. Trivializing, is that a real word? It is a word. Trivializing. He's, he's saying it's, it's trivial when you miss the date. It's like when you give a how confident are you that we will, whatever, and you say, I am 78% confident. And then the thing doesn't happen and you're like, Brian, you said you were 78% confident. And, and then Brian would say, well, you never hold me to that in the past, so why should I worry about, oh, Brian would say, well, There was still that 22%. Yeah. 22%. What do you want, man? Like, you didn't ask for a hundred percent certainty. The, the issue with that is your business will start treating you in that disingenuous manner. Exactly. Yeah. That's a, that's a big problem forward. It is a big problem because going forward you have a credibility issue now, right? Right. With your business and your stakeholders, why would they believe you when you say, well, this time it's 85%. Yeah. Oh yeah. This time, this time I'm confident in my 85%. Whereas last time when I said 85%, well, last time you said 78%, right? Yeah. Right. And so you missed it and we're gonna give you a pass on that. But now that you're saying 85, well, heaven forbid if you missed the 85. Yeah. Good grief. No, you, you can't erode confidence in the business like that by, by treating dates flippantly like this, that takes, I really want to use the word flippantly. Flippantly. Flippantly is a great word. It takes a long, long time to build up that confidence. Right. And it takes a split second to lose it. pushing back on estimates also misses the bigger point about engineers staying focused on delivering the largest business value. I, I don't understand what I just read. First of all, there is no bigger point about engineers staying focused on delivering the largest. Sorry. I I read that twice and I, I don't understand the point. So he's saying, he's saying because we're not estimating in time, we're not focused on the lo delivering the largest business value. Is that that statement? That's what he's saying. That's why I said it's unintelligible sneezing. There's a thing about writing whoever the author of this is there's a thing about writing and being an author. It's called show Don't Tell. Okay. Every time you have to say, I'm really good at this. It makes me think, me the viewer think you're not actually good at it. Exactly. Okay, let's, let's keep reading. Now. I'm done. I feel he started it at this point for every, or she, for every, oh, he or she for every major project shipped. We, we shipped something different on the launch date than we agreed to originally for Skype and XBONE. We didn't ship group video calling on launch date. We, while playing games, The platform turned out not to leave enough e CPU processing to decode more than two streams reliably. So we cut this feature, we cut the feature. Yeah. I, dude, everything he's saying is that's, to everybody else. Everything he's saying is, is completely agrees with, with, with, hang on. Let me see if I can skim this. Because like for the people listening, like a lot of this guy cut out. Yeah. Similarly, for every project with a fixed deadline, we ship different functionality to what we planned. Oh, really? Wow. Similarly, for every project with a fixed deadline. There we go. But, but the stakeholders were never surprised. We had continuous conversation with the business. We kept hitting our milestones. Yeah, you, that's, you kept changing them though. In order to hit 'em, you just said that. Okay. Estimates and deadlines are great for getting things done. They heavily incentivize team to focus. We built Skype for XBONE in 16 months. We spent most of the 16 months in a way, similar to hashtag no estimates philosophy promoted, even though this was not a thing back then. Our pace picked up from jogging to running for the last four months, two months to the launch, we realized we were behind and started sprinting. We were more productive and produced at the same value in those last four months that we did in the previous 12 months combined. Why the sudden productivity change? We had a big deadline coming up. There was no option of not shipping. Suddenly the whole team became focused distractions. We were all gone and we moved at a faster pace I don't see anything else in what he just said. He said the closer we got to the deadline, the artificial deadline, the more the whip got cracked. Yeah, exactly. Yeah. Okay. That's, that's the way software development was done in the nineties and early two thousands. How is that different to how I was doing Waterfall? Really? You know, the closer you got to the deadline, people just kept getting whipped harder. Yeah. Okay. I, I believe him. I don't, that that doesn't, that doesn't support hour base estimation. That actually works against mm-hmm. The argument he's trying to make. Sure. Boy, I'm, I'm glad he's with us now. Software has too many unknowns. Learning to estimate different types of unknowns giving estimates than missing them forces deeper reflection. Oh boy, I, this is getting philosophical now. giving estimates then missing them forces deeper reflection and faster learning about the types of unknowns in the software world. No, no, it doesn't. No, it doesn't. Absolutely doesn't. Absolutely doesn't. No, I, I certainly make to differ on that one. Yeah. I, I, I, I disagree with that statement philosophically, Logically, emotionally, you name it!. Spiritually. Spiritually, religiously. Yeah. Any, any enigmatically. Emphatically, theoretically, practically wait a minute. Like, giving estimates and then missing them does not force a deeper reflection, giving estimates and then missing them; all that does is f look, where am I on camera, dude. The under, all that, all that does is confidence. All that does is undermine confidence and it forces your, your management. That's right. Not leadership. It forces your management to, to pick somebody out of the crowd and be like, it's your fault. Get outta here. Right. That's all it does. Somebody gets shocked. What about your stakeholders though? What happens with your stakeholders? You say, well, I'm gonna do it by this date, and then you miss it and you go, it's all right though. cuz it, it, it makes us focus sharper. It's not our right. No it's not. Alright. That's not, that's, that's the recipe for working in the middle of the night and coming on's right. Saturday. And I'm gonna need you to work on Sunday pajama parties and all of that stuff that happens, right? I'm gonna need you to work on Sunday as well don't you go ahead and, yeah, do those TPS reports by tomorrow morning in fact, just do it right now. All right. What else is in here while I'm waiting? Software has too many unknowns, when you end up giving estimates, then miss them by a large margin. You cannot avoid being uh, having an honest conversation with yourself and your team. What do we miss? Why do we miss it? How can we try to account for it next time? If you don't have estimates, you'll end up asking these questions. Far fewer. Times. I feel an agile coach worth their salt would step in at this point to say I'm sorry, how, how did you come to this conclusion? Like, that's a question that you should pose to the team, not a statement that you should make, which is, if you don't have estimates, you'll ask these questions far fewer times., Why are you not inspecting after every cycle that you're done with? Bingo. Even, even if you have an artificial date set by somebody who doesn't sit on the team and doesn't know how the work is produced or whatever, listen, dates are reality. A date will come down set by marketing. If you have a physical component of your software dev development, if you have a hardware component, dates will be set by your manufacturer. The devices will ship by this date. Dates could be set by your management. I'm not arguing against having little diamonds on the top of milestones on the top of your backlog. That's not what I'm saying. What I'm saying is he's, he's saying if I don't do it in time estimates, I won't inspect it after the fact. And, and I'm saying that's completely wrong. This is putting the, this is putting the cart in the next cart before the horse, not just your own cart. You really should be just trying it out one time and then inspecting and adapting from there. So you put a date out there and it doesn't work to his point. Yeah. Forces great conversations, meaningful convos, whatever else. Okay, fine. But how about doing that before putting the data out? Yeah. Work with your team and say, Hey, what do we think is reasonable? Right. Yeah. Adding everything that you think you need to add in for, to account for uncertainties and complexity and all the unknowns, et cetera. Mm-hmm. Now, You put out a date, but I suggest you don't put out a singular date. I suggest you put out a range that says between X one, Y one Yeah. Whatever, whatever the date ranges are between August 30th and October 15th or whatever it is. You know, if you land somewhere in there, you could claim success, right? If you, if you don't, yeah. You know, just look at it as you get closer to it before you get to it and say, we're gonna change that because we've learned something. This is why. So, changing the dates, for changing the dates purpose. No. Change it with a rationale and say to your leadership, we learned this. The date range you gave me earlier will now change as a result, unless you tell us we can cut scope, we can live with these risks, we can accept these or mitigate these, et cetera. Mm-hmm. Fine. You know, but it's, it's informed decision making at that point. Right, right, right. So yeah, I I, I don't agree with this idea that you missed dates and you have convos with your team and it's more meaningful suddenly now. It's kind of like after the fact, you've already failed once. Yeah. You've already undermined, your confidence is already eroded in the eyes of the stakeholders Right. And possibly the management. Right. Right. How you get that back. It takes way longer to get that back. Yeah. Right. If you've been in the trenches, you know what I'm talking about. And that, and that's if you don't have a culture that washes out these people that give bad estimates. That's right. You know, or, or in the example that Deming warn warned against of you have a management culture that once they fail a couple times, they just you know, throw themselves on the sword and go get another job. And then you basically, like you have a culture of management that never learns from their mistakes. They just wash out gracefully. Mm-hmm. From there and and then you never get that skill at the management level. he talks about technical debt and estimating technical debt to say, oh, I, I, I don't, I don't want the team to work on technical debt because they end up taking months and I don't see any value in it. If you're a product manager and you can't paint the technical debt that you're resolving with value, you have a different problem. Estimates are not your problem. I don't believe anything he says here. Let's cut to the summary of the article. He says, yes, you should estimate. That's a summary. It's ridiculously hard to do and most engineers are bad at it. However, being good at it will make you stand out. That's, that's his claim. Being good at estimating will make you stand out, but he doesn't say hard to do it. I, I will throw out also He does say, if you never give estimates, you'll never be good at them. I you don't have to do time-based estimates for that statement to apply. Yes. And I think there is a takeaway in that statement. If you don't do estimates, you'll never be good at them. There is a takeaway in that statement of, Hey, it's a muscle we have to build in order to get Yeah, it takes practice for sure. I, I get with that. He doesn't even get into a lot of the typical people pleasing behaviors that teams and individuals do, right. When they're asked for dates you know, committing to things that they know they can't do and forcing their teams to take up the slack. He, he doesn't really talk a lot about that. He doesn't really talk about different styles of estimation. We did a whole podcast on estimation. That's right. And we did a podcast about how to, how to not have to deal with estimation. Mm-hmm. We did that. I, I feel like, anybody reading this article would benefit from either or both, both of those podcasts. Yeah. And then you know, basically his takeaway is estimating and being deadline driven it's basically good for you he says, I've seen teams burn out after sprinting to try to make deadline after a deadline. I, I would argue if you're sprinting to make deadline after deadline, your issue is some cultural command and control some, something in your environment is wrong because the agile is supposed to be about working at a sustainable pace. Exactly. See our podcast on that? The, the the previous podcast, right? Yeah. I agree. I I think that's right. So this, this is classic though, because what, what he's saying keeps the team doing what they're doing. I feel Right. Keep doing what you're doing and just keep practicing and you'll get better at it. Yeah. And keep estimating, even if those estimates are going to be wrong and you just talk about why they were wrong. But you keep estimating right. Point in time estimates are bad if you do what he or she's suggesting here, how do you think this will be received by your leadership? Okay, first time, second time, third time. How many times are you gonna have, right? Sometime at one point they're gonna say, yeah, you said that last time, right? Why should we believe you? This, this, this, there's this credibility issue, right? Everything in this article, this leads to a blame culture. Yes. I'm not dismissing his opinion outright. I, I've tried to consider everything he said here. However, everyone that has had a similar take that he has in this article, That I have encountered in my career has been the type of that when the date comes in on time, they somehow snake themselves in where they're taking credit for it to say, I was a single person that achieved this. And every time the date slips by, they find a way to either blame it on somebody else or absolve themselves of making any changes in any way, shape, or form. So, a, I've only seen this turn out negatively yeah, I concur with your, your conclusion there, right? So people are usually in it for themselves. If you're a team member where somebody is committing a date or a series of dates on your behalf, ask yourself the question, what's in it for them? Seriously. And then go from there. You'll be well advised to do that as early as possible because guaranteed, as Brian just said, there's something in it for them. And when that date happens, which is usually some fortuitous happenstance, it's not because of diligent, purposeful, methodical approach that brings you there. Mm-hmm yeah. They're gonna get what they wanted. Right? Right. The people that put out the dates. Right. The person that put out the dates but then they're gonna do that again and again and again. And it, it's at the expense of the team members usually Right. When it doesn't happen, which is more the eventuality. They will pass the blame to somebody else. Usually the team don't be, don't be that person. They will still be there, but yeah. Don't be that person to take the blame. We have two podcasts on this. We have a podcast on estimation about all, about different types of estimation. Yeah. And we have a podcast on moving past estimation. Before I try to enact any of this, I would definitely watch the podcast on moving past estimation. Yep. To see what the future looks like. You don't need any of this stuff to be good. Correct. I, I, if you're working on the top business priority, the thing that brings most value to the business and you're working on it nonstop, and you're delivering things I can't say iteratively, iterative iteratively. If you're delivering things iteratively, That's the best I can do. That was, that was spot on though. Then the business is not gonna complain. I, I, I tell people all the time, if you are delivering software on a regular basis, all the other vanity metrics sort of take a backseat at the point where you're delivering things to customers, to, to users, to actual users on a regular basis. If you can do that, most all the rest of the metrics that he's kind of talking about here is like, oh, well you told me it was gonna be done in 25 hours, but you turn it in in 23 and I'm really disappointed. And we do individual numbers and like all that kind of stuff fades away when you're delivering things into the waiting hands of actual users and they're happy about it and they get it on a regular cadence. I would say do that first before you, before you mess around with any of this stuff. I fully concur with that. So remember, measure the right things. And then measure them, right? So ultimately, it's all about what the customer wants you that's the ultimate measure really. It's not about what somebody in the, in the middle middle management. He never brings that, none of that. He never right. He never brings that up in this article. But, how are you delivering value to your customers in a timely manner with quality products? That's the only thing that matters. So, measure that, and anything else is really just an interim vanity metric that is put out there as a facade, right? Yeah. This is an agile facade. Yeah. So just, yeah, just, just be, be mindful of that. All right. So I think we might have beaten this one to death already, so thank you for staying with us those of you that have, and Yeah, subscribe and like, and let us know what else you'd like us to cover. That's right. Go to arguing agile.com and there's a form on the site and you can even send us a little voicemail Oh, yeah. Of your, we, we love voicemails