AA146 - Our Most Viewed Podcasts and Clips

We here at Arguing Agile like to do occasional retrospectives on our content and talk about what we're doing well and what we should stop doing. And other than Brian should stop talking well, it's the end of the year, so this is an opportune time to look back and see what worked and what didn't. That's true. We're looking at the podcasts that we've done. In some cases, clips, that have received the most views on YouTube, only using YouTube in these analytics the audio product is a little bit different, gives a little bit different metrics, but Out of six, arguably seven. Of our most viewed of all time podcasts. We're going to talk about, we're going to talk about the podcast, and then we're gonna talk about why we think, why we think that it, it was it received so well. So the number one most viewed podcast that we have out there, or as the younguns might say, the one that went the most viral. You're right. Yeah. I, I think of our of virality as a, a, a slow steady burn. Over many, many years. Yep, that's true. Sorry, I can't, I should never say Virality ever again. Yeah. The, the episode number 17, it was the Scrum Master's role in release planning. Ooh, so that was quite early on, actually, number 17. I was not even editing, so it was really remarkably terrible. Rough and raw. Yeah. As it was. And this wasn't a clip. This was the full, the full. Podcast, right? Mm-Hmm.. Mm-Hmm.. So, I mean, look, one of the things that we pride ourselves on is touching on subjects that other podcasts don't. And this is one of 'em, right? The Scrum Master's role in release planning and deployment. Yeah. I haven't seen that addressed in other podcasts since then, even really. Although I don't necessarily profess to know all the podcasts out there. Yeah. But I, I suspect I have some recollection of this. I suspect it's because scrum masters themselves find themselves involved somehow, and they don't have any support for this particular aspect of their work anywhere. So that's kind of Delving into it has to be something of interest to the Scrum Masters, which probably is the reason why this was the number one. I put up , our notes from that session here on the screen. I think probably a lot of Scrum Masters get asked to help in release planning, either release planning or release notes. Right? At least release notes, or maybe, maybe even part of the, what I think is a more powerful way to help in release planning is stakeholder communication when a release goes out. Hey you know, we put this release out, maybe we need to get stakeholders together to review the release, or maybe we need to, do the demonstration to the users. Scrum Master can help a lot with that stuff. Like, there's a lot of that in here, we even have a chapter heading called Backup or Redundant Communicator, right? Which I will tell you, I rely on my Scrum Masters as, as a product manager a lot of I'm, I like, I'm moving a million miles a minute. It would really be helpful if the Scrum Master can help with that. Customer communication to let them know, Hey, we're about to put out a release and here's what you can expect. And then when the release is out to get some customers lined up for us to kind of walk through together and watch how they receive the features. I would appreciate assistance when it comes to that stakeholder communication so that we can jump to get stakeholder collaboration for our releases. Yeah, I think there's a couple of other areas that are kind of allied to what you were saying. I mean, some in some organizations that communication out to customers is responsible is the responsibility of a separate matrix group, perhaps like change management. So there's still coordination needed who feeds them right? And it's not just before the release going out. It's well before it's coming out in person. 60 days, 30 days this weekend, and then after it's happened, here's what we've just done and then follow up, right? Whether it was a success, to what degree, how many people used this new feature, and so on. So, the, the, it's, I'm yes handing you, basically saying the Scrum Master could be the linchpin here, communicating with, in this case, a change management group. The actual mechanics of the deployment, going to that second half of the, the title of the podcast, right, which is Scrum Master's Role in Release planning and deployment. So in some organizations, you need to do some mechanical tasks basically that are self imposed on the organizational front. But these are, these are stage gates like having to open a ticket to do the deployment, which is done by some other group again creating RFCs and and and the like, so the scrum masters can help there as well. I've kind of been on both sides of the fence here, right? As a scrum master, a long time ago, I was asked to write the RFCs, but they were very technical in nature. So all I would be doing is getting in the way, asking the tech lead a whole bunch of questions. So we ended up abstracting what was in the actual RFC into some simpler form. Two or three. Fields on a Google form and ask the tech lead to fill those out all of the other mechanical stuff, which environment we're going to, et cetera, et cetera. You know, has it been tested in lowers? So on? I took care of that as a scrum master because it freed up the tech lead again. It has nothing to do with product at that point, because the decision is already made ahead of time that we are launching this. So yeah, there's a lot that scrum master can do in terms of facilitation off all of these things. Yeah. We've got probably about 15 topics here. Yeah. One podcast. There really was, there really was a lot. It really was a tour de force of topics. Tour de force. the non helpful thing in here is for the Scrum Master to be like the, the person who in large organizations goes around the organization to submit all the forms and all the like, oh, you got to let this team know this is happening and you got to queue yourself up for this approval or whatever. Right. Like, I, I don't think that's. That's the helpful part of this. I think the helpful part of this podcast, Scrum Master role in release planning is all the things that get you to the release. The feature mapping and the planning of what stories go into what release and the lining up of stakeholders for that release to make sure that they're available, right? Cause you can sit down with your product people and say, these are the most. These are the most valuable features, we all agree, maybe you have some kind of prioritization or framework or something in place and but then you can never get those users on the phone and they you can never, so it's like, we all agree they're the most important, but also those users are like, yeah, yeah, they're difficult. Yeah. Yeah, I agree. It says the Scrum Master is rolling in releases But even if you're playing the role part time, you're a developer on the team, and you're playing the role of the scrum master carve out some of your time to try to do, these mainly communication based tasks. They're absolutely critical. Because they're critical, yeah. Because you can easily not take responsibility in this situation to be like, well that's a product, that's a product's job, that's a product's job. You know, that's not my job. I easily could see that. And honestly, that probably in a matrix organization where you work for a developer, that probably would fly. You probably would get away with that. Yeah, I agree. I think but you know, as a behavior, right? It's actually not a good thing to say. That's not my job. You don't have to necessarily carve out time every, I don't know, every sprint or whatever. This could be as and when, depending on when the releases that. And then the other thing is, if you're playing the role. If you're on the team and you're not a, you're not a scrum master, you're playing the role, say you're a tester or developer, you can rotate that. Yeah. It doesn't have to be one person. Yeah. I I'm thinking of a world where you, you rotate the role of scrum master and then you just happen to. Throw the unlucky dice and come up where we're putting out a release like I think of like large companies But they don't put a release out every every week or whatever. They're you know, or every day let alone it's like I don't know if I brought it up in this podcast, I Often have been on teams where they release As soon as it's done with a story and they have good solid CICD practices and it goes to production immediately. So there's really no reason to like coordinate a big bang release or send them all to stage as soon as they're done, but then hold them all on stage until some big corporate person gives us a big corporate thing. Thumbs up with their big corporate thumb or whatever. I don't know what a corporate thumb is, but that's just incurring a holding cost the whole time, right, right. I'm cutting way ahead, but Airbnb, like in the, in the Brian Chesky interview, he said that they did this, they, they held the releases so that they could like build up a lot of marketing and build up a lot of anticipation and feel like they were making a big splash when they released every twice a year or something like, I don't remember how often they released twice a year, four times a year, I don't remember, but they held the individual releases. On purpose, so they can make a big splash and build a big marketing thing around their releases. So, Apple comes to mind right away, right? Sure, yeah. They bring out a phone every year or two years or whatever and they hold that. But the date is already decided up front, right? You know, September 12th, the new iPhone's coming out. iPhone 84 or whatever. So, that's another example of how that can be done. But, releases here, they don't have to be GA, they can be internal. So I know in Apple's case that they have releases internal like in the case of Airbnb too, I imagine where internally a team is releasing something to another team. IOS could be being released, a camera module could be being released, etc. But the whole product isn't until a certain time. Right. You bring up a great point. About Apple because whoever's in the role at that point could know that we have several features that are in the micro releases. Like if you're going to go with the, the, the, the public release versus the internal quote release, I guess, in, in, in terms of Apple, I have to suspect that they know what features are being introduced and they're testing them and releasing them. Even though Apple's choosing not to send them out to the public, they know that these features are coming. So, I would expect that Again, if we're talking about the scrum master's role in release planning, the scrum master then serves as a communication conduit to, I don't know, sales, marketing, whoever else, whoever those consuming teams are at that point in the game, to say, let me make sure that you know exactly what features are coming. Let me make sure you don't get skipped or you miss anything. So there'd be regular touch points or regular releases or demo, or maybe internal demos, not quite sure. maybe a reason why this is like the number one most viewed podcast is, the Scrum Master can add a lot of value by saying, hey, I can serve as a bridge to connect with these other teams, and then kind of walk around the organization to figure out how. And when they should connect with those other teams. Absolutely. And bring feedback back to the team. You're right. Yeah. Yeah. Yeah. And keep expanding that circle to make sure that the team's influence keeps growing and growing the team's influence and the. Communication and that kind of stuff keeps growing. that would be a cool podcast to just completely revisit in and of itself just release planning. Let's put that on the to do list. In the number two spot for podcasts is acceptance criteria in user stories for us acceptance criteria in User stories. This is a super interesting one to be in the number two spot because because of its tactical nature, it's a very in the weeds in depth Hey, let's talk about acceptance criteria. When we do podcast topics, I often think of like, I want to talk about. Systemic problems, like problems with the systems. But then sometimes I want to talk about like real, like how I do things as a product manager and form a core practice, core practice, how I do real nitty gritty stuff. This was one of those, like how I do real nitty gritty stuff. how I work acceptance criteria into my stories and how I get the team thinking about acceptance criteria. And I'm, I'm, I'm not really shocked, but I, I am surprised that this is the number two most view viewed podcasts that we have. Well, this, this was a full podcast, right? Over an hour long. And we have sub topics within this. We have, I don't know, 20 or so, I'm guessing at a glance. That there's a lot into this podcast. I also think that over the years. This is something that just repeatedly keeps coming up for definition or not abiding to a C's or just doing them as you know. Oh, we're checking a box, right? We create them and then we forget about them. Those sorts of things. There's many different anomalies that we tackled here. You know, I'm just looking at the list here. Scope creep. I mean, there's a lot here. We also, we walk the line of yes, we can define these up front. And then when the team gets into it, they might learn something and what happens now, right? Because oftentimes people say, well, no, that's a different story now because it doesn't meet the AC because you're just so pedantic about the ACs. Whereas I think in this podcast, we talked about how. It should be fine, based on the new learnings, to go update your research. Sure. Right? Sure. I often will describe acceptance criteria to my teams as if I were demoing the story to the user that is named in the story. First of all, I guess that's an assumption, right? Do you have a, you have a persona and that persona is represented by a person and that person will be at your sprint review. But if, if I am demoing the story to an individual, no matter what the individual the, the. Acceptance Criteria will be the checklist of the demonstration. I will walk through Acceptance Criteria 1, and then I'll walk through Acceptance Criteria 2, and then Acceptance Criteria 3, and hopefully there's not a lot of, hopefully there's not 20 Acceptance Criteria. Like, I don't know if, I don't know if that was in this podcast, but but, hopefully there there's a single digit number of AC. Hopefully it's five or less, right? These are just general rules. They're, they're, they're not rules at all. They're just like my personal preference. I would like the seven criteria to be. Fairly broad, not technical and the ability to say, Hey, next we're going to demo this and just call out the acceptance criteria because there potentially could be a lot of flexibility in there. But also if you're adding acceptance criteria to stories after you start the sprint you have a problem with that right there. Like that, that's where we were going with scope creep right here. Like if you're doing that. It does indicate a problem. It does, it does indicate to me that you did not fully understand the story when you started. Again, I'm, I'm talking generalities here because it's, it's obvious like you can get into work and you can figure out things in a, especially if you're not familiar with the code base of the product or if you have new developers or whatever. Sure, but generally speaking, generally speaking, if you get in and you have to add acceptance criteria as you work through the ticket. That's an issue for me. I, I agree. Because that, that shows that the, the story wasn't ready. Right. Right. You probably shouldn't have picked it up because when you pick it up, you have some confidence that you can finish it in the script. Well, well, I mean, to, to be fair, to like, it's not ready, like it may have been ready from the business perspective, AC is a tricky one because. I've had teams that they want me there's a product manager to write the description like as this type of user, I want this functionality so I can derive this business value. And then they don't want me to write the acceptance criteria until not at the backlog refinement. Right. They want to wait until they're in sprint planning to write the acceptance criteria. And at sprint planning is when they'll decide to break the task in half. And when because it was like, when they're in that section of the code, looking at it in sprint planning, and, and they're in the database, and they're looking at the tables and what they have to do, then they'll start negotiating of, of, Hey,, we can do functionality X, but if you want functionality Y, we have to modify a database table and that's going to be more involved than it's going to go from being a three to a five and maybe that's the point for me as a product manager to say, I don't want it to go from a three to a five, I'm fine pulling this out or like, like I think of like putting up a new API endpoint, for example, I do this all the time and I'm pretty sure my team hates it, but I do it all the time. Well, I'll say, I'll say, Deploy the new endpoint, make sure that it takes these criteria as inputs. But then no matter what you put in as an input, give me the same output. Just put like Brian says, hello, as the output, no matter what it is, because like the idea of throwing the new endpoint out there, getting the authentication in place, getting the deployment in place for a team that doesn't have all this stuff in place. Right. Like. All that stuff is going to be hard enough to figure out, let alone the business logic that is inside of the container, that API endpoint to say like, Oh, if this, then that, then this, I'll normally ask teams when they're doing something new. And like, listen, I'll strip all that business logic database back end stuff out. Just let me, let me hit it with the correct inputs I'm expecting. And then next sprint, we'll make it work correctly. Like, you know what I mean? But we can demo that. We can demo, especially if there's a front end involved. We can demo that. Right. Log in, log out. Exactly. So the contract could be written up front, but the you can Progressively elaborate the pieces of it, right? Sprint X, you can have these two things working. Sprint Y, it's going to be those two plus maybe one or two more, etc. You can do that, depending on how big the payload was. Yeah, I like culture and facilitation affect acceptance criteria. Culture and facilitation. Because I've been in a lot of organizations where the acceptance criteria becomes a set of development. Tasks to get things done, which are, which you, you could not demo. I agree. I've seen developers write tasks instead of ACs and just say this is done, this is done, this is done. The last task is done. The story is done. So you try and demo that that's going to be a tall challenge. Yeah, and, and also if you, if you're going down the. Road of the acceptance criteria becoming like the development tasks basically if you're using Jira or whatever tool if that's the tool you're using you have epics and stories and subtasks and the subtasks are meant to be the developers like How I'm going to implement What the story asks for. But the acceptance criteria when you create a new work item, it's not like it stubs out, like put your business subscription here and put your acceptance criteria here. It's just like a blank slate. So you have to bring the yeah, anyway, whatever. That is one thing that that was very helpful when I put the template in place for Azure DevOps, right? Yeah, you create a new user story. It puts a not only the The sentence that says, as a, in parentheses, and all someone has to do is replace what's in parentheses. So it says, as a, persona, in brackets, I want, in brackets, what the need is so that, the why, right? And then in the acceptance criteria field we decided to go with one of two different ways, depending on the team. One just simply said, verify that, and then there's a bullet list of things to verify. Well, the other one was the You know given when then kind of construct. Sure, sure, sure, sure. But the teams don't have to worry about what to put in there. Cause like you say, you have junior developers and they're just gonna go focus on the dev part of it, right? Right. Yeah. I I actually would I, I as product, I wouldn't mind if the team pressed me to do given when then, because like, if they were like implementing some kind of like automation framework I think it would be a very minimal lift. For like a singular number of people writing the requirements, quote requirements into the system to change the way that they work, it's like asking like four people to change the way they work versus asking like. 50 people to change the way they work. Sure. Just write the requirements instead of as a whatever, I want whatever, so that whatever is a given this condition, you know when whatever, I want whatever. That's pretty straightforward. I mean, the only thing that you lose is maybe you lose the personas. Maybe you lose the personas or the business logic, but you, you can still include the business logic. Okay. As, you can be as verbose as you want. And also. I would argue, all that stuff should be in the Epic. It should be at the higher level. It should be, however, developers aren't going to continually keep looking at the Epic, right? No, no they don't. Yeah. That's why I'm a big fan of the Mike Miller model, right? One actor, one action, one result. That's right. That's right. Mike, we got to get Mike back on the podcast. Yeah, it's been a while. so Another one, this is number three of you keeping count. In the next slot was our clip on budgeting, agile budgeting versus traditional budgeting. Since the beginning of the podcast, since episode one, I wanted to do a whole podcast on a better way to do software development budgeting and talking about CapEx and OpEx and talking about how software capitalization works and how you can get capitalization numbers out of Azure DevOps and or JIRA Or any ALM, could be JIRA, could be anything. I've wanted to do that podcast for a while. I, I've not kind of pressed the issue because number one, there's a lot of prep that's going to have to go into that. We're going to need examples and spreadsheets and like red string and conspiracy theories and all kinds of stuff. Number one. Number two, um. that's a really uh, expected to be a really dry subject. I think we may start on the next one on that broadcast. We may start at a different level instead of just simply going into traditional versus as your project budgeting we'll start off by just simply saying should be fun. Projects or products, and then we get into how, right? Maybe that, that'd be a good, solid podcast. Yeah, yeah, yeah. Well, I mean, the, the, the CapEx, like the CapEx amortization strategy, the debt leveraging strategy of taking the cost of your development team this year and, and leveraging it over three years in the this year and then two more years in the future. Mm hmm. That, that works when you're trying to You know, when you're, when you're trying to scale quickly, so, so the idea is, is I can hire three times the number of employees for this year. Maybe I bring on a contracting firm or something like that, right? And, and, and I accelerate my software development and do like three years worth of development. So that I can get my, my platform or my software package or something to a certain point. And then I roll those people off. And then I amortize that over three years. It, it's, it's, it's a strategy to accelerate your software leveraging debt right over the next couple of years. That's, that strategy is not for everybody. Oh, it certainly isn't. I mean, if you're not vigilant about your market space for one thing, right, three years, what's the, what's still a burning need at that point that you saw now, right? And then the other thing is the whole net present value of dollar today versus three years from now. Yeah, but there's a whole bunch of other things that that we need to consider in this as well, depending on the financial model you use. Yeah, I really want to do the I really want to do the Agile, CapEx, OpEx, like a general familiarization kind of podcast in and of itself, because it still kind of arms you to understand the pitfalls of this traditional budgeting cycle I don't know when the end of your fiscal year is going to be, whether it's going to be October, so that like around September time, you're going to come and start talking about what you need for, quote resources for next year, right? Or if it's the actual end of the year, end of the year. So then you're probably doing it in late November or whatever, right around holidays, holiday season, right? When everyone's trying to go out on vacation, you're trying to talk about budgeting. It doesn't really matter. There's a better way to do that. And it's about micro budgeting and you can bring this to your finance people and they can research it because they should be the experts. Like you can bring these new fan dangled ways of working to evolving agile team, to all of your old school employees. And like they should be able to work with you to, stretch that money that this goes into contracts and it goes into a bunch of, it goes into a whole different side of the organization that the software developers, scrum masters, product people, maybe anyone who might listen to this podcast might not, Normally be exposed to, but that's the way that this whole side of your organization thinks. So you really need to be able to speak their language. Yeah, I think it starts with trying to explain to them this idea that budgeting for the next fiscal year up front and then putting out these lofty goals that say You know, we're allocating 10 million for the next fiscal year, and for that money, we want this, this, and this. Like, you don't even know if that can be attained with that money. You know, so, yeah, we'll start with that sort of an intro, I think. Well, you also don't know if the market is going to absorb that. You don't know if the market's going to accept that. There's a whole discovery process involved. And the, the, the money should be structured to support that. But the whole yearly financial planning type of cycle, the idea there is you only get to replan plan or replan one time per year. You only get to inspect and adapt. One time per year. And it's probably too late by that time. Anyway, that seems really, I mean, it really seems like an old school, very old school layer on top of that, these asinine things like. You know, let's say your, your fiscal year is the calendar year. So come November, you have money left over by some miracle. Well, you can't roll it forward. It's use it or lose it. Send people on some training classes in Hawaii or something. I mean, come on, what a waste of money. Well, or you're going to buy things that you clearly Don't need right and and and then and then you got okay ours and stuff like that at the end of the year that you're Trying to mesh with this new system to say well we spent money on this tool. So you have to use it like things like that. Like it's a double edged sword because if you have that money left over the budget left over and you don't use it, not only can you not carry it forward next year, you'll get that much less, right. Right. You know? So it's like a lose, lose all around. Yeah. Well, you had this budget, but you didn't use it. It's a very accusatory right now. Yeah. You, Oh my goodness. That encourages. You know that biases you towards overspending right and then you go back to the well and they say no Oh, man, where do we start with? Yeah, this would be a really good really good podcast. Yeah, at least a two bourbon podcast. Oh Well, I'm I'm ready I will I will buy it right now Next one also, by the way has both of us in blue shirts. I don't know why that's a theme a clip from Agile Podcast 10? So the next one we have, it's delivering roadmap features and milestones in Agile projects. I think, I think the reason that this was the most viewed is because it has to do with something that we explored actually on a later podcast about Gantt charts and about how traditional organizations do project planning. Like they have their timeline, they have their money and they put both of those on a timeline with little, the little diamonds on the top with the milestones that they just pull out of the air and say, we want to be GA by this day and we want to be whatever by this date. You can do that. In quote, agile delivery. Okay. That's super easy to do. equate it to like the planning for alpha release, beta release, GA release, that kind of stuff, same thing we talked about earlier in the podcast about Airbnb, Airbnb will hold its releases. Until they can consolidate their marketing activity and then they'll announce the date and they'll drop it. Same thing with Apple. Apple sure picks dates way out in the future. Oh, 15 months from now is gonna be our big conference, so let's spin up what we can spin up for that conference. They're releasing very quickly and iteratively, I'm sure. Mm-Hmm.. And then holding those features to demo the most impactful of all of them. At that conference, that's, I'm not saying that you can't do that. That's completely fine. However, the constant release process is happening on the back end, regardless of what you publish as milestones. You can even pick dates out of the air and say, I want to do this milestone by this date. And then your teams have to figure out what is as much as we can do to deliver those features? By this date. It sounds like it sounds like the implication of like like, like the early 2000s development where you had to like work nights and weekends to deliver whatever by by an unholy date or whatever. Do what you can, okay? But the milestones at the top of the chart You can still do that in Agile. You certainly can. I think in traditional project management, the thing that went wrong is you set up these dominoes and each domino was a, was a milestone. Sure. So you miss one and the whole thing just goes tumbling down. In the case of Apple, Airbnb, or whoever else is doing the new way of working. Yeah. I mean, you set out a date 15 months in advance. And as you get closer to it, you've got features that are being completed. Sure, you'll find yourself with one or two features that may not be complete. Right? Sure. So fine, make the scope flexible, leave those out, and then bring them out in an update later. Yeah. That's how they've been doing it and it works. Well, if you're building your milestones where they all build on previous ones. Yeah, I know. I mean, you have a problem right there like you have a problem with dependencies and that now we're talking about dependency management and we bring in Red String and we bring in people whose full time job it is to reduce dependencies or whatever you have a problem with organizational design that's manifesting in your roadmap at that point. Yeah, it's quite a circus this whole dependency management when you want to nip it in the bud and just simply Resolve those dependencies instead of putting them on a wall with red string. Resolve them as fast as possible. Minimize them. I thought it was really interesting. Milestones, milestones. I really didn't think that would be one of the top contenders for our most viewed podcast. But I mean, honestly, it makes a lot of sense because probably a lot of scrum masters and, and really even product people they probably have the screws put to them to say, tell me when X, Y, Z is going to be done. And, if I am a product manager in an organization where my leadership dictates to me you must get this done by this date or whatever milestones make perfect sense. You can call them something else if you like, but yeah, I mean, look, milestones have been around for decades, right? Sure. And one of the reasons why I think this podcast was of interest to a lot of people is because you've got people that came up. Through the the old ways of working with milestones like project managers who are now. Relabeled as scrum masters, perhaps, or even product people. So they are familiar with the terminology and how it was used in the past. So I think you're right. It's just a, it's just a tool and it can be used going forward as well. It's also, it's, it's just not like Agile, scrum, the scrum guide doesn't. Cover milestones in any way or form, like product management is like in another discipline that it, like they don't really cover milestones, or release management, which is kind of in the same vein, right? They don't, I broke it again. They don't really cover any of this. So it makes sense that people are looking for these things Absolutely. Outta the internet. Which brings me to our next Most viewed podcast. This is an interesting segue, which is the Gantt charts in agile software development. First of all, just to be super clear, where's my camera just to be super clear. Gantt charts are ridiculous. You shouldn't do them. Yeah, Gantt charts, however, are the the fabric on which milestones are hung. Right. Typically in the old way of working, you shouldn't do Gantt charts. Yeah. Do this by this date or else, or else, well, that's the thing. I mean, you can put out aspirational dates, but don't kill people if they don't make them. Right. It's the, or else piece that makes them useless because people are going to work under threat. And even if they magically met one of those, just. Randomly, right? What's the quality of that delivery going to look like? Because they were working under pressure, under the gun. Too much pressure. Too much pressure! Tweak! Too much pressure! I've got nothing good to say against Gantt Charts. There is nothing good to say about Gantt Charts., in retrospect, sure, all day long. I'll give you a, I'll give you a yesterday's weather of Gantt Charts. And it'll be correct all day long. All the time. Right? But if you want Gantt Charts Looking forward? It's really hard, though, for you know, a lot of the people that say that came up working through the Gantt charts method, the traditional project management method. You can't wean off those people. this is the reason why I don't know. This is the reason why you have ALM tools give you all these Gantt charts. They create like any product planning tool they have a Gantt chart view of your product. But their intent is not you start there and you finish there. Their intent is, hey, if you're familiar with this view Look, there it is, right? That's it. That's what, that's how I use it. Anyway, now's the time to say this podcast is brought to you by any a ALM tool, possibly Jira. It could be any a ALM tool that pays us to give you project management tools that don't really help you with your job, but give me all the money in the world. We probably could do a podcast on a dozen ways. of projecting what your roadmap is going to be like. Creating and then projecting what that roadmap is going to be like. And these companies, they just love money so much they're just willing to throw their principles out the window just to collect a buck. So I agree. First of all, I think it's very dangerous of these companies to do that because what's going to happen when these folks see the Gantt charts, they're going to gravitate back to what they know, and they're going to ignore the agility aspects. And they're going to say, this is what we have to do is just now become a Gantt chart, right? I mean, right. May as well just give them Excel or something. Well, you know, the other, dangerous part of this podcast on Gantt charts is the more these vendor tools that are quote, Agile tools integrate this functionality in order to make a buck, in order to make a sale. The more they're propagating, they're like, oh, Gantt charts are agile, totally. The more they're propagating bad practices. That's what I'm saying, it's dangerous. That's why, it's dangerous to agility, basically. Alright, well, look, we need to take a turn from the negative back to the positive. And speaking of positive we're gonna go to episode 120. Did AirBnB fire their product managers because that's fun. This was this was our foray into, like hijacking a current thread, a current trend in the market. About I was going to say, calling out Brian Chesky. I don't know if it was really something. No, it wasn't just like. So this is. Analysis. Analysis. Yeah, it's analysis of a topical news item that was very popular at the time. Right? It was all over social media. Mm hmm. And so we figured, why not? Right? Yeah. People are, people are. Yeah. Considering this. And yeah, we, we did a pretty decent job, I thought. It's probably about, again, maybe 15 or so subtopics under this one. This was a full one. This was a full, not a clip, this was a full podcast. Oh yeah. we're getting to the point where like, our most viewed podcasts a lot of these are over an hour. Other than the clips, a lot of these are over an hour. Full podcast. Yeah, but the views are over an hour and it, they're our most successful videos. Like this Is, this is honestly, this is like, this is saying something to me. Mm-Hmm. And I, I was editing in one 20, so if it, if it ended up being an hour and three minutes at one 20, I know we went, we easily must've recorded for an hour and a half. Other than Brian Chesky's like hot takes and the clickbait or whatever, like the, the analysis here is he claims that he got rid of product management in the typical traditional quote, traditional. You know, style of product management, but what he was really saying was like I, I need product managers who also understand product marketing and also understand design, right? He kind of scraped off the top of talking about, Marketing, but he really dove deep on talking about I need product managers who also understand design it was real Important to him in his organization the product managers could understand design and I've watched him in a few other videos. I think what he means by design. Is Systems thinking. Yeah. It is more of a holistic viewpoint, right. Than he's taking, he's not not thinking tactically designing anything necessarily. And, and since this video, I've kept Airbnb kind of in my peripheral vision or peripheral vision. One of the I, I've, Ferral is an R in there a second. R Oh, yeah, yeah, yeah., it's on my radar and I've, I've kind of been watching Brian Chesky as he kind of recaps what he said here in this video that we watched. And yeah, I, I really think design thing is really where he was going with this, which is I need my product managers. To be thinking of the, the, the holistic view. I need them to be coordinating with each other. Like they're, they're not just in their little silo. Right. Their little vertical slice of oh, growth or whatever. Retention or whatever you mean. I really need them kind of talking to each other, so like, this would be a good one. To revisit in terms of, well, the product manager should be in their vertical and they should be concentrating on features that hit their OKRs or whatever, right? And they're a little vertical, but also they should be in a horizontal with the other product managers to say, well, what are you doing? What are you, what, what features are you introducing? Let me be in the know about that. And let me think about how I could enable that. I feel that is a level of coordination that. you know, after 10 years of running Airbnb, maybe he feels is lacking. I have no beef with his thinking here, right? I'm a fan of systems thinking I try to implement some of this. Well, before this episode, right? And there was no vehicle at work where product managers are within their siloed environments. So just as a facilitator, I created a meeting on the calendar once a week, half hour initially the product posse product people get together and talk about how I can enable you or how someone blocking you, right? It has taken off. So that's, I mean, they, they seem to get value out of it. Which is really good because otherwise there's really no way of knowing what some other product managers working on for what time frame, right? So that, that I think what Chesky was getting at is, it's true. Unfortunately, though, how many product managers do you know that lift their head up above their screens and say, let me look laterally? Because they're incented to look only down at their screens. Correct. Yes. They need to be incented. To help each other out or if you're in some kind of like group Functionality where you have a group product manager, whatever They need to be incented to help their product managers reach out to other product managers They maybe this is leading to the to Brian's gripes about okay ours like the okay our needs to be Needs to incent your product management department to talk to each other, to just talk to each other. First of all, let's start with that. Just talk to each other, go to each other's plannings and be a fly on the wall. Just listen to what's happening and understand what's happening in the whole system. So that you can figure out where to plug in. Like maybe you don't need to, maybe you don't need to build that whole component. Maybe another team built it for you. Maybe you don't need to redo a whole new piece of functionality. Maybe you can reuse something or maybe extend slightly. Something in another team, we're going to learn something from somebody else. We could just buy that functionality, right? So, yeah, I agree. I mean, in systems thinking the values at the interfaces, right. And that's what they're not doing. Yeah. You you just lit a fire in my mind about build versus buy like the, the, the, the decision of build a feature. Versus buy a feature in this case, it could be build a feature versus extend something. And then the team did slightly for my data or my app or my whatever. Yeah. So leverage something that exists. Yeah. Yeah. Like looking to reuse pieces of development rather than like, Oh, I've got a whole development team. I'm going to spend a quarter and build something. Like, you know what I mean? Like rather than doing that. The reason that you might not look at it like that or might not do that is number one You might not be aware which is what we're talking about or number two You might not be incented on like well if I just extend this other part of the organization If I just extend their feature that they built like it's gonna go on their numbers So it won't really look to me like I built my own I mean like you didn't build it you just You just added another checkbox or added another thing to it or added a metric that you can measure and expose it on your side of the app, but that other team built it. So that other team is going to get the credit. So in this, in this case, you might shy away from doing something like that. Whereas if you're all talking together, and you have the customer in, in mind at the end, you might say, well, it's faster to get this as a customer to rush it out the door. And get the feedback. Yeah, there's a million ways to go with the, with that, with that podcast. The last thing I want to highlight today is. Agile podcast number two, this is before the name change, Agile podcast number two was, was titled, New Product Owners, Not Getting Fired, and Meet Them Where They Are. That was, that was our, it was a, it was a potpourri of different. Potpourri. That's right. That's right. I love the French. This was way, way early. It was where we was basically not anything. I don't think that's right. This is like two hour podcast. That's right. And, and out of those two hours, I think I, I feel like it was, it's not true. This is not true. Statistically, metrically, philosophically, spiritually at all. But I feel like out of these two hours out of these hour and a half, whatever, two hours, I feel like I hated on Spotify for an hour of this podcast. It's not true. It was actually like 12 minutes or something like that. this is the podcast where we touched on Spotify's framework. And also, also we touched on a little article that here we are several years later, the article was, called rebranding the Scrum Master role in tech orgs. It was posted on Capital One's website, but it was since removed from Capital One's website for mysterious circumstances. I feel like I'm cutting a promo right now. I gotta whisper that part. Mysterious circumstances. the article that we reference in this podcast doesn't exist anymore because Capital One has since fired all these people, including one of the authors. I don't know if they fired one of the authors. I think he just randomly moved on. Mysteriously. So it's pretty easy to, I don't know how deep I want to go here. No, not deep at all. It's pretty easy to go find the original article and look at the two authors and look up their LinkedIn profiles. Sure. One of them has, one of them left Capital One really not too long after writing this article. The other one stayed with Capital One their whole career and, and made a pretty good path for himself. I'm not, I'm, I'm gonna pivot now because I'm not trying to make a, I'm not trying to make a statement about either of their careers. But I, I will make a statement about this article. Everything we read in this article on that podcast about stamping out their own need for the scrum master to not just do scrum mastery and team coordination and team development. They should do more technical things and in the article it says another side effect of moving to a more quote, technical agile role focused on delivery is that it gives the team a second set of eyes, on design, and you can get into to figuring out different methodologies that work best to the team, like Ban or XP or Agile. And also he ends the article saying you have to roll up your sleeves and quote, Getting their hands dirty. The implication here is that scrum masters are like, A management class that really don't, they're really not involved in the work and we, we really need them to be more technical and they need to have quote, sharper, technical chops. All these are quotes out of the real article. Like again, are these actual Scrum Master? Arguably. Arguably. However. However, we called this two years ago, right? Nothing in here about value, nothing in here about customers, nothing in here about helping product prove value to the business. Those are all red flags. Like if you were to read this job description and see nothing about value to the business or the customer or the value stream that it's producing. I'd be real worried about taking this job because you could be seen as overhead, which might've happened. History has proven. Yeah, actually happened here. It must've been so embarrassing for them to pull this blog down off their official site. Yeah. It, it behooves us to say they actually in that. Early blog that we just deferred to, they rebranded Scrum Masters to ADLs, Agile Delivery Leads, right? But yeah, this whole article is Miraculously vanished along with a thousand agilists all ADLs, gone. In one fell swoop. You know, the funny thing about this is, the scaled agile framework they still have it as a success case. Capital one benefits of safe for financial services article on their website as a kind of like a banner level. Yeah. Success case study. Yeah. Yeah. So I don't think they got the memo or maybe they did get the memo, but they just moved too slowly to pull it down as well. So there we have it. Well, I don't get victory laps often. But that's about the amount that we allow ourselves to indulge. I'll have to say anyone with a negative critique. Of the last five minutes of the podcast. I agree with you. It was a negative critique. However keep their resume updated because if you, if you get stuck in a spot like this, like you, you gotta watch out for yourself in your career. Okay. If your company is saying like, Hey, like these industry standards I don't know about this. Like we, we could, we could squeeze employees in this other job role and get, get 20 percent more productivity out of them for the same salary that we pay them. so what we're gonna do from these podcasts is, we're gonna take the comments from this podcast back, and we're gonna see acceptance criteria I think deserves another podcast all its own. And a few of these other ones I don't Budgeting does too. Budgeting certainly does. I, I think we're gonna take this list that we came up with, and we're going to refine it for what the most valuable topics are and we'll do follow up podcasts or new podcasts on the subjects. I think that's the takeaway here. And it won't be a repeat, of course, right? This is going to be a different take on the same subject. Right. Yeah. So for unique takes, you know where to come Some of them need the vitriol taken out of them like the Capital One one it needs a vitriol taken out of it to be beneficial. I mean, unless I guess, unless you were involved in the Capital One layoffs, and then, I guess, you're all about vitriol. Yeah. Right. So we'll think about that and you think about whatever topics. You, the listener and or viewer want us to, to cover their on arguing as well. Dot com. There's a form on the website and also agilepodcastquestions at Gmail that still exists. Oh, nice. Well don't forget to subscribe and smash that like button.