Arguing Agile
We're arguing about agile so that you don't have to!
We seek to better prepare you to deal with real-life challenges by presenting both sides of the real arguments you will encounter in your professional career.
On this podcast, working professionals explore topics and learnings from their experiences and share the stories of Agilists at all stages of their careers. We seek to do so while maintaining an unbiased position from any financial interest.
Arguing Agile
AA137 - Estimation is Evil by Ron Jeffries
We're reviewing Ron Jeffries article: "Estimation is Evil" from the February 2013 issue of the Pragmatic Programmers magazine.
This article is mostly known for being the source most people quote when they say the inventor of story points is sorry he created them, or that the inventor of story points doesn't like story points. We dig into this claim, reading the article and summarizing and pontificating on key points.
Join, Enterprise Agility Coach Om Patel and Product Manager Brian Orlando as they time-travel back to the not-so-good old days of 2013 (and before)!
The source article:
https://ronjeffries.com/articles/021-01ff/estimation-is-evil/
0:00 Topic Intro: Estimation is Evil by Ron Jeffries
1:14 Article Opening: A Historical Snapshot
7:07 Undistinguished Teams
8:45 "All Our Requirements" is Wrong
11:06 80/20 Rule in Requirements
14:11 Forcing the Answer
16:05 Contracts in Agile
18:11 Forecasting & Stretch Goals
24:52 Asking for "Better" Estimates
28:28 Financing Software
31:41 How Much Do You Want to Spend?
35:24 Relative Estimation (the Soundbite Section)
40:17 Two Ways to Go
44:58 Article Conclusion
52:33 Summary
54:02 Wrap-Up
= = = = = = = = = = = =
Watch it on YouTube
Please Subscribe to our YouTube Channel:
https://www.youtube.com/@arguingagile
= = = = = = = = = = = =
Apple Podcasts:
https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596
Spotify:
https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3
Amazon Music:
https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-Podcast
= = = = = = = = = = = =
There was an article that Ron Jeffries wrote the very famous Ron Jeffries in the Agile circles in 2013, so a billion Dog years ago, basically in agile terms, that was a 15 careers ago wrote this article called estimation is evil. The tagline of the article, like the, this, the single point that a lot of people will point to in the article is to say, , even Ron Jeffries, who created story points says. He doesn't like story points that's why this article is famous But I figured it would be like for a little trip down memory lane for a little for a little context To anyone who might hear that little sound bite, let's have this podcast, let it live on the internet in perpetuity. Absolutely. Yeah, and that's, we're going to crawl through this article pointing out select quotes. Snippets. And snippets. Yeah. From the article. It's interesting that, because 2013 is what you just said, right? And that was what, 10 years after the manifesto or something like that? A thousand years, yes. Yeah, yeah, yeah. But, Ron Jeffries was one of the, the, Founding fathers of this whole concept of story points, but we're going to delve into what he's saying back in 2013. We're going to delve into it today so this is going to be an interesting podcast for those of you that want the historical perspective, but also what's going on today. So I'm going to skip a good section to get in directly into the meat of it or the vegans amongst you, the tofu of it. Let's, let's do that. Tofu. So his hook to opening the article. Estimation is evil. Here it is. I'll post a link to the source that we're reading this from so people can read it themselves if they want. It's from February, 2013 in pragmatic programmers magazine. Magazine is like a papery blog for you kids. And then he says many teams, I believe it's most agile teams. Get some improvement from applying Agile values, principles, and practices. That's his first sentence. Kind of a nonchalant first sentence. But, but, well, he, he calls out undistinguished teams often seem to have excessive concern for one or more of these things, which is completing a predefined backlog of work. Asking for quote everything to be done by a fixed date and improving the quality of their estimates and basically being able to say how long it's going to take to do quote everything before they start doing, I don't know, not quote anything like anything. Yeah. So look, it's 2013, right? Get into your DeLorean and go back to 2013. You're gonna find that a lot of people are looking at... Exactly what he's portraying here, which is, here's a date, you're going to hit that date, and here's all the things you have to deliver by that date. So those of you that are PMPs even if you haven't recovered yet you'll recognize the iron triangle argument that he's making here, right, without saying as much. So that's really what this is about. Back in 2013, it was, you have to meet this date. You have to deliver all these things by this date. That's really the kind of opening that he's he's used here. By all means, go ahead and read the article. Ron, if you're if you're watching or listening to this... We would love to hear from you. And also, I have to jump the clock back 10 years from 2013, because I feel this is like a this could be like a mid career summary at this point. The way the article is written, the way that I read it, the way that I read it, the way that I read it, read it, read it, they're spelled the same, so you don't know what I'm going to say right now. I feel he's reflecting on 10 years of experience at this point from 10 years ago, which was 2003. And I can tell you. Because that was the very, very, very early part of my career was back in those days when every developer basically worked for a project manager who decided what was going to be done and when it was going to be done by. All of the requirements were written before anybody started on anything and they were all chiseled in stone and sign off was in done in blood in triplicate and Once you agree to something there was no changing it unless you signed over your first child In the form of a change request like that. It sounds ridiculous. I mean like people are like, oh People listen and we'll say why is it even relevant to me? That's not even the world we live in today. Not even by a long shot, not the world we live in today. That, that's what people, that's the critique here. That's the arguing Agile pushback to say, why is it relevant to look at this snapshot of history? You know. Yeah, and it's a very, very valid pushback. Because now we have product managers now. We do, we do. And the P word wasn't even, the P word when it pertains to product, wasn't even spoken about back then. It was always project, project managers, project this, project that. Yeah, there were no product managers. So it's relevant today, this isn't just some historical thing that you can say, well that happened then, doesn't matter now. The reason why it's valid today is because it is still prevalent today, right? Whether you recognize it or not. So the point of this podcast is for you to look at it in your own environments, look at it and go... Do we have some of that? All of that. Any of it. And then if you align to any of that, this is where the value comes into play here. The dates are very, the years at least, are very relevant here because 2003, 2013, 2023. Right, yeah, but you know, you know the funny part about the about like history repeating itself that were that you're kind of dipping in Yeah, I'm just getting there. Is like how long are the Misinterpretations of Taylorism gonna stick around, right? Like they've they've stuck around for well over a hundred years at this point How much longer do people need to think that? Oh We all know that software development. There's not one right way to do everything there are multiple ways some of them more right than others, but But certainly equal on the quote correctness of doing things. So like how, how long are you going to apply this incorrect application of management to this new, what new method of working to this new industry basically, where it doesn't, it's incompatible, this incompatible management mindset. So if a hundred years. Is not enough. Like how long are we going to be stuck with this? This is what we'll do. We'll put this at, let's put this podcast in a time capsule and 10 years from now I'll play. So Siri set an alert for 10 years. Oh . My Siri just did that. No, seriously though. Yeah, that would be so revealing if we did that, right? But again so why in 10 years time, where are we going to be? And why is it relevant today? And all of that, because this is not a binary thing. It's not like, okay, 2003, something happened in 2013, this happened. And then 2023, we're completely, you don't have that compartmentalism. Did I say that right? This is a stroke, if you like, of an artist's painting that doesn't have any ending. This is the sound of a bell that never actually stops. It decays. Kind of like my name it never stops. Okay. It just decays. Trust me. So why is this relevant? Because it impacts you. You just don't do things. You either don't know it does, or you don't know how much it impacts you. Right? So when we're back again, from that time capsule, we're going to tell you, Hey, knock, knock, knock, wake up. Do you still think that this is impacting you?\ All right. So I was going to say back the article, but I'm going back to here. So, so he talks about undistinguished teams. Undistinguished teams. The distinguishing characteristic of undistinguished teams is they have an excessive concern for one or more of the following. And I will, I'll shortcut you to the end of this. One or more of the following is, they really like to have fixed dates and estimates for, quote, everything they could potentially work on. That is So, he says, they're excessively concerned with estimation. These concerns are understandable. Most organizations experience with software development is not good. Promises are made and not kept. Projects that were supposed to be done on a certain date dragged on and on, burning valuable time and money. Like again, this is a time capsule from 2003 re described or re unearthed edd? Yeah, unearth and, and yeah. Re rediscovered basically. Yeah. In 2013, not a lot has changed, but certain teams, they gave it a different name then and called it software crisis because software had been more prevalent between two thou, 2003 and 2013 in those 10 years. So one thing I wanna highlight from his first paragraph, he says these, these are the things that cause an agile project to only. be about 20 percent better than whatever was going on before. So he's saying, Oh, we got an improvement with agile applying it, but it's only about 20 percent better with whatever was happening before we can dispute the 20 percent better with the number, go back and forth, surveys, whatever. We're not like, I don't want to spend a lot of time on that. I want to, but what basically his point here is it's not a lot better. It's not, it's not monumentally better than what we were doing before. It's only marginally better. Okay, so moving on to his next section, which is titled starting with all our requirements is wrong. He has the zinger of most of us were taught to write down all our requirements at the very beginning of the project. There are only three things wrong with this quote requirements quote the very beginning of. And quote all. So basically everything. And I can definitely relate to this. This guy basically nailed the essence of what we were doing back then and why what we were doing was very ineffective. Right? So in project management, you treated the customer different to your own teams because it was Us and them. They paid. We received. And you had the customer write down what they needed. And not just kind of sort of write it down and then come back and revisit. No, no, no, no. Write it down, sign off on it, and then you say, okay, it is now fixed. These are your requirements. That's what Ron's saying here. And so when your teams start delivering things to the customer and they start seeing the early iterations, because remember that word, I'm actually being kind to lend back to that era. We didn't have iterations. So when the customer finally saw something, it wasn't quite what they wanted. And they said. Yeah, we, we don't want this now. We know we said we wanted that a year ago or nine months ago. Immediately, immediately, the providing organization, you said, but you said that and you signed off on it. Now you're saying you don't want that. So, ah, that's fine, right? We're customer centric now. Well, because Michael Porter had been around and the people are now thinking more about the customer and they're saying, yeah, yeah, yeah, fine. It's okay. But, but we need you to now sign off on a change request because you're changing your mind. You want something different, right? That was the era that he's that Ron is is speaking off. And I've lived through that. Let me tell you this. It was extremely painful because it it really bled through any trust you had built up with your customer, right? Their business changed. The business climate changed. How do you satisfy that over nine months if you're just gonna stand there and say you said this and now you're saying something different? Sure, that's what Ron's talking about. So the all our requirements Yeah, they didn't even know what the requirements were they told you what they were in good faith Well, He kind of summarizes in this section. He says the bulk of the value. He's saying from the requirements quote requirements he's invoking the 80 20 rule and saying the bulk of the value, so, so 80 20 rule, 80 percent of the value of requirements comes from a very small, comes from 20 percent of the so called requirements. So, so so, he, he says the, the worst case scenario, kind of in the last, in the last paragraph of this, starting with all our requirements is wrong section. He says, worse yet, when we write down all our quote requirements, we act like this is the very last chance. To ask for anything. So the idea is like, well, when you write everything down, only 20 percent of that has value or 20 percent of that has more value as compared to the rest of everything you've written down. So, I'm fine. Like I'm fine. Applying the super loose and fast 80 20 rule to, to a, a giant p r d requirements document. And we did, we did a podcast on the p d before. Yeah, we did. Now you were like, you were like I think in that, in that podcast, not, not to summarize 'cause I'm not gonna be able to remember it 'cause it was more than like a day ago. But in that podcast you had mentioned like, well, it's supposed to be a living document. You have to go back and update it when it ha and, and I was like, yeah, but I mean When I use Jira, like why, why do I need a separate document if I'm using Jira? Don't all this stuff lives over there. Why do I have to do, why do I have to update it in both places and, and if I'm not updating it in both places, doesn't the p r d become like a, a snapshot in time type of like time capsule of like, At this date, on this whatever, we thought the project was going to be this. And now, with many, many changes and discussions over time, it's going to be different. So you can, you can, after this podcast is over, you can go back and listen to our PRD discussion because we, we took, we touched on a lot, a lot. Of similarities in here, we absolutely did. It's still in our audience to think about this 80 20 as an absolute. It could be whatever, right? It doesn't matter. The thing about this is back in 2013. There was a lot of this us and them ism. And we always said, well, the customer doesn't know what they want, right? They say something and then they change their mind as if that was an anomaly, right? So, that's how we treated it and we almost penalized them. And we said, look, you change your mind. You have to pay in the form of a change request. That's more money. And they're like, well, how's that our fault? We didn't tell you something wrong. We told you what we knew. To be the right thing at the time and now time has changed so there was that sort of dichotomy in place and it was very difficult to live through especially if you work for a large organization right because The numbers were bigger, right? Then you had competitors. 2013 is about the time when some of the early competitors of yours, whatever industry you're in started to think about agile and they started to think, Oh, this isn't maybe the right way to do things. And they started to embrace. Customers, including your customers, potentially and say, come on board, right? We'll work with you and we'll just kind of figure it out as we go along. Right. And that's what Ron is trying to kind of summarize here in his article. Yeah. But that article goes back to 2013. That shows you the. The forward thinking that he was projecting at the time. All right, let's let's let's cut back now. So he's in the next section, which is estimating when we'll be done is wrong. Forcing the answer is worse. That's the section here. And the key takeaways, the key takeaway in this one is he says, well, we, well, we push back on developers estimates. Leaning harder and harder until we are sure. We squeezed out all the fat they have left in their estimate. Sometimes we even just tell them what, when they have to have it done. So, so and then he, and then, and then at the bottom, the little tag onto what I just read is, I'm pretty sure no one in the room believes that date. If this. If this is a time capsule, this is a very accurate time capsule, because again, back in the day, like at the very beginning of my career, everyone worked for a developer, QA, whatever, BAs. Documentation, whoever the quote IT department you all worked for a in a, it was a matrix environment where nobody was employed by the project. Actually, that might not be true because the project manager might have a budget and the project manager might go out and hire a team to implement a software project. So, so, so the project manager might actually be your employer. So that what I'm about to say isn't true, but what I was going to say is, you were hired in by the technical people or director of development or QA manager or somebody like that and then you work for QA But but but you did projects that were initiated by project managers that had They had dates and they have budgets and they have customers and so like that So so really the project manager was more like a modern product manager Then anything else back in the day, even, even though they didn't really kind of realize that. Right? Yeah. I think when Ron says that sometimes there was a date imposed upon the teams, my experience has been almost always always back in the day, there was a date you had a date imposed, inflicted upon you and then you had to work your way back from that date and somehow backfill everything that needed to be done. By that date. Well this is, this also goes back to the podcast that we had on contracts. Yeah. Like, you, like contracts, they, they, they pretty seamlessly weave their way in. You could write a contract that isn't Oh, all the software has to be delivered on this date, And all the UAT has to be done on this date, and all the whatever has to you, you could write a contract that doesn't work like that, But still makes everyone happy. Like, there's no reason you need to do that, Other than, other than, of course, Well, this is the only way we know how to write contracts. This is the way I've written contracts for 20 years. On this date, you'll deliver that. On that date, we'll accept this. We get seven days to say whether we like it or not. You know, we'll take possession of the vehicle on this date, and you will deliver the vehicle on this date. You know what I mean? They're applying a different paradigm. Ooh, that's a 5 word I haven't said in a podcast. Paradigm! They're applying a different paradigm to software development, whereas they should just... Change the contract to be a software development contract, right? You know, we're delivering software. We don't know what you want, but, but there will be delivery on a regular interval. And at that time you get to inspect what is being delivered. Yes, you can say that you what you want in terms of priority. I value this over this, but it's all relative to everything that needs to be delivered. Back in 2013, it was very difficult. It was not like that to come up with the paradigm of continuous delivery over several milestones. It was like, This milestone and and part of that underpinning was the fact that people that came up with those dates hint It wasn't the teams people that came up with those dates Were rewarded based on meeting or not meeting those dates. So there was a lot of that going on I think we've touched on some of these elements on other podcasts. So if you're in Send it on meeting a date. You're going to do everything you can in your power to make that date come what may, which is where these teams are like really pushed and pushed and pushed until you squeeze all the fat out of them. You do that, but obviously the thing that suffers, even if you could make the deadline is quality, they'll deliver something, they'll push it over the line. And then you start to use it and it will be suboptimal to say the least. He touches on this. Let's, let's get into the next section. Cause he does touch on this. So in the next section, next section is titled agile teams working short iterations, period. They pick an amount of work. That they forecast they can accomplish. Too often, the product owner or member of management expresses disappointment with the amount of work that the team has chosen, has picked, and encourages them, them being a team, slash urges them, slash demands them, that they take on more work. And the quote here is, People need stretch goals, stretch goals. I wanted to bring up the idea of stretch goals I hope it'll land in the middle of this podcast. That way most people have stopped listening when I bring up stretch goals because there is a framework out there that specifically has stretch goals. As a part of their planning, which is hilarious to me because when I set sprint for my team, I've done this for years, by the way, when I like it, so like like not to be a, like the hipster product manager, there we go. That, that should have been our podcast name, hipster product manager. The hipster product manager, the hipster agile coach that should have been, we, we're going to create two different YouTube channels now. So, there is a framework out there. I definitely talked too long. There's a framework out there that incorporates stretch goals in the nomenclature that actually is a thing. This is your sprint goal. And these are your stretch goals. So, Again, if you get nothing from this podcast and if I'm going to cut a clip from this podcast, this will be it. My name is Brian. I am a professional product manager. I've been in the business of product management since about 2018. And I'm here to tell you, you don't need to stretch goals. You just need goals. You just need a goal, a goal, one goal, because a team will find it difficult enough to hit one goal quote on time. They don't need a thousand goals. Starting a sprint, setting one goal. The top business priority is this. And then fill in the blank. The top goal is this. I would like to accomplish that in this sprint. What the team does not need, and what I feel that his, what is it, undistinguished? Is that what it is, undistinguished? Undistinguished teams. What I feel, the differentiation between good teams. The best teams and quote, undistinguished teams is, is the product manager coming in and saying like, Here's a laundry list of things. You've got to get them all done. I have 17 goals. As opposed to the businesses to get this one thing done. Well, what happens when we accomplish that thing on day three of the sprint, Brian? You, you've achieved the goal and may all your dreams come true. Like that's, that's great. Fantastic guys. Good job. You achieved the goal? Well, why not call these other things stretch goals? Why not call those other things optional things that you didn't need to work on if you had to work the whole sprint And like, are, are we counting on what, what, what game are we playing? That's what I'm saying. Exactly. What games are we playing? What game are we playing? Why, why, why not call 'em like, why not call 'em pipe dreams? How about this? How about this? Why not call the sprint? Successful and close the sprint as soon as the goal is done and start a new sprint. Oh, we do two weeks sprints. Well, if you do two weeks sprints, then how come you finished the goal in the first three days of the sprint? You're under committing maybe, right? I'm thinking about this from a PMO perspective. Oh, you finished in three days in the sprint. You're under committed. So guess what? Next time you start a sprint, I'm going to give you 10 times that. Well, five times that really, right? So that you can have 10 of those plus the five. Stretch goals are one of those things where when, when you as a team member, whatever your role is on the team, when you are presented with stretch goals, your immediate counter should be, if I meet that stretch goal, how much are you going to pay me? Right? Because there's no incentive to meet stretch goals. To your point, you finish in three days of a ten day sprint, you finish the one and only valuable goal. That the team has decided upon or however, right. Been dictated, but you finished it. Then what does the team do? You can start saying things like, well, do some team building exercises, this and that. Yeah, most of the management isn't going to like that because they're going to look at that as a waste. And they're going to say, start working on the next actual goal. So then it morphs very quickly from that to, you should have a goal. One goal you say cool. I'm on board with that one goal and then five stretch goals. So the team has never Standing back, looking at their process, looking at what else can be done, et cetera, right? If you finish a stretch goal and you start the next sprint, I bet you you're going to get at least two, maybe three, maybe four stretch goals. Because they know that you under committed, or they think you under committed, right? So, just be wary of that, right? Stretch to me says, my definition of stretch is really, really simple, right? Which is, time and again, we've been Hitting this cadence, right, of meeting X number of goals, two goals, three goals, and every goal is different. So it's not just the number, it's, it's on context a goal for a sprint might be different than a goal for the next sprint. It could be more challenging, it could be more complex, could be. The team gets to say what that is though. I think the helpful, the helpful context here and the helpful pushback is it's hard enough for the development team to hit one goal. Yeah. Why, why do you need 15 goals? Well, you don't, why do you need five goals? Like, you, you hit your one goal, accomplish it, close sprint done, start a new sprint. If the concern is, well, we finished the goal in three days and we have seven more days of the sprint. What are we going to do? Like that, that's, that's an issue to deal with in your retrospective to talk about older than why, why, how often your sprint goals accomplished relative to how long the sprint is because that might be a problem with the length of your sprint. Well, it might be also a problem of not treating every goal differently, because if you're treating every goal the same, you can say, well, this goal was finished in three days, so we should have maybe three goals next sprint, right? And then maybe you won't be able to meet those. Who knows? Right? So that, that's the other thing. It's not linear. That was my point. It's not linear. You can definitely stop a sprint at any point. There's no rule that says you have to work ten days, even if you finish in three days, and you've met your sprint goal. You can pick up another sprint or you can say, well, we're on the same sprint, but we'll pick up a goal that will fit in the next seven days. Yeah. Yeah. I prefer the latter just because I like the cadence based approach. cause it, it disrupts less than it, you know. Yeah. The other way. But yeah, I, I, I'm, I'm starting to feel that the whole concept of stretch goals needs to be taken offline for another podcast. I, I love it. The downside as a habitual pattern with your management is . If you're taking stretch goals and even if you meet one or two of them. They expect you to take stretch goals period and that's bad, right? Because your actual goal could be enough to consume your entire sprint. Yeah, so that's bad because it becomes an expectation Even worse is you take two stretch goals three stretch goals and you meet one. They're gonna say You met one. Why can't you meet another one? So there, to this point, to Ron's point on this blog, they are squeezing you until there's no fat left, right? And that's also not a good thing from a team perspective. Well, I definitely agree with that. The next section is called having Having demanded the impossible management asks for better estimates. So I have a couple of things called out for us to talk about. He says management tries to force the team to do more than they can do demanding that the team quote, become more productive. Which means quote, go faster, promise more and get it done. Which is also my gripe in corporate America with OKRs because this is the way I see Orca. OKRs are not supposed to be pushed down, pushed down. They're supposed to be pulled. That's right. And this is, this is my main gripe. So I agree with that. A few more things I want to highlight before we open this up. I believe really works out well. He says they'll begin to overestimate everything in order to get things done quickly. They'll cut back on important aspects of the work. There'll be sweeping the dirt under the rug. That same thing that that you're talking about with testing cutting back on testing, that kind of stuff. That's exactly what happens here when you start, squeezing teams to get done faster, faster, faster. So he says this slope is very slippery. Let's consider first long term planning and then short term planning because he has an exchange in here that I'm not going to read, but basically is the idea is someone comes and asks how long will it take to To get the entire quote project done and then the team say well We're working in iterations and we're doing the most important thing after the most important thing after the most important thing So we can't tell you how long it's gonna take to do all the requirements So there's there's these this dichotomy this this sort of like these two perspectives are kind of clashing in his world And then he goes into this story which I think is a really good story. You can read all about it though. We'll put the link to this blog. It goes into this story about working for Sue Unger, the CIO of Chrysler Corporation with Kent Beck which I think is a very, very, very interesting story. It'd be worth reading on the podcast, but it's a fairly long story. But the concept is that they were building a payroll system and that the project as it went on, they said, hey, we're going to build the most valuable things and then we're going to give the product owner who is a domain expert full empowerment to cancel the project should she feel that it's not producing anymore. And which eventually apparently happens. And she gave a commitment to do that. Yeah. Yeah, which is great. That's pretty rare too. And apparently also Sue Unger was... It was a payroll system at Chrysler and Sue Unger apparently was a subject matter expert on that system as well. So she really knew the features that were being delivered. She really knew which ones were making an impact and which ones were not. Yeah, and the project was ultimately cancelled largely because of politics. In the end, because again, that plays its role, right? In this case, they were lucky in that they had a SME who also was somebody who was empowered to make the decision on whether to continue the project or cancel it. So he recognized the fact that not the whole thing had to be ripped out and replaced. Like there were parts that didn't need to be changed. That's right. That's his summary is that parts of the old payroll system were just fine. They didn't need to be replaced. Other parts never belong to payroll at all like tax And other external programs. So really, he's saying, don't rebuild the Franken monster that you have now. Like, I mean, whatever, right? If you have something and you're trying to just build a new system to replicate that, you don't really need a new system. Well, he has this, this passage right here. Yeah. So he says, what we should have done and could have done is solve the problems one after another in order that Mary Marie, Marie, and the other payroll people wanted to be solved. Yeah. Yeah. So build a system that solves the real problems that you know about at the time, rather than replicate the functionality of an order system with new technology basically. And then here's the other passage. The payroll held up as one of the original successes and original failures of Agile would very likely have been more successful had it not assumed the job was to predict when it would all be done. Or even track the project when it would be done. Not even track it is what he's saying. That's right. The job was convening a team to solve the problems of the payroll organization. Yep. Probably department, right? Yeah. And when the return on that investment declined to move on. Right. Yeah. When we were thinking about doing this topic. This passage stuck out at me because it pretty clearly is a now next later roadmap. And when you decide like, Hey, this is everything I'm doing now, this is everything in the next category. And these are the things I decided to do later when that next category starts looking kind of droll when it starts looking like not so alluring and you are funding the quote project. There's nothing to say. Like, listen, I don't really care about the next category and everything is later. I don't know. Like, do we you know what? I think I've got enough functionality. I think I'm going to stop the funding. That's right. Completely. Again, our whole podcast on roadmaps where I, where I was saying you should only do. Now, next later, you should not put everything on a timeline because this garbage, this is exactly what I'm talking about. I, the person funding the, quote, project, can decide, you know what, I've got enough functionality, I'm good. Let's just stop, stop paying for this, move on, thanks team, go on to your greener pastures or whatever. Exactly, yeah, I couldn't agree more. See, you don't have to necessarily... Chase that every single last piece of functionality. I think this is where Ron was at in 2013, and we're still talking about that today, right? And he's, his His blog is more of a reflection on what should have happened. To this day, I'm seeing companies that do this, fall foul of this whole thing, right? Ten years later, right? They're still doing that because they say, well this budget was for this project. So we have to spend it because if we don't spend it, we'll lose it. Well, that, that, again, like he points out in his next... Section that says how big is this project he says like this this mindset survives that that you know before the business engages something that commits money to something They want to know quote how how long is this gonna take when the reality is? Well, they don't know, they don't even know what they want. Right. When they're asking how long is it going to take. So, how are you going to tell them how long it's going to take? They don't know what they want yet. Right. You have to engage in an exploratory period of software development where you're building stuff for them. Before they even know what they want. Well, so this requires that trust and that and that assumes that you're you're skilled, right? If you're a new team, you don't know how to vet that out of there. You're actually done for that. So this requires that trust that we stop talking about the customer as they, right? This requires the trust where you say, let's figure out what their real needs are. Let's talk to them about their wants, wishes and desires as well, right? We'll map them on a on a chart and say You're funding for your needs. We're going to meet your needs. If you can even do that much, you're doing really, really well. Well, in the article, he has a section that I think is fairly enlightening. He says, most of the time, they, quote they, again, we're assuming we're dealing with this old school mentality, right? Most of, or maybe not old school, but the CFO look viewpoint, right? The CFO viewpoint. Most of the time, they... No, how many people they'll give us and how much time they want to commit to this man. And I turn his time comment directly into money. They know how much they know how much budget they want to throw at the problem to see if they can figure it out. And they do that head shaking until we quote estimate the numbers that they already had in mind. So we should turn a question around. How much do you want to spend and what you hope to see? In the product which again is is kind of the the underpinning of modern product management everything He wrote in this article a decade ago, right? He says if no one knows and no one has an idea Odds are the project is too vague and too big and it really shouldn't be doing it Anyway! Ding ding ding ding, right? That's the alarm bell. So run away is what he says. Those are the two words He uses right there next But I think you have to have your organization be bold and say, this is too risky and we're going to decline the business. Right? That's, that's what he says in his previous paragraph. It is tricky because today. Organizations do not decline business. I don't think they did back in 2023 either I mean, if you were to go to your C suite and say this project we think is too risky because they're gonna say, well, do what you can, right? We need the business because we need the oxygen to keep the organization going. We need to pay you and everybody else. I believe that. I think it's incumbent upon whoever is taking on the work, whatever your role is to say, right? Let's stop this, this whole idea of a divide between us as the provider organization and them as the consumer organization and say, let's partner with them in a true sense of the word and, and have them understand that they can't have everything because they're not have, they don't have an unlimited budget, first of all, and make them realize that, right? And then, but don't penalize them and say, Hey, Write down everything you need right now, in blood, and then we'll hit you with change requests. There is a medium, in the middle of all that, which says, given the money you have, you, customer, decides how much you want and what you want, until that money runs dry. If you can satisfy what they want, when they want, You've won, right? Don't worry about when the money runs out. Because when the money runs out, it runs out. They can walk away and say we got what we wanted. We got our money's worth basically, right? And that's enough. We have a different podcast coming. I haven't put it on the list yet. But we have a different podcast coming about satisfying our customers, right? I think that's a worthwhile podcast because a lot of people focus on that. But we have a slightly different take on that. So just to kind of throw a little, thing out there to to whet your appetite. But coming back to this, how much work should we accept this time around is a loaded question because oftentimes people will say, well, how much money do they have to spend? Because we can always get more team members. Okay, stop, right? That isn't really what this is getting to the crux of. This is saying, can you meet what their needs are? Right? Needs, not their wishes, wants, and desires. If you can identify those, you're already off to a great start. Because if you can meet the needs, you can have a conversation and say, Here are your wishes, wants and desires. Now we've met your needs. Do some of those become your needs? Not in the current budget. Maybe in the next budget, right? But, the invitation is out there for them to come back to you, right? When they have budget next time. So, if you don't do that though, You're kind of going back to the old evil ways of working. It's that us and themism that creeps in. So he says, how much work should we accept this time around? That's his next header. So an Agile team needs to decide how much work to accept in its next iteration. One way to do this is to look at each proposed work item and estimate how much time it will take to do. So now, now we're in the, we're in the Meat and potatoes of the article, so here, here's, here's the, here's the soundbite. It's coming up right now. I'm just warning you. There are a number of ideas how to estimate using something other than time. Points, gummy bears, gummy bears, I love gummy bears, Fibonacci t shirt sizes. These were originally invented to obscure the time aspect so that management wouldn't be tempted to misuse the estimates. I know, I was there when they were invented. I may actually have invented points, and if I did, I'm sorry now. That's the thing that gets quoted out of here. But he says, there's a good idea hidden inside of these methods which is to compare one feature idea To another and think about whether it's a larger or smaller, right? That the relative estimation is saying is still, is still important. He says, we're doing all this as a side of how much work to take on in an iteration, we might want to improve our ability to do that. And we might benefit from thinking about why we thought the thing would be easy. And it turned out to be hard. You know, so we, so we want to inspect afterwards, we want to retrospect afterwards of why we thought something would be easy or, or complex or not complex and, and, and look at it afterwards so, so the soundbite, the soundbite, oh, Ron Jeffrey says you shouldn't use story points, and he's sorry for inventing them. That that's not what he's saying at all. No, that's not what he's saying. That's right, that's right. He's saying relative estimation is the way to go. Like he just, he, he just said, oh, I'm sorry I did this, or whatever. But also you should compare items to other items, right? To figure out relative estimation. Or at least relative comparison, if not estimation. Yeah, absolutely. So look, first of all, two things, right? So just to unpack for people that are listening to this that weren't Outside of maybe middle school in 2013. Ron Jeffries invented story points. And what he's saying here is they've been misconstrued a lot, right? So he's trying to put that right in this blog. And, and, Relative estimation has been very much misunderstood and underused. So teams estimate items. I've seen, I've seen, I can't tell you how many times I've seen teams. Go into an estimate session, pick up a story and say, okay, team, how much is, you know what do you think? This is a three or five people vote. All that happens. The relative part is missing, right? And this is not a new concept. I'm gonna repeat that. This is not a new concept. Relative estimation was around before all of this and agile was a thing back in the day when we were doing things like Estimating projects, estimating deliveries, whatever, in the classical waterfall project management world, we have this thing called analogous estimation. That's a fancy term for relative estimation. All it meant is, we've done a project like this before, right? And it took six weeks, just to take a number. It was similar to this. This one's slightly different. So we're not gonna say it's six weeks, but it's different. It could be five to eight weeks, right? Or you can pick your padding factors, right? You can say five to 10 weeks, whatever, based on the complexity and the unknowns, et cetera. So that is relative estimation. It is carried forward here, right? But what is really misunderstood is how the team should use this, which is look back and say, what have we comfortably Comfortably been able to deliver in a sprint in the last sprint. Nothing. Okay. Look for the sprint before it doesn't matter. Has the team been intact and have you delivered something in the 10 days of the sprint to done, meaning you didn't just get dev done. You did dev testing and deployment into production. Everything was done or whatever your definition of done is. Just, just abide by that. Your, your definition of done. If you met that, well, that's your reference. That's your standard story, right? Look at that and say, compared to that, how. Does this compare? How complex is it? How risky is it? How much effort do you think it might take? What do we not know about this? And the outcome isn't always well, did the last one we did it was like a five. So this was maybe a three. Somebody, somebody on the team. Should feel empowered to say, well, this is one thing we don't know. We need to find out. So I can't really give you the estimate you're asking for. Listen to that person and say, well, what do we not know? Maybe we just create a little spike story for a day to figure that out and then come back to this story. That is perfectly legit and should be pursued. Because anything else is just really just... Guessing. Yeah. You know, what happens when you guess, right? Yeah. I didn't win the Powerball, but I did guess I win the Powerball every time. Because that's my superpower. All my guesses are right.. Yeah. Think about that one. That was a, that was a inside joke. Yeah. Moving into the summary. We're moving in the summary. Here we go. So he says, what, what's his advice out of the whole article? What is his advice? So he says he's got, he's got two ways that you can go. The second one is better. So, the first one, he says, is, you can, he, he says, the, the big guys, the big guys, quote, quote, big guys, the Vinnys and the joeys, that's right, the big guys, they're gonna pick a date anyway, so you might as well pick a date before they pick a date, so that, that's his first one. I'm going to skip straight over that because it's obvious it's it's kind of a facetious kind of a suggestion. And I'm going to cut the second one. He says, put a person in charge who understands the problem with the right people who understand how to solve problems and then solve the problems in the order of importance. Yep. Solve those problems and then ship on a regular basis right away and get feedback and get, and have observability as to what the market says with regard to your changes. I just summarize this paragraph. If there's a lot there though in that little paragraph. There's a lot there, so I can tell you, I, on multiple occasions on my client engagements, I have seen teams evolve from where they were to where they got to, and they get things done and then it sits there. They can't quite deploy into production because DevOps doesn't have bandwidth, for example. Cause we're in a matrix environment and we simply reach out and open a ticket and they say, we'll get to it next week. Every second, every single second, a delivered, completed, tested, UAT tested piece of product increment sits on the shelf waiting to be deployed is waste. It is declining in value for your customer. Your customer has the highest value. If they can get that when they want it, which is as soon as it's finished. So if you delay that. It is declining in value, right? And when I try to explain this, people are like, What do you mean? We don't understand. I'll give you a simple example. Let's say you're in the market to buy a vehicle. It doesn't even have to be a new vehicle. Let's say it's like two years old. You buy a vehicle that has lane keeping assist and all these, safety features, right? So it will follow the car in front that slows down, your car slows down, right? Things like that. You put your indicator on to turn right, and there's a car there in that lane, and it's gonna tell you that, because it'll beep, and it'll show you a little LED, all of those things. Great! Fantastic! However, think about it this way. Let's just assume... That they were made available, generally available on most vehicles back in, I don't know, 2014. I'm just picking a number here, so don't get hung up on that. Let's say it was 2014. If you were in the market in 2014 and you knew that the model you were considering had these features, what were they worth to you, right? These are brand new features. They're worth, I'm assuming, a lot to you because they're adding so much more than you had before. Now, fast forward most manufacturers adopted like we all have that now every manufacturer offers that yeah, so it becomes not a new feature. That's worth Something to you. It's just an expectation on the Kano model. This has become right. This has become something that basically you expect to happen. It's not a delight or by any chance, right? The lighter might be a while based on the weather is going to steer me around this and self drive and whatever. Give me a massage, whatever. Yeah, right. So that that's kind of, yes, slightly extreme, but it gives you the idea behind it is there is a time element to the value proposition for what you're delivering. To your customer, right? The more you delay, the less of the value for them. Yeah, the less of the value for them means automatically whether you know this or not. The lesser the value for you, because if they can get the same functionality for somebody else, why would they come to you? maybe they're you know, an entrant in the market that can offer it cheaper. And now they're gonna go to them, right? So just bear that in mind. Well, I mean we could, we could, again, this, this single paragraph, we could go on and on for probably 45 minutes. We could easily. Because again, this one paragraph is kind of the, the, the seed of modern product management he says, put a person in charge who understands the problem with the, and put them along with the people who solve problems. And then have them solve the problems in the order of most important to less important. And then ship it right away. And change what you're doing based on what the users and the market says about it. You basically just described the whole product management profession right there in one sentence. He did that! He did that in 2013! Yeah, in 2013. Also, by the way, there were no product managers. Exactly! Exactly. The whole product paradigm was really even, wasn't even really kind of mature back then. anyway like we're, we're a stone throw away from wrapping up. So his final paragraph, he says, this approach shortens all the cycles. That delay getting value to your point. It cuts communication lines between the people who want things and the people who do make things. It cuts communication lines between the people who create things and the people who use those things. It takes the most important ideas, builds them quickly and gets them out there. Yeah. It's hard to do it. But that's, that's why it's the best. It might be hard to do. Yes. Oh, devops is hard to do. And product prioritization is hard to do. And scheduling and jockeying calendars is hard to do. Sure. It's hard to do. I mean, compared to, I'll just pick a date out of the air and shove it over to a team to do things and just pay them whether they do them or not. And whether anyone finds value or not. Like, I don't know. Is it hard to do? No, I don't know if it really is that hard to do. I agree with that. Listen, this whole voodooism of picking a date out of the air. That's how it's days. So like now that we read through the whole article. But, but like, again, the, the, his, his little clickbait piece that, that gets picked up on social media. I, I, I feel is is like the, the least important uh, gummy bears, oh, I gummy bears. This part, this part, this part. Story points. I, I know I invented story points. I'm sorry if I invented story points. He says that in one paragraph and the very next paragraph outlines, yeah, you might not like story points, but I still suggest the good idea of compare what you're doing to something else that you did to see if it's larger or smaller. Listen, I, this whole concept is so misunderstood out there in the wild. Course, right? Story points. People are like, why don't we just use time? Why don't we do this? Why don't we do it? Why? Why Fibonacci? Why don't we just use straight line? Anything. You can use one, two, three. Fibonacci doesn't matter what it is. Sure. So I, in the past, on at least two occasions have used a fruit scale. For, for story like sizing, not story points, but you don't understand story point. Don't agree with fine. Just throw them away. Yeah. Right. Just say, let's just look at something that you were able to deliver in 10 days. It's a sprint in 10 days. And we'll just say, well, that's the size of I don't know watermelon. What if it was 10 percent bigger, whatever way, bigger effort, bigger complexity, whatever. Right? Would we still be able to deliver that in that same 10 day period? Right? No, we won't. We'll just call that a watermelon then. Right? So, you have a honeydew melon, a watermelon. So, a fruit scale. Sure. Right? Apple, grape. Grapefruit, right? Kiwi. Sure. And strawberries and blueberries. So, we can do a lot of blueberries and get those done in a day. Less than a day. Okay, a strawberry a day. Okay, a grapefruit 23 days. Fine. All of this is relative to the definition that your team has of what done means, right? If it's just they've done. Yeah your fruits are huge. That's fine. You know, but if your definition is get it to Dev complete, testing complete, UAT complete, or even better, out into production, right? That's what he's trying for. If you're doing that, then you have fewer fruit and they're probably quite big. Well, again, I would expect most people experience when they hear what you just said. Is, well, my management asks, well, what is a watermelon is equivalent to three days, five days, 10 days and a great, like they're still going to try to pull them back to what, what, the management knows again, what they were taught in their MBA class, because they would like a hundred years ago, somebody came up with the scale of this job takes this many hours to complete. They're trying to pull them back where you're saying, no, no, no. This is a, this is a grapefruit size task because. You've chosen this other task that you did in the past and just said this is a grapefruit sized task. And this task looks like this task. You're comparing work, whereas these, what, what they're doing is they're, they're taking a relative estimation Fibonacci. This is an 8. Well, what's an 8? Well, an 8's about, I don't know, 3 days worth of work. 5 days worth of work. It's about 2 days worth of work. Okay, well that's about 16 man hours. And I'll equate that to like, again, that is incorrect. It's with this article, and, and, and again, I, I wish he really could. There's, it's so sad that like the, the one paragraph, one sentence outta one paragraph gets the soundbite because to dig into this paragraph, I feel would be an entire podcast. Yes. He would with, with Ron Jeffries in the room to digging it, be like, oh, that'd be fantastic. Why? Why? How did people. Get this so wrong where they take it and they know because you wrote in this article, clearly in this article, you have to compare this, this Fibonacci number to this other Fibonacci number that actually represents finished work. So how do people get from like, well, I understand you're saying it represents finished work, but I'm going to sub in hours for this. That's not what this says. Listen, so it is, it's, I feel the confusion of like. Well, people have messed this up so much that the original concept is so marred that we're just going to abandon it and say, listen compare this work to the previous work to say, is it larger or smaller? Well, a lot of times people forget about the underlying assumptions, right? So, yes, of course, the management, the PMO folks will say, Equate it to hours, right? Of course. Then my immediate comeback when they say that is I was by whom?, right? So you have a team of, let's just say for the purpose of discussion, eight people, it doesn't matter. 10 people. Who is doing the work and at that point that when that question is fired back at these management types or the PMO, you're going to equate this back to hours. But we have a senior. Developer who has eight years, 10 years of experience in the same technology, right? And they can do this reasonably in lesser hours than we're talking about. On the other hand, They may not be doing all the work. So we have this other developer, developers, that have less experience. And it may take them longer because of that. Or, hey listen, this work involves new technology that nobody knows about on our team. Someone's gonna go figure that out. We're gonna learn that. If it's not the right technology, we have to figure out an alternative even, right? That's why that other spike story is in the backlog, to figure that out. So if you pull that out on them and say, listen, everybody is not equal skill sets, experience wise, etc. Then you can't just generalize ours. Ours is a, is a, I can drive. You can drive. You and I can drive on a Formula One track. I have no doubt. We can do that. Can we keep pace with... Pick a, pick a race driver. Lewis Hamilton's my guy. So Lewis Hamilton, can we pick, can we pick Lewis or Max Verstappen who is kicking everybody's butt? But anyway, can we keep pace with them? Probably not, right? So I used this argument one time and one of the execs said to me, Do you realize that Schumacher, back in the day when he was a, he was a race driver, he couldn't, he didn't actually have a driver's license. He couldn't drive on, on regular roads. But he was the champion. Formula One champion like go figure that out. So the point is everybody's not equal. Yeah, right to me that drove it home It's like you can't drive. He doesn't have a driver's license The guy drives at, I don't know, 180, 200 miles an hour plus, right? Yeah, but not on the roads. I was going to say, not on the roads. On the closed circuits, he can. Sounds like he should have a driver's license in Florida. I'm just saying, hey. He doesn't need one in Florida. He can just crash anywhere. He doesn't even need insurance. So, but that's the different topic. So, so, so the, the Ron Jeffries article, like estimation is evil. The Click Baitey title, I feel like, yeah, it kind of did a disservice to this article, which is a very good article about saying like, Hey, , look at the work and compare the work to the work and the estimation that is evil where he's talking about is picking dates out of the air and just, just going and saying like, well, you're going to pick a date, so I'm going to pick a date first, right? So at least, at least my date might be closer to reality than your date because we know someone's going to pick a date and this whole rat race Of estimation that that is the evil that he's talking about in here He's not talking about story points specifically being flawed. That's right, but people blame him for that I I which is why he's apologizing for it. I feel and that was in 2013. I understand but again for everyone listening We've read many, many excerpts of this article. I'm going to link the article down in the video slash podcast and people can read it and come to their own conclusion and comment below if anything that we missed anything that we didn't or if we're wrong, any of these points, you know again, I, I, I got kind of tired of the, of the click bait of referring to this article and Ron Jeffries, taking Ron Jeffries holy name in vain. Or something and well, it's a lot of Ron. If you're listening, we would love to hear from you and I'd love to have you on a podcast because I really agree with your ethos of getting something done and getting it out there in the wild as soon as you can, which is what he's saying in the last two paragraphs, get the product out there, see what happens, take the most important ideas, build them quickly and get them out there. I couldn't agree more. And speaking of getting things done, we're done. Thank you for staying with us, everybody.