AA72 - Gantt Charts in Agile Software Development

Ah,, listen, ah, Om, I'm gonna need you to do some Gantt charts, Gantt charts. Yeah. I'm gonna need you to do a Gantt chart because, we need to know what it takes to get quote all the work done. Absolutely. Yeah. I could give you a Gant chart that the only thing it will guarantee is things will happen on days that end in why, other than that, I can't guarantee anything. You know, I feel you got a bad attitude about that tune Gantt charts for me, the agile project manager. I put agile in front of project manager. That means where agile. That means I gotta get you a Gantt chart faster. That's right now, if I do a Gantt chart, will you. Please take this the right way. Will you hold it against me? Like, will you say, you said home, something will be done by July 31st and it's not listen, it's like, , at the used car lot. You were the first person to throw a number out. So, so I lose. Yeah, you lose. Yeah. Yeah. We're gonna throw it out or whatever. We're the last, I don't even know how the rule works, but the point is if you are in an organization and there are traditionally a project management led organization, cause I don't know a better way to phrase that. then there's a high chance that you use Gantt charts in your organization, or at least at the leadership level they use GA maybe your team never sees a Gantt chart, but your leadership most certainly does. And, whatever panel that you have at your organization that., gives the thumbs up or thumbs down to projects before they start. Cuz again, if you're using Gantt charts, high likelihood, you're also using projects right? To allocate funding to your software efforts, you probably have to create Gantt chart, do a certain amount of planning and do some activities like that before you're even allowed to start a project. Yeah, absolutely. You're right. I think a lot of times it stems from the powers that be looking for some sense of comfort, . They, they look at that and they say, if you gimme a Gantt chart, it gives me something to put on a wall and talk to with my leadership. okay, fine. But. The it's your point? The leadership is planning with Gantt charts and the teams may not see them. So now you have a situation where the planning's done up front, and the teams are supposedly delivering in an agile way. How does that marry up together? Yeah. I think expectations are a big thing here. So if leadership understands that the Gantt charts are done at a given point in time, so it's a snapshot mm-hmm and it's likely to change if they admit to those two things. And then the last thing you want them to kind of, relent on is these are not guarantees. When I put those little diamonds on a Gantt chart, beating milestones they're best faith estimates. We think this might happen. This might not happen. I mean, are they like you bring us into the purpose of this episode, like we're gonna, it's arguing agile,, how to argue about Gantt charts, welcome to the new framing of the podcast. Yes. I change all the taglines for all the podcasts across all the podcast platforms to say, , we argue about things , in the agile space so that you don't have to right. They, , change that. Nice., and I feel like in an effort that follows that branding, I'm not gonna put you in the position. I'll do it on your behalf to be the one that argues for Gantt charts rather than against, I'm not gonna put you through that trunk. I don't mind, honestly. Don't, it wouldn't be the first time., no, no, cuz if I were the one arguing against Gantt. I feel like I would make an equally crappy argument against them than for them. So I feel you, you should be the proper one making the argument against them. So that, that's how we will. That's how we'll go. Point by point, arguing four and against, we we'll try to stick to that framework sure. For this podcast. And, and if it, if we don't then Hey, you'll get all your money's worth out of the podcast. Keep you in a seat. That's right. Yeah. Keep your receipt. turn it into your corporate HR. Or HR, HR. So, , Gantt charts, why, what is a Gantt chart? Why does the industry use them? Let's start there. That's an awesome question. A Gantt chart for those that don't know, is really nothing more than a description in a visual format of when various components of your project are anticipated to complete project. so let's say you are buying a car. For example, you might have a game chart that says you're doing some research, you're looking up the different car manufacturers, models, et cetera, that suit you need that there might be some bullet points that you can put down and say buy a certain time. I want those done all of your research, all of your research. Yeah, that's right. All everything. so yeah, you, you put something down on paper, virtual paper that says, if I'm done doing my research by a certain time, then I can go shopping for the car. And then you have another limit a time by which you should be finished with your shopping. So you can actually start negotiating with car dealerships or wherever you're buying your cars from., and, and then finally you might have so. On your Gantt chart that says you actually buy the car, you register it and that's it. That's the end result, there's various different levels that you can break this down at, but these are just high level things that you might have in this example. So Gantt chart is nothing more than a projection of end anticipated high level activities, right. That are put down. And then you project out some end times for these activities along the way, you would've some key activities, there are, there's just, they look like any other activity, except for the fact that they're a point in time rather than a range. So starting my research ending, my research is a range of time. It's a time block, whereas registering my car. It's not a range. I don't start registering now and then finish a few days later. I do it. Right. So that's one day on a day on which you register your car, so that becomes, what's known , in the Gantt chart world as a milestone. And it's represented on this chart as just a little diamond. Yeah. Typically, , you can have any shape, so that's really what a GA chart is. It's a, it's a forward looking projection of when you anticipate activities to be completed. The last diamond in every get chart is that's the end of the project. So in software development, it's typically you're building a new product. It's a product launch or go live, or however you wanna phrase that. Yeah. Well, I've been on projects with Gant charts that go into an aftercare, hypercare, whatever you wanna call it, daycare. You could definitely do that. Yeah. I mean, after so yeah, maybe I should take that back. It's not the last. Milestone on your G chart that says you go, you went live, you might have a period of warranty., and you can put that on. And there's typically a fixed duration on that maybe three months after the product is launched. Mm-hmm that the development team is handholding the product it's negotiated with your vendor. Usually if you're absolutely contracting. Yeah, yeah, yeah. You can do that. Right. Exactly. And then the, in that example, right, the last one would be when you turn it over to perhaps another team within your organization, that's, , handling that on. Maybe it's an operations or maintenance or support. Yeah, I wanted to go back on something that you said, but I also, forgot what we were talking about. Gantt charts is like looking at an auto accident where there's fatalities involved. I look at it, it was interesting guys, you can stop looking at it. And I can't like, I can't stop looking at it, but also like, I'm like, oh God, why? Why? I wanted to look at this topic from the perspective of companies that say that they're doing agile development, but still. Claim that they want Gantt charts because the two seem to be incompatible. So yeah, I think that's a really good point. And maybe we can just step back a shade and just talk about where these things came from. Right. Gantt charts are named that way after the inventor of these things, right. Henry Gant, Henry Gant came up with this back in goodness. A long time ago. So think about that timeframe early 20th century, it was hardly any, none, no software being written back then. So when, when, , Henry Garrett came up with this, it was to reflect processes that were completely predictable. Right. For example, manufacturing is fairly predictable. And so he came up with it with the right intent. To say, here's what we can plan. We can make a short term plan this month, right? Medium term this month at the end of this month, , maybe I don't know, four, three months, six months out. Mm-hmm, take your pay. and then the next level he can do that. What he did not do is he did not build in the idea that, and, and this applies, regardless of whether it was software or non software, basically when he came up with it, it was, this is it. This is how you're gonna do things. And if you didn't stick to the plan, you were off the plan. Yeah. so that's a bit of history behind where it came from now. Well, that, that would be so, I'd be remiss if I didn't mention it's because Henry Gant at that point was working as an understudy or, he was working alongside of, Taylor at this point. And he was specifically studying , the time clerk role of Taylor's operation. So he was dealing with a very small piece of the operation, right. in the managing of the, the factory workers and the, the manual labor is basically sorry, I forgot going with that, but the point of me breaking in was to say like the, the, the management of how long it takes to do every individual task was just, a smaller piece of all of this operation that was happening. All, all. Professional management that was happening. Right? On this podcast. I'd like to be in the position of supporting, , one side of the discussion. I want to push myself to try to support the side of the Gantt chart, but also I realize that the Gantt chart can't just live in isolation in and of itself, if you're ignoring the management of all the other aspects. Cause the idea is you've put in time to study how long it takes to do each individual job. And that the Gantt chart is built. Henry Gant time chart is built off of your expert, understanding of how long it takes to do every single job. If you don't understand how long it takes to do every job or you have not done the work to figure. The research to figure out how long it takes to do every job. You're not gonna be able to build an appropriate Henry Gant chart cuz you don't, you, you not put in the work to do the research, which brings us to a very quintessential soul searching problem of, can you build a Gantt chart for a task, which is unknown to you, you know? Yeah. Can you include items in that Gantt chart, that you are not sure that you're not aware how long they truly are going to take. And I have to ask you, since I'm in the role of supporting the, the, the deviations of the Gantt chart, the CPM, the PERT, the different types of charts that are out there that are deviations of the Gantt charts, do any of those. Take into account what I'm talking about, where you're not exactly sure how long it takes. So short answer is they absolutely do not; they do not take that into account. They only cater for the known can't charts live in the world that is known. But I wanted to just briefly unpack what you just said, which is you have to be able to. no exactly how, what, how long everything's going to take. Right? Mm-hmm and that's, that's true. If you're building a proper grant chart, the difficulty there is how do you know? So when you go and ask, right, you go and ask people. If you're not the expert, who's actually building this. You ask people that do this for a living mm-hmm . So if you do that, you might get an answer. You might get many answers. If you ask many people and that's where I'm going with this to, to have an activity completed. If you ask somebody who's been doing it for 20 years, 30 years, you'll get an answer, call that "a." You ask someone who's been doing it for five years. You'll get another answer, which is gonna be different than a let's call that "b.". And then you ask somebody who started last week. you're gonna get C now, which is the right answer here. A, B or C. And Henry Gant, when he came up with it originally this whole concept of, of Gantt charts, he didn't build that in. He didn't build that in no. Right. It evolved. However, over time they did scientific studies of people doing manual labor. And that that's how they figured it out. They, they did a lot of studies. One tends to think if I were to do a broad study of software development and let's say for example, , your software development team, , was engaged in activities and I could split your activities between two categories. The category number one is things that your team has a skill to do. Let's say you're building a web applications in, react front end C plus plus back end. Yep. Well worn industry standard type of stuff. Right. I, I give you, I give you Hey, we gotta take our, our, our web application and we gotta add these features. They're either, C plus plus, backend type features or they're, react widgets for front end. And okay. Well, it's all stuff that our team's worked on before it's in the current code base. No problem. You probably could compare those features to things you've done before and come up with a good estimate of how long it would take. And then I would tell your team. Okay, cool. That's great., now, now I want to , work with this completely new. Web application that you've never worked with before brand new code, brand new server, the equivalent would be moving you from like you work in, , the Azure cloud and now I'm gonna migrate my Azure cloud stuff, all the data, the application, the backend, everything. And I want to see if I can do this in AWS. Right. Completely different. So, now your team has to go learn the whole AWS stack, the whole stack. They have to learn everything different, right? all of the knowns where you could estimate they all now break down and you're in uncharted territory. So you have to have a period of time where you allow your team to learn new capabilities. I'm the only reason I'm bringing this up is because now I'm in the vein of arguing for the Gantt chart. Is there a period of time? I could give my team to learn something new, say, Hey, I'm gonna give my team a month. Because we, as an organization have decided to migrate off of the Azure cloud. It might not even be the Azure cloud. It might be that we are a.net in-house shop with in-house servers. Right. we have a rack of servers in our data center. We're gonna get rid of those servers in our data center. We're gonna migrate up and we've chosen AWS as a vendor. Okay. That's the situation I'm proposing now. Okay. So we are gonna migrate out of an in-house architecture and we're gonna migrate to use the cloud. All AWS, everything. All gold all the time. Yeah, bling forever. So in my Gantt chart, I'm gonna give a period of time to skill the team up, to work in the new architecture. Yeah, for sure. And that just becomes an activity on your GT chart. It becomes a capability, a training time. Basically it becomes training time on my Gantt chart. It does. It really does. I think I'm glad you brought that up because I think where, where this is kind of highlighting things is in your example, there was a skill set that's needed, right. That needs to be, , procured on the team, so to speak. So yeah, you add that as an activity. When Henry Gantt came up with that, it was just literally just all these activities. One through end, right. And various times when they should happen and much, much later it was. I forget the name. I don't even know if it was one person that came up with it, but the concept of dependencies was brought in, it's a natural evolution to looking at something like a GA chart to say, yes, we forecast this, this line. It's yay. Long. It's supposed to finish here, but down here we have something that cannot start until this is finished. Sure. So they linked the two up. Sure. Right. And then this is a great example because you can't start your AWS development, your migration or whatever until your team has the skills of operating in the AWS architecture. Right? So this, this is a great example. your Gant chart will stop at a point where your team has gained, quote, all the skills. I realize it's a bit unrealistic, has gained all the skills. And then you can start your next phase of actually migrate my stuff to the AWS cloud. Cuz now the team has all the skills they need. They've taken a two week period four week period, whatever the period it is, right. To skill up in the environment and to learn things. So there, there, you can't start section B until section a is complete, you can't, can't start section C until sections B and a are complete that is the typical Gantt chart, that we think of mm-hmm and, and like not to introduce another term, but here we go, that would be the, the normal critical path of a Gantt chart these are the absolute things that have to happen. In order and everything else is added on to that. But if these things don't happen, it's going to change the timeline for everything that comes before and after if these things don't happen as prescribed on the chart. Yeah. Absolutely. Spot on him. And the critical path is really showing you the shortest path to completion for the project. Right? Right. So anything that slides or delays, even if it's a short delay will impact the critical path. If that activity that's being delayed was on that path to begin with mm-hmm some activities are not on that path. Right. quite often., but yeah, so dependencies were brought into this, this model of creating a game chart at that point. Yeah., and then later on, again, sometime later they were evolved into different types of dependency. Like this cannot start before this finishes or this must start when this other thing starts. Regardless of when they each finish, right? Yeah. Different types, right. Finish to finish, finish to start, start to start, et cetera. Yeah. All these different things came about. But , for many decades, nothing changed fundamentally. Yeah. Right around a Gantt chart., much, much later people realized that it's, it's fine and dandy to have a Gantt chart, at least it gives you something, right. It's a plan kind of makes people feel comfortable with the end date in mind that we might make it even though everybody recognizes that there's slim to chance of nailing that date, but we might fall in the ballpark or that's what their hope is. So after many years people realize that is really not prudent because if you learn early on that, you're not on track with that Gantt chart. So let's say for example, you have activities a through Z you're at C. And you already know that the planned C duration is going to be longer. Cuz something happened, whatever happened, it could be anything, it could be external things and new regulation came out that you aren't expecting whatever. Yeah. Right. So it's gonna take longer. Well, you know that everything's gonna ripple out and the end result will be longer the end, the end one. So why wait till the end and say, well it's because of C why not adjust it? Now that concept came into being, so people started saying, well, if you adjusted it, we won't know where we started. Right. Well, what was adjusted over a period of time? How many activities and by what amount? Yeah. Yeah. So they started this concept of baselining. They would say, well, we'll just take a free frame of the first one. We came up with that everybody agreed on and that becomes what they call the baseline. And then anytime you change it going forward, other than just simply tracking progress against it, have you changed it, added something new, removed, something changed, duration change of something else, whatever these things were. Future snapshots again. Right? They, they were saved and sometimes people just did that. Just keep 'em going, change the plan as you go. Other times people said we're gonna have a new baseline now, so you change C and you go, okay, now, given this, where are we now? That's our baseline. Yeah. Right. So it, that process is what in project management is named re-baselining.. Um, so they did that, but beyond all of that, really not a lot has changed over the years. And I wanna go back to your question, right? You don't know what you don't know basically. So how can you do that? for software development, that's a really good question because software development's. Engineering. You're not stamping out widgets. I, when I say engineering, I means like manufacturing mm-hmm predictable inputs outputs, right? And predictable time to get from input to outputs. So you think about a black box, which is the process, the input is what it is, the output, you know what to expect. All those three things are known. You can plot them on a chart. There you get chart inputs change in software development inputs here, meaning requirements, right? They change people find new things, et cetera. The process changes process, meaning taking the inputs and turning them into outputs that changes your team can sit you and see changes. People leave new people, join you, go back to forming everything that we know about all that changes. and then the output itself, if you're really doing agile, Can change, right? So you, you set out at the beginning and say, this is what we want. And when you get closer to it, assuming that the, stakeholders, the business has been involved throughout, they might say, well, this is taking time. But what we have now is good enough. We don't need that other stuff, that can happen in software. We don't need all that stuff now, so we can just deploy what we have. Yeah. But, but what would you say to the person who claims, the Gant chart tracks my chain cycle. And we might decide along the way that we want to pivot in an entirely different direction. And that's fine. We can update our Gantt. And, our Gantt chart will change over time. And that, that is realistic that our Gantt chart will change over time but they'll have a mechanism that usually the mechanism and like you've been a project manager, so I'll tell you. But the mechanism from my perspective is you go back in front of whatever team manages, all the projects and all the, usually it's a team that has oversight over budget as well. Mm-hmm you go back in front of that team and you say, Hey, we've decided that we wanna do X, Y, Z, and XYZ is not the most advantageous of the market. So we're gonna pivot to ABC. And we're gonna cut the Gantt chart off here. And the old XYZ is gonna stop here on this date one week, two weeks, whatever, from now, we're gonna cut all the contractors, fire.'em all get rid of.'em all bring out a new team to do whatever bringing in a team from this other contractor. And then we'll start with Gantt chart ABC, and we'll go with these new priorities the argument here is. Gantt trucks work fine. Like if you have to adjust, like you can, you can just adjust them and change them and they'll indicate new deliverables and you they'll basically indicate a new plan to the end. And, it doesn't have to match what we started with. It doesn't have to match, like we can show that we just change a plan because that's, that's, that's, that's the, the principle of agility now., and now we've taken the best of the project management world and the best of the agile world. And we've blended them because we'll just throw out whatever, Gantt chart we had before. And we'll create a new one. And that's cool. Yep. Absolutely. Yeah, that would be the arguing point here. And that would be fair that as an argument, I mean, there's some provisos there that you mentioned already. It's okay to change right. When we have to pivot, we pivot. and if you're doing that, then again, chart is fine to, to, to use as an instrument. ultimately though you could look at that and say, well, has your get chart really any different than a product roadmap as we know it in agile, but most organizations though, they tend to frown upon changes to a plan, changes to our get chart. What do you mean you have to, oh, we're delayed now we're suddenly in delay mode, right? Assuming you're not doing a hard pivot where everything changes. They understand that, but what we find is a plan. A Gantt chart is made up many months in advance of the desired end result and any delays, any slippage is frowned upon. Yeah. And that is completely non agile. We've been talking about this topic now for a while, but we've not talked about how each individual little bar on the Gantt chart is created because each individual bar on the Gantt chart could potentially be an individual team doing, playing to tell the person who's compiling the Gantt chart. I was trying very hard not to say project manager, the person who's compiling the Gantt chart to tell them how long they think in their expert opinion, it would take to carry out whatever that bar is. So there's planning involved. But if you're trying to say, I want you to build a new software package, a new software website or mobile app. Let's, let's go mobile app. We're in the business of knocking out widgets, that we sell in the app store for whatever $2 for whatever people download them. Right. Mm-hmm widget just do X, Y, Z functionality, whatever the, whatever it is. Right. I want you to, create a new widget for my company that, , does X, Y, Z put it in the widget and push it out the store, right? You're gonna build me a Gantt chart and the Gantt chart's gonna have milestones and the milestones are gonna say different functionality. And the very end is my app is in the app store. It's people can download it and do X, Y, and Z functionality X and Y and Z functionality. So you're gonna have a Gantt chart that says build X functionality, build Y functionality, build Z functionality, pushed out to the app store, let customers download it and do XYZ functionality. Yeah, I mean, in that example, so if you've got each bar being represented by somebody who says this is a team that's building this. Yeah. Et cetera. then what should really happen? As opposed to what actually happens. So let's just take it backwards. What actually happens is somebody just puts down their best effort. It might be based on their experience, or it might be just something they pull out of the air and say, this takes a month who is like, I gotta help you there because this, this is my, if I'm gonna if you are, in the spirit of refuting, I have to stop you there because I need specifics. Oh, I give you specifics. We're gonna assume that it's one team. Okay. It's a mobile app. It's one team. Okay. Couple iOS developer, Android developer, maybe two backend developers to support them. So it's a, it's one team. I want X functionality, Y functionality, Z functionality. There are three different features, right? I want them all done before I push my app to the store for the customers, because that's what I've decided it is MVP, not you. And I both know we're gonna put that offline for a second. Sure. For the purposes example, we know that MVP should not be X functionality. Y Z, etc. C MVP is like, I made some screen designs. That's MVP. I pushed out in four hours and here's my mobile app. the reason I bring that app is I want to, I want to make it more tactile, more real world for people that might be listening right now. That's why. Yeah. So if let's just go back, right. It's one team, that's fine. You have three I'll call features, whatever they are. Right. Sure. as far as the game chart, how does the estimate to complete each of these get reflected on the get chart? So there's one of two different ways. Usually it's somebody uses expert judgment. Or just judgment and this says, I I've done this before with other teams. This kind of thing takes about this long I'll add in my little padding to it. And so this is what I think it is. That's one way. And then they repeat for the other two a, B and C start of a finish of C there's, there's your, there's your product? the other way is you get the whole team together and you say, this is what we need to do. Go and figure out the, the how part let's get back together again in, in a few days. Yeah. And as a team with everybody's thoughts and inputs and, and going back and forth and negotiation, et cetera, you would come up with. a minimal path that gets you from a to C at the end mm-hmm . If I was a project manager or the Gantt creator of that process, I would then look at that and say, well, what are our assumptions that we're using here in building this, what are some of the risks? What are the dependencies that we haven't thought about that we might consider those things? So after you do that with your team at large, you would then add in all of those and say, it lends you at, November, sometime, and not a big fan of actual dates, but let's say November, it falls in November. So my game chart shows an actual date because all the software out there that does game charts, deals with absolute dates. Right? Yeah. You can roll that up and look at it in quarters or weeks or whatever. Probably a good idea. And let's just say, I looked at November. My messaging to stakeholders would be, we can get this done, assuming the assumptions that we have here, they are, we listed those for you. Somewhere between November and January or whatever, it's always a range. Right. And that is at this point in time with what we know, we will come back if there's any substantial changes to that. Yeah. If there's changes that take you from November to December, and you will know as you go forward that something's slipping be upfront and say, look, that Gantt chart I shared with you that needs to change. And here's why. Yeah. Well, I need to ask some questions to make my argument a bit more solid. Yeah. If I'm trying to, as a project manager, if I'm trying to claim that my high level. ties to budget that that's really where this comes down to. Yeah. I'm trying to tie it to budget. If I'm trying to claim that my high level, budgeting basically, holds up the scrutiny. I need to know that all the planning that we did is all the planning that needs to happen. That's the issue here. Like I can't, I can't have my team go back into planning as the project goes deeper over time. And as the project,, stretches out over time., and, and if you wanna take this back to a most people, like we're gonna lose most people now. So thank you for listening to the podcast, but if I'm a project manager and I'm going to say, Hey, we're done with the planning phase of this capitalized software budget. We're going into technical feasibility phase where we can capitalize the a hundred percent of the developer's time or whatever. Yeah. I, I need to know that I'm not going back. I'm not dipping back into planning phase. So in my chart, when we were in the next bar where it's a hundred percent capitalized, whereas like we went through a couple weeks of deep, deep planning with my tech leads and my architect, where the architect came down from the mountain and said, oh my like, here is my architecture. Plebes I dunno I'm sorry I dunno, you used to be an architect. I can tell. Yeah. Yeah. Yeah. I cannot go back into a planning phase cuz then I have to alert my finance people and I gotta go have a conversation with my CFO and say, oh, I said that we were not doing a planning phase, but is we had to do more planning the lean principle here for me, if I'm trying to completely pervert the Gantt chart and agile, , is the assembly line can never move backwards. The, the line only moves one direction. Yep. So the worst you could do is you can take something off the assembly line, call it waste. Put it back on from the beginning. Yeah. That's that's the worst, that's that is, and that's really the worst case. You can't stop the line and move the whole line backwards. That's not in the model. No, that's, that's very, very true. I would say this though. The concept that you've just outlined is, is very, very prevalent out there. Right? Do all the planning up front, indeed. They even call it the planning phase and the implementation phase or execution. Right., that seldom works and I'll illustrate that with an analogy. Right. Next time, you're on a flight just think about how that flight pans out let's say you're going from and take a real example. Let's say you're going from, I dunno, LA to London, what happens? The flight takes off. See, it takes off on time from LA and is going across the, the Midwest on its way. And if you're flight people, you you'd understand, they, the pilots are following what are called way points along the way. And, and you can follow the flight on a, on a map seat for like seat back. You can do that. And then you'll see that he's suddenly decided to go against the anticipated path, which is usually an arc he's he's going against that. He's now going up to Canada, he's gonna Halifax instead of going straight across the Atlantic, why would he do that? And so where I'm going with this is the pilot didn't know himself. When he, or she set off from LA, that that's the path they're gonna have to take. They knew the start, they knew the destination and because they've done this several times before they knew roughly the kind of timeframes it takes, right? And so they could say, well, we're gonna land it this time. So when you take off, they'll say we're flying at X thousand free. Our flight duration is going to be blah, Right. They'll say that, but on the way, if they're deviating from the plan, it's because of external factors that they just learned on route, they learned this bad weather for example, they learned that the president's plane is flying in the vicinity. So they were told to steer away these things are, these are real. They happen all the time they learn there's just simply too much traffic as it's called right. Too much traffic. So they're told, Hey, deviate up here or reduced to a lower altitude, et cetera. These things happen all the time. Mm-hmm . And what do the pilots do? They don't sit there and update a plan. They simply respond to the plan by agreeing to ATC and doing what they're asked to do. and eventually they'll get to London and they might get there at the same time. They might not. And if they don't, you can't say you got here late, we call that, , collaborating., right. Yeah. They collaborate. So with the other pilots in the area, also with air traffic control, , yeah, yeah. We, that collaborating. Right. Right. Exactly. So my point of, of that analogy is did they get you to your destination safe and sound. That's the, first and foremost requirement, and now you could say they did, but you know, 20 minutes late, it's like, okay, so what, right. There's nothing you can do about that as it happened. So I think coming back to Gantt charts, we need to treat them in that way. Right. So to your point about planning, here's what I would do. If I were that project manager who had planning as a phase, I would have that in, but I would call that initial planning and then I would have planning built into every phase. Yeah. and that's for the purpose of making those deviations course corrections on the way. I wanna pivot now to the case against Gant charts. what we started with in our intro in agile, like obviously the first one is, , don't do a Gantt chart. Okay. But, Brian's sassiness aside and that's a huge aside, by the way., let's talk about the case against Gant. If somebody told you, Hey, we're a agile company and we do agile software development., but I had, , somebody in my company leadership maybe, right. Saying, Hey, oh, I need a Gantt chart. I don't know how to tell when things are gonna be done. If I don't have a Gantt chart, you need to do a Gantt chart. What would your initial reaction be? How would you deal with that? How would you deal with that person? Probably in leadership. Telling you that, what, what would your first impulse be before we go into the case against Gant charts? Well, as a lean Angelist my first impulse is yuck. What a waste, because ultimately this is not adding value. Yeah. But that not withstanding, that's obviously my, my first reaction as well would be like, oh, GA shark. That doesn't really help anyone but, but I mean, given the fact that you ha you know, you're being asked by leadership to do something like this. I think what I would do is this, I would say, look at the granularity, which at which you will provide such a thing, because when you think about what your teams are doing, they're doing sprints, right. One to four weeks, possibly two mm-hmm. And during the sprints, it's the team that picks up enough work that they feel they can finish in the sprint. and sometimes work doesn't get finished for whatever reason. So my point is where would you get chart? Like what level are you doing your get chart at? Are you doing that at the sprint level? You say in the sprint, we'll do this in the sprint. We'll do this, or are you saying it it's every X sprint because if you're doing it at the sprint level, you always be updating that thing. Yeah. Over and over and over and worse than that, you would always be trying to justify that to leadership, that, to say, you said it would be done. Why isn't it done? Right. So what I would do is I would have a conversation with leadership and set their expectation that the Gantt chart is a best faith estimate at a higher level. Probably nothing lower than a month that says, here are the features that we anticipate delivering and milestones not just features, but things like we'll start the process of launching the product. We'll start whatever the activities are put that in there. And the milestones, is this gonna be slightly, slightly deviant thinking here for those of you that have done get charts before my, my milestones would not be a point in time milestone it, wouldn't say let's say, go live is April 15th or whatever, right. It would have that milestone of April 15th with a dollar line that goes all the way out to potentially June 15th, because we're just starting the project. So my window's two months wide. Right. And the messaging to leadership is at this point with what we know, we think we can land in that spot somewhere between April and June. and as time passes, we learn more. That may change. It may get narrower. We may go from April to June, to April, to may, eventually mm-hmm and it, we may just stop there. And whenever it falls within that span is where it falls and that's still a success. Well, hang on a second this isn't sound much like the case against Gant charts. This, this just sounds like how to incorporate it in your agile pro I, I tend to think, if you're telling me, how long does it take to do the entire XYZ project? I kind of feel I would be remiss if I didn't say wait a minute. We don't even know if X, Y, Z are all the features that the customers. You're right. You're right. I missed to go back to that level. I missed the prompt altogether here. The case against G charge is the biggest one is the obvious one, which is people fixate on the dates on the get chart. Mm-hmm and then they become commitments immediately. Yeah. That's the case against it is these are not commitments. If you don't understand that you shouldn't be doing get charts. That that's what I would say. that's the first thing. I mean, the other thing is that the, the, this assumes that everything dude is assumes more. It not only is assume that everything that's that's gonna happen. It also assumes all the dependencies are known up front. Yeah. Right. Which you don't. It's the stuff you don't know, it's the unknown unknowns. So what do you do? You put in a big, big, old fudge factor, right? So we can go live anywhere between February and November. Yeah. That's too wide of a fudge factor. Yeah. Well, as a product person, I don't like padding. Like I'll, I'll add the padding if necessary padding in the way of these are the other initiatives that the team is involved in that are more important than this. And we could go offline because we're engaged in X, Y, Z, I'll engage leadership from the perspective of don't you think these other things are more important? Leave that stuff to me. I don't need the team to add a, a third on top of their estimate and to pat things down because they know that I'll pat things down anyway. So the padded estimates are actually padded. I don't need all that. I need clean estimates as clean as possible because I'm gonna try to align them, , around,, the expectation of scope. That's what I'm gonna align on is, Hey, can you deliver the ability to do feature X with this customer? Yes, I can. But feature X, to me, sounds like number one, number two, not number 3, 4, 5. So if we're just talking about number one and two, yes, we can deliver feature X and that's what we'll rally around. And I don't need to talk to sales, VP, customer advocate, representative support rep, whatever. I will talk to the customer who asks for that feature. And I will show them every two weeks that we're done what we've done until they are satisfied. And we'll keep working on that until either, either until they're satisfied or until I get new marching orders from the higher ups in the organization. Because at some point I'm tying into the company vision, which brings a product vision, which brings the features, which brings etc. Cetera. Yeah. So that pro uh, view and approach that you outline absolutely has merit. I mean, that's valid getting raw estimates or absolute estimates without any padding and then doing your own thing with them. That's fine. But before you do that, should those estimates include things like a variance for people being out sick? I mean, I know we got whacked sideways on COVID hit but even now with re infections and everyth people, people take time off, at the drop of a hat. No, no plan. Right? So there's a certain amount of flex, I would say that needs to be added. Well, let's argue the I feel like I'm effectively arguing the Gantt chart side of things. You should know how much sick time your employees have. You should know how much vacation time your employees have in aggregate. So if my employees typically have 30 days of vacation per calendar year plus X amount of sick days, seven days, I don't know, seven days so my employees typically have five weeks of vacation and I have, this is actually, actually, this is a good number. My employees typically have five weeks of vacation for the whole year and I have six people on my team. Right. That means I should plan two and a half days cuz it's six people, 12 months, whatever. Yeah. Yeah. I should plan two and a half days out of every single sprint I have two and a half days. I don't have productivity for, so if I'm trying to do a Gantt chart, you shouldn't be planning for 100% utilization. That's where I'm trying to go. Utilization, capacity, whatever you wanna call it. Yeah. You should not be planning for a hundred percent cause you're never going. It's not, that's not realistic. No, you're right. I mean, so you've outlined the known knowns, right? I mean, we know people have PTO, et cetera, so yeah. It's the unknown unknowns. Right. We don't know how many people are gonna get, get off sick, like right. If they go, do they only take three days or sick time that they have allocated for their year or are they really out for two weeks for COVID? I, I don't know. Whatever. Yeah. Yeah. Yeah. So there's a little bit of that as well. So that becomes non-scientific at that point, but the example you say, yeah, you could definitely factor that in and you should, yeah. You should factor that in. Yeah. But, but it should it should be generally factored in because when, like what you just said, when you have one sprint where you're like, oh, well this sprint it's the, I don't know, 4th of July weekend, Christmas weekend, Christmas, new year's break or whatever, like. you should pretty much expect, like you might have one or two people on your team that wanna work in that, like whatever single people or whatever that might wanna work in that the rest of your team, you're gonna have three quarter people out during that period. Yeah. I feel there is a certain point of this where you should expect, there should be some familiarity based on your experience that you should expect dips. Yeah. Spikes and dips. But, but I feel if you are planning for your normal amount of, vacation away, whatever time in your calendar, you can make up for the spikes and dips, moving things around. Okay. Well, I'm expecting three days of vacation between the whole team and this two week period this sprint, I had zero vacation then the next sprint I had six hours of vacation. They should make up for each other. Likewise, four sprints out over each other. You should make up for whatever variances you have in the longer term. I, it comes out in the wash. I, I agree with you. Right. But those things you can actually account for what you can't account for is things like once the project started, you had people leave new people join. Yeah. Right. But having said that, let's say you don't account for that. That's still something you should really explain. Right. Pointing to the Gantt chart and tell whoever's looking at it. Right. And listen, we had this dip because of right. And we all know what happens when someone leaves. Yeah. The same way I feel about that. I feel about product management is for example, if I'm tracking business value on all my stories and I show in the last two sprints, we had a significant dip in business value deliver. Over time. I, as a product manager would come to the product management meeting and my leadership would say, Hey, Brian how come these last two sprints you've done a third to a half of what the normal business value has been like, oh, normally you deliver 20 points of business value per sprint. These last two sprints you've delivered eight and 10. What's going on? Why is there so low amount of business value compared to the normal? And I will say well, because we've had a couple of. Technical upgrades that we've delayed. And we had a few architectural things that have come up that we've delayed and we really need to take some time and get over these architectural hurdles to get ahead, to get current with the technology. And we've dedicated a lot more time to making sure that the team can bring the architecture up the speed, so that we aren't bothered with, end of life and stuff like that like I I'm fine explain it should be a one sentence explanation. And then we move on our next topic. it should be that quick, right? It should prompt the business to talk about it. I bring it up. I tell them a reason. And then we move on quickly. If somebody really wants to dig into like, oh, did you have to do a AWS migration now? And not three months from now or whatever, when it if somebody really wants to. Battle that out okay. You know, you really wanna get into a technical discussion yeah. In a product meeting okay, we can do that let me get you think of like a directed development or a CTO or somebody like that. If you really want, I will get them on the call and they will make the case. Assuming I, the product person cannot make the case. Right. Maybe I'm in an organization where your product, people are straight outta college or whatever, what we talked about a lot on the podcast, like your product people don't, they don't really know very much about technology then. Cool. You get your technology person on the call and they can explain why what the risk would be. If we did not. Overcome this hurdle. Yeah. And, they can help you talk through it. The topic we were going into was the case against, against arts. So to transition into doing a Gantt chart versus doing, what you normally see in. Agile development or agile delivery or scrum where you have, release maps, story maps, roadmaps burn down charts. You have a lot of the different ways of measuring what the teams are up to different artifact and forecasting or measuring. Yep. So for me a again, in a product capacity, if I'm gonna compare my, whatever, the equivalent of a Gantt chart would be to, what I would try to do is I would compare a Gantt chart to a roadmap. That's what I would compare. Number one, if I had to do anything, assuming I had to do anything. Right. So, talk to me about how a Gantt chart. And a roadmap are different because on if you look at the two of them on paper, they look very similar. They do, they do look very similar. And I do agree by the way that it's not one or the other. Yeah. Right. Sometimes people say that I, I think fundamentally it's about the granularity Gantt charts typically are not high level. People wanna see the details in a Gantt chart. a roadmap can be high level. You don't necessarily wanna see that every inch stone on, on the roadmap. Yeah. there are tools that allow you to. Derive one from the other. So for example, if you had a reasonable product roadmap, as you traverse down that roadmap, you can then derive a GAT chart without having to manually created sure. the specific tools do a better job of that than others. Most ALM tools do not. There are extensions that you can use for that, but they really don't because they're sprint focused largely mm-hmm. , so things like feature plans and things like that in, tools such as a Azure DevOps, for instance, , they let you do a feature plan, but it's flat meaning it per feature feature a, this is your plan, feature B this that's not, it's not showing any dependencies, it's not showing any phases, anything like that. You could feed all of those kinds of things as work items on a one-on-one or roll up basis into something like aha for example. Right. And having done that, it works really well. so that people in aha, the leadership can see a GT chart, cuz it's nothing more than a series of bars. Yeah. At a higher level that are fed from your ALM and they will see progress on it. I usually ask in the book market and refresh it every time they feel the itch to look at it. so that, that's the difference. It's the granularity. Yeah. That's the first thing I, I would say. And the other thing I've already mentioned it before, which is a product roadmap. Does not allow you to see dependencies across different things in that roadmap. I would agree with that. On a roadmap. I would expect we are calling out features of the application and when we're calling out features, as we implement each feature, we're deciding when enough is enough for the feature. Yes. Whereas a Gantt chart. I think the difference here for people listening, who might be like, oh, a roadmap with a list of features is basically the same as a Gantt chart. It looks the same on paper. It's a bar that says when we started in a bar that says when we ended the difference is when my customer is satisfied and when my, product manager has kind of negotiated the end That could come up to the, I guess it could come up to the sprint. They're doing it in, I mean, it's flexible. It's very flexible. Yeah. The argument here is the Gant chart may be equally flexible. We may be going to the customer at the end of every period of the Gant art and saying like, Hey, is this enough? Do you require more? It, it can be. I haven't seen that very often, but it can be you're right. Yeah. You, yeah. I mean, you're right. Be because of the nature of Gant art being planned so far in advance, everything being planned in advance, like you probably wouldn't get that. You would say, well, you're done when the, the plan says that you're done because you've implemented everything. Yeah. that, and also the fact that it's so onerous to keep a Gantt chart updated throughout. I'd rather see the focus. I know we're deviating from the topic at hand, which is the case against Gantt charts. Or maybe if you flip it around, you're in the right podcast. yeah. If you flip it around though, it it's, why not have a Gantt chart because the Gant chart does not have a product focus. It does not to your point say to the the end user is this enough? Yeah. Right. And they may turn around and say, yeah, we said, we wanted this other thing. We don't want it, or we don't need it, or we don't need it now. So we can use it as is. And we'll see if, if we need it. So we need it later. It might be another project, different budget or whatever., Gantt chart has none of that. Mm-hmm right. It simply has. We expect this to happen at a certain point in time. If you think about a story map, like you, when you draw like, am my epic are here. I, I don't remember my epics are on rose and my stories are in columns and you draw a circle around. I can't like, I'm do not doing this justice, but you know what I'm talking about, you are circle around whatever, and you're saying, okay, this is release one. And you draw a circle around the certain stories, that may span epics, you say, well, this is release two isn't that the same as a Gantt shark? The, well, when you're doing that, right, two things happen when you're doing that. You're saying these stories that I've circled. We want that in a release. Is there a date with that release at that point on your roadmap?, that's the question sometimes there is, sometimes you say, well, at the end of sprint 12. We'll we'll hope to get there. Just for the arguing perspective of people listening, trying to support agile, if there is a date, they probably are not dates picked outta the year. They probably are real dates. Okay. They're probably like I have a team on site at this date, or I have to my budgeting runs out at this date or whatever. They're probably real dates based on real activities, not just. my salesperson promised X, Y, Z functionality in eight weeks from now. it's probably not a made up date like that. It's probably a date that actually has something like we'll do as much as we can to, support the privacy regulation that was passed by the federal government. Right. By XYZ date. Good examples. Yeah. So there could be dates for real reasons. other than that, though, right? If you have those great, we work with those. If you don't have 'em there's flexibility involved through negotiation, as far as when that release could happen, mm-hmm and it could go down several paths. It could be that as a product person, you could say, well, we anticipated a release with these six stories or whatever it is, and we see that the team ran into some headwinds with this one story. Right. You know what? We we'll take those other five and we'll still go with, with that release or we we'll put that release on hold, right. Until that six story is completed. Yeah. In a get chart, you really don't have that focus. You really only have a time based focus. Yeah. And that I think is a detriment here because people outside of the end of the sphere of influence, if you like of the team at a higher level, perhaps were external, I would say external to be safe or leadership certainly. Or. To be more accurate and pedantic it's management, not so much leadership. Now they would look at that and say, on your Gantt chart, you are supposed to be done by this date why is that not done? Yeah. Right. So it becomes an inquisition at that stage and then when you go into the organizations that use Gantt charts in this way, typically have monthly stage gate meetings and you go into a stage gate meeting and you feel like all eyes are on you because you have to explain why what happened happened is, and it feels pretty uncomfortable to be honest. Well, you have, I mean, even in product, you have to explain why things are changing. Well, I meant defend not so much explanation. Well, yeah, no, I understand what you mean, but again, I'm trying to draw, I'm arguing on the side of Gant chart. Sure. But even in the organization where you, you are dealing with typical all playing front Gantt charts versus dealing with customer sprint to sprint. Like I would think that you could say in this, in this spread of the Gantt chart, I'm working with customer a and the next spread of the Gantt chart, I'm working with customer B and we're gonna get as much done for customer a in this part of the chart as possible before we move to the next bar of the chart and deal with customer B, like in that perspective, you're sort of being agile in that you are restricting your effort to everything you can do for a certain persona before you move to the next persona. So you could envision a Gantt chart from the perspective if the bar on the chart is what customer are we serving in, what timeframe then, we could kind of argue back and forth about like, is that enough time? how do you know enough time to please a customer? The back and forth of that is like if you only give two weeks for customer C before you go on customer D who gets six weeks Hey, is that really fair? Like who, which is the more important customer I guess you could do with money? Which customer pays more, right. There are certain ways you can try, to adopt this model. I'm kind of arguing all over the place. When you do a Gantt chart, I think you do it from the perspective of, you do it from the perspective of this is a complete plan from the very, very, very start to the very, very, very end so that we feel that we are in control of the whole process. I think that's why you, we probably should have started the podcast with that's why you do a gang chart in the very, very, very first place. So you feel, you have a good understanding and by understanding, I mean, control of the whole process you got about to endeavor on. Yeah. That's a valid reason why a lot of organizations use Gantt charts. I, I think the other thing is if you were to ask 10 organizations, why you use Gantt charts, I don't know, maybe seven, eight out of 10 might say, because that's what you do. That's how you plan projects. In other words, this is how we know how to do things, right. Because people that are in that level of management leadership, if you're being gracious. Yeah. Um, yeah. Uh, they grew up with this approach of big requirements up front, right. Full planning up front. That's all they know. So that's why they want you to create hand charts. And how do you move them away from that? That's a, that's a podcast in itself probably, but right. I think one thing that might help you is to you not say no, obviously, right. But do a Gantt chart and. Get a commitment that these are not something that are guarantees. These are just, they're gonna move. And don't position, is it, as you know, these milestones I'm showing you and these durations of these activities, they might move. No, they will move because nobody can guarantee when something will start and when it will finish. Yeah. So I wonder if there's labels you can apply when things move for example,, emergence of, , architecture, emergence of regulations, emergence of priority, business priorities emergence of,, different needs, technical needs, team needs, what, whatever it is. So when you go into , your big, quarterly or monthly or whatever, big meaning you can say like, well, we've had to change the Gantt chart. Again, assuming you can't change your organization to be more accepting of emergent changes to your prioritization process, right. And that you're stuck with Gant charts organizationally. You're stuck with GA. I think that's probably the, the main reason we're talking about this topic. Yeah. To try to shift us, , from drive back into a neutral for a second. Gantt charts are they're not really roadmaps. I could see where an organization could liken them to roadmaps. I was like, wow, you start process a, you finish process a, you start process B you finish process. It looks just like a roadmap. And it kind of does honestly it kind of does look like a roadmap. if you think about roadmaps from map perspective, but when you start thinking about roadmaps. less as build functionality a and then build functionality B and you start thinking about your roadmap from the perspective of solve customer problem a and solve customer problem. B the Gantt chart starts falling apart very quickly. Yeah. Very quickly. Customer centric, focus and Gantt charts do not mix, yeah, you start having big problems and,, I would expect that your organization, again, if it's built from the perspective of the Gantt chart, your organization will start having internal conflict and falling apart at the same time. The other thing I wanted to, to go into that we didn't talk about in this podcast was the idea of, systems thinking, because your Gantt chart, if it's only dealing with a very specific thing in the software, and it's not looking at your entire organizational and or systemic ecosystem, When dealing with how we're gonna deal with changes. it's gonna fall short. Yeah. So this is a relatively new, it's not a relatively new concept. It's a relatively new application of the concept of systems thinking. Yeah. In planning. it's been used at a short term plan level before quite quite extensively probably, but, planning it for the whole initiative that an organization's taking on and using systems thinking is still in its infancy. Probably. Yeah. Least from what I've read, I might be wrong. And if I'm wrong, let us know, in the comments. But I haven't seen that very widely applied., what I have seen is, is you say at a team level, people can go in and start applying those principles cuz they are solid principles. Yeah. in, in. I don't even like the term micro planning because it has negative connotation. Mm-hmm but yeah, that's why I've seen it used, I haven't seen it used at a higher level. It's probably a good idea though. If you're coming in at a level where you are influencing the organization beyond just software development. Yeah. I'm kind of torn because if you haven't shown them the value of it, you wouldn't get buyin. So you have to show 'em value in some way, and then you might get buyin and you could take it forward from there. Well, I think, I think you just, I wanted to talk about Gantt charts versus burn down charts because, the equivalency there is, you said in the Gantt chart would be, you said you were gonna be done on this date and you're not, or you are, or whatever. And the burn down chart would be you said that you could be done with 24 points worth of functionality on X date. And I calculated in my Gant chart, 24 points was this. Two or three features and then you could be done. You know what I mean? That the Gantt chart, , versus burndown like you, you, if you're gonna, , equate a false equivalency on paper, this is another one where I could see you equating the two, for sure. It's one of the fallacies in, in doing that is you knowing how, what that rate's going to be. So your team's going to burn down X number of story points over these many days, right? That's not known, that's not necessarily known. You can look at heuristics and say this historically, they've done that, but that's with those requirements, these are not the same. So, I mean, I I'll like, again, like I'll, I'll bring my product bent focus to this one is let's say we're tracking business value and we're tracking velocity, right? Your work crimes have both, they might both be stable sprint over sprint. You might generally do about the same amount sprint over sprint. I mean, that would be the best scenario here. but, , should you manage deadlines? That kind of stuff, like let's use an analogy for that specific, scenario here, right? So, so you're running a, a marathon 26 miles typically, I think. Right? So 26 miles and you're tracking how many steps you're taking.. I don't know every hour or whatever it is. Right. Every, every mile, every mile, every mile, every mile, sorry. Yeah. Every mile, every mile. So the first time when you, you set off from the the opening, like the, the pistol, you, you gungho, or you're not depending on how you're pace yourself, you just hit it. Like you just hit both the values in one, in one, in one track. So you're tracking the number of steps. Mm-hmm, the amount of time it took you for that mile. And you're tracking the number of miles total. You're tracking all, every value you're tracking now. Right, right. So here we go. Like I'm. Yeah. So how would that work out mile over mile, over mile. And does that then project out in a linear fashion to when you're gonna finish the marathon? It, it doesn't well, the Kenyans have proven it doesn't I really know it doesn't. Yeah, yeah, yeah. Right. So, yeah. So I, I mean, that analogy was just really, just to point out the fallacy, the list, which, which one of those is your Gantt chart build off of is built off of your steps. It's built off your time to miles or is it built off your miles? Like regardless of which, which I feel we're transitioning to the case against Gant charts again. Yeah. We are, , trying to summarize the topic because your Gantt chart could be published off of the number of steps. Sure. Your Gantt chart could be published off of the number of miles, which could be short. I mean, if you're in a 5k three miles and then Ooh, Gantt chart's over. Right. Or your Gantt chart could be on the number of steps up. I which game, which shell game are you gonna play? That's exactly right. With your game chart. Yeah. Cuz these professional runners, they. I don't wanna use the word manipulate. they will vary up all these things, including their stride length, things like that. Right. Based on a number of variables based on the weather, based on what the competition's doing based on whether it's a hail uphill or downhill. Yeah. Based on how they're feeling, uh, that, that piece is completely out from our discussion. Also, also gut feel also based on how close they are to the finish line. Of course, of course. Right. Because that, because they, because everyone sprints sure. Regardless how tired they. When they see the finish line, everyone sprints to the finish. Line's right. That's very true. That's very true. Some people leave more in the tank than others. Right. But yeah. So leaving just this, this kind of gut feel factor out of it, too many variables in this. Right? So multi-variate analysis maybe, but even that assumes linearity and that is what's different in developing software is you seldom have it. You, you really don't have it and you don't have it. Even if the team is the same, but it's a different application you're building because you are learning and you're discovering new things all along. As you build things and you learn things you're gonna be changing. I don't know your estimate. I don't wanna even wanna say your estimate. Like re projection's probably a better way to go. Yeah. Yeah. Like your forecast, your forecast. That's another way to say it. I think the summary for both of us is like, don't do can, like can't trust are ridiculous. Don't do Gantt charts. like, that's a good summary. Don't do 'em because they're not value added. Right. They say, well, I mean, I mean like, okay, you're gonna do them let's talk about how you're gonna do them are you gonna pick the number of steps, to run your marathon? Are you gonna pick the miles to run your marathon? Are you gonna if you're gonna pick miles in Gantt chart okay, are we gonna use miles for everything else? Like, well, how many miles does it take? You learn in a new technology? How are you gonna represent that? Even, if we break the three different things down to say, The effectiveness of your solution, the efficiency of your solution and just the bulk time of your solution. If we were to break 'em down on that, like you, you basically have to pick one to represent your chart. Okay. Yeah. Even when I do my backlogs as a product person, the team has its story points, estimates, man hours, actual hours, literally, whatever they want, no hours. Whatever, ever every story is a one. Right. whatever they wanna do, that's for the team. For me, the product manager, I have my business value. That's an arbitrary number I set of how valuable I think it is. We both have our own arbitrary. Like which one are you. Project manager gonna pick. Well, awesome. The question, right. So again, falling back on the analogy, if it doesn't matter which one you pick, as long as it's the consistency there, right. As long as it's the same one to your point, if you're using business value in point some there's some quantification of that. Yeah. If you're using business value on whatever scale, if you're always using that business value delivered per month, whatever, that might be a metric you could share mm-hmm and you could put that on a chart and you can call it whatever you like that's okay. Right. I, I think that's okay. As long as people understand, this is not a guarantee it's really backward looking because you're saying over the last six months we've delivered this or two months, whatever, therefore projecting forward, we can deliver the same, that, that throws away the idea that we're discovering something new so that it might not be the same, that that's an understood assumption or built in caveat if you like, but there is one reason to do a Gantt chart, but don't spend a whole lot of time on it and that just, you could use software to do it. And most software allows you to do this. Once you've done this, I suggest you completely throw it away and that reason is this. If you know the activities you have to do, and if you know roughly how long it's gonna take, it's a guess, but let's say you put the guests down. Most software, Microsoft, Microsoft project, for instance, and others, they let you. Create what they call a network diagram out of this without getting too P what it will do is it will give you the critical path in that critical path and don't look at the, the numbers here, just look at the path and say, according to this F has to be done before B, otherwise the whole thing slides just that knowledge alone is worth doing a game chart. If you were forced to do one, that's the reason to do one mm-hmm and then throw it away. I'm not saying that knowledge cannot be gained another way. This is the quickest way, throw things in there. Put some times on very quickly, find out your, your critical path. And now that you know that you can adjust your backlogs accordingly, and then just throw away your, I don't know, I feel it's, it's just a, a lot of overhead for me that I just, I honestly don't need because two sprints in, I could decide that the business, values something else more and I could throw away all of that planning that we had to do for X, Y, Z, or whatever. If your team is doing scrum, there's a certain percentage of overhead, with regard to the model of scrum, which includes, , backlog refinements. If I decide to pivot and I have to do significantly more backlog refinement, am I breaking that number? I feel like I am because I'm throwing out a bunch of previous planning that we did. I feel it was, this was a helpful discussion from the perspective of, do I understand what people looking for Gantt charts are looking for, the people looking for Gant charts are looking for a plan of everything end to end every potential feature we ever could deliver. And, I, as a product person I could decide at a whim it's not really that's yeah, yeah. It is more, or my expert investigation campaign. Sure. But honestly, at a whim I could decide, like we're just not gonna put any more money into whatever initiative and,, we're gonna pivot and do something else. So I really don't see a reason to plan more than two or three sprints ahead at the absolute most I agree. Or, or if I'm planning to two or three sprints ahead, I'm planning two or three sprints ahead from a very high level feature level, we're gonna deal with the functionality X and you, as leadership might, might say, what, what does functionality X mean? and then I would rattle off three or four features that may be included in functionality X. Right. But when we get closer, I reserve the right to take stories in and out of functionality X, as we talk to the customer like if you work in Azure DevOps, right? And you have epic, and those epics have features, and those features have stories, we'll break it down to that level,. you might start with, oh, here's an And the way we're gonna do that is we're gonna implement feature X in the inside of feature X. We're gonna do story one story, two story, three, story four. But that's what we plan. We talk to customer, we get started. We do story one customer likes it. We do story two customer really likes it. Very happy. We do story three customers like this is great. Feature. 4, 5, 6. I don't really care about 'em. Yeah. I got mounting pressures from other teams. I decided, you know what? I'm just gonna cut feature 4, 5, 6. I'm gonna cut 'em out of that feature. I'm gonna move 'em to a future thing when I come back to that customer or when they give me money or whatever, and I just decide, I call the audible and I just decide we've done enough for this moment in time where this feature is done for now. Right. And I make the call as opposed to six months ago, we decided we were gonna do six stories under feature, whatever ax, whatever I said. Yep. And now since we made the call six months ago, we have to stick to what we said yeah. You know, again, if some project manager who, again, wasn't even talking to the customer in the first place, decided that stuff months ago with a team who may have been contractors who aren't even here at the company anymore. And now I have to do it with my team or whatever no, no, no, no, no, no, no. We're not gonna plan that way. We're not gonna operate that way. We don't need that. I will talk to the customer. I will sync up with them and we'll do what it takes until they reach a certain level of satisfaction. And then we'll pivot and we'll go to something else. I, as a product manager will take on that responsibility rather than delegate it to some, some outside person whose total job is not actually accountable or responsible for any actual implementation of the customer needs. Yeah. Yeah, no, I couldn't agree more. Yeah. I could not agree more with what you've just said. Big requirements, big planning upfront really seldom works. And the only way they make it work is that person who's full-time job is to keep planning and updating the plan is to Rere baseline re re re. And then a month before they go, this is our go live date. And then turn around, say, see, I told you, right? Yeah. Well that, well, that person's full-time job is to manage us, manage, manage all of the people that are responsible, target customer, doing the actual work, all the people accountable and responsible for the work. They they're just their job is just to manage us. I don't see that as a necessity. we can self manage. Sure. We can self organize. We can talk directly to the customer and, to take it to the next level, to completely divorce myself from the point that I was supposed to be supporting. At this point, we can talk to leadership as well, and other members of the organization sales, right? You know, whoever else that we need to talk to account management, whoever we need to align with to say this is what we're doing to satisfy the customer. This is what we're doing to deepen our relationship. This is what we're doing to solve their problems. We can align that. Well, we don't need a professional manager. We absolutely don't. And I think agile leadership understand that unfortunately, they're a rare species even today is surprising even today. Yeah. You don't see too many of them. Yeah. But yeah. So the bottom line is don't bother with Gantt charts. Yeah, yeah. I think that's where we ended. I tried to support the side of the Gantt chart, pretty, fairly, through three quarters of the podcast and I just couldn't myself. Well, it was pretty good. Pretty good attempt. Val attempt couldn't help myself anymore. It was good all well. Hey, if you, like to podcast, we appreciate all likes. I probably already have stopped, the editing at this point. Yeah, I know. That's cool. That's cool. Gantt chart. Don't do 'em can't even spell Gantt most of the time.