AA119 - Software Development Methodologies

All right. Welcome back to Arguing Agile I'm your host, Brian Orlando. That's your host Om Patel covers the enterprise and all things people, and I cover all things product. Hit my music. Oh, wait, there's no, there's still this, the music. Anyway today on the podcast, we're fielding a question from Mitch. Here we go. Mitch, these are your questions. So Mitch asks has there ever been a time when management forced you to use a methodology and Mitch listed some, some methodologies, some current methodologies. Some, some older methodologies. Well, they're, they're older codes, but they check out, I was about to clearer them, Lord Vader. Sorry, well, we went too deep. so I figured in in no particular order, we would walk through software methodologies and kind of talk about like what happens when management dictates you should use this methodology. That doesn't happen, right? When management forces you to use a methodology. Th this could be you're walking into a new job and mm-hmm. You walk into a, a practice where something is already prevalent and now you're forced to go along with it, whether you agree or not. It could be that could be it could also be that you are using some methodology and management comes in and says, stop, you should use this now, or You must use this now. Yeah. That, those are ways that you could be forced, I guess, right? Yeah so again, in no particular order, but maybe just in the order of prevalence out in the industry. So I think from what I've seen in the industry what, what's colloquially now referred to as the Waterfall Development Methodology mm-hmm. Is the most prevalent. Sure. Whether it's actually referred to as waterfall or not. Right the practices definitely are those that align to sequential way of developing things. Right, right and typically entail those, those things that people have already grown to I was gonna say grown to love, but maybe not so much love they're, they're accustomed to it, right? Yeah. Do the discovery phase find out what the requirements are, get them signed off in blood do some design, and then once the design's ready start development. And once developments ready, start the testing. And once testing is done, then you actually deploy something somewhere that someone can use. in a, in a, in a nutshell, that's kind of what we mean by, you know when we say waterfall, right? Yeah. Yeah. Winston Royce was credited with coming up with the original kinda model from which waterfall was derived. Although if you dig deeper, you'll find that was a mistake really. That, that was, that was his original model which he spent a good portion of his life saying, Hey, you shouldn't do this. And then industry of course saying like, Hey, go away. Like, who, who are you? Yeah. In a nutshell, really there's, there's nothing wrong with that sequence of events. However, it's the timing of all that. So if something is taking many, many months from discovery to delivery that's when you may have issues because the customer's needs have changed. Their business landscape has changed. Yeah they have competitors that are doing something different and they need you to pivot as well. Yeah. That wasn't always the case way back when when this model first came out, you had long lead times. Yeah those things were easy to budget for because you knew how many people were working for how long. Right. And you knew, you knew their run rate. You could easily work out the budget of the project. Timeline estimation was pretty straightforward because you project out these dates and say that's it. Yeah. Whether there's any basis for that. Um in terms of the person who is, is projecting those dates, have they done this sort of thing before or not is it analogous? Like, have, have they seen a project like that similar to it? Um, those things play in, into it. So there were some positives to that approach way back. Right there were some cons as well and obvious con would be that that approach is inflexible to change. Right. The other obvious con is the sequential nature of the project prolongs the completion of the project because you have to now move from one phase to the next. You had, you had phase gates at which the customer was asked to sign off on that previous phase as having been delivered. So there were some things that were not so not so good let's see, what else? For projects that have well-defined requirements and not a lot of scope for changes are ideal in this sort of a methodology. I'm reading Wikipedia for for Winston Royce, and apparently out of this paper that waterfall was kind of coined later in 1976, he says the, there was a later paper by Bell and Thayer in 1976 that they, that they used the word waterfall to, to refer to what Royce was talking about. And apparently Royce was talking about all of these sequential steps for very, very, very large projects. But he says, for smaller projects, these two steps were sufficient. For smaller projects, just analysis directly to coding were sufficient steps in the quote methodology again, that he never coined his waterfall. Maybe we'll go do a podcast episode of specifically about his original paper, cuz I like, I just pulled the bell and Thayer paper: that's software requirements. Are they really a problem? Bell and Thayer from 1976. It's, it's only eight pages. I'm pretty sure we could read all the eight pages and summarize the whole paper. Right now we're not going to, I, I think we probably could do the same thing with the, with the Royce paper on a separate podcast. But, but anyway, like the point of getting into this is to point out Waterfall, point out that it's often, like the paper that originally was detailed in is misquoted. All up and down to the point where other papers were written about it and, and, and it probably was both a great one for us to start with and also not a great one for us to start with because Waterfall, like by the time you realize that your management is pushing you into using Waterfall, you may not even realize that you are now using Waterfall. Because from the Royce steps of doing all the requirements and then doing all the analysis, and then doing all the design, and then then moving into coding and moving into testing. I can think about drawing a circle around each one of these boxes. And making that a different team that does that, like the bas do all the requirements stuff and all the analysis steps. And then the architect does the design step, and then my development teams do the coding steps, and then my testing team does the testing step. And then my implementation team, my platform team does the rollout to operations step. Like I, I, I may be the most agile company in the world, but I've just implemented Waterfall just by organizational design. So the, the tricky part of this and the interesting part of this, someone who maybe doesn't work in the industry, right, who's like looking at it from outside trying to understand what the difference between these methodologies is is that waterfall can kind of creep into any of these methodologies by poor organizational design choices. That's absolutely true. So organizational structure really does drive the way people work, right? Right so I think this is, that's a good illustration you could be, like you said, the most agile company, but if you organized that way in your example, if you had different teams doing that, you're doing waterfall. Not only that, you have no idea what the other team has done, right. Cuz they're handing off stuff to you. Right. So you have all that all the disadvantages of not having the deep rooted knowledge from, from other teams in your team. Mm-hmm. Plus, plus the disadvantages of giving something to you just without context even. Right, right. Or inappropriate context. So the original intent gets diluted every step of the way till it gets to delivery, which is the last step the scary part of this to me is like the, there's a S V P G article about that, that names this as well. And there's a popular term, the Silicon Valley term, they call it dual track Agile. What they really mean is you have a discovery and you have delivery. You have discovery and delivery, right? And like discovery has some things, some, some things that happen during discovery and delivery has some things that happen, but delivery always happens after discovery. Okay. I see a lot of vendor tools have their own diagram for dual track Agile. They call it like, well, you wanna do, make sure you're doing your discovery so that you don't implement things in the most expensive way. And they speak all the right words. Yeah. But when I look at their diagrams when they're trying to explain this, I look at it and I, and I see their diagrams. I've never seen a dual track agile diagram with the discovery phase and the delivery phase written in a way that, that doesn't scare me, because it looks scaly like Royce's analysis to coding step. And I'm worried that the, like people trying to sell their tool are gonna make well, you'll have the discovery team over here and the software delivery team over here, and the discovery team is responsible for making sure that the development team knows what to build and that we it's, it's, it's usable and feasible and blah, blah, blah, blah, blah. You know, and it's some other person's responsibility. No, that's the development team's responsibility. Like that, that's, that's what scares me about Waterfall is like, it creeps in this whole let's pull everything apart. And give it to different people who don't talk to each other and don't know what the end goal is. Like. Let's take the system, the, the Deming system approach and let's draw a, a circle around every single little step in the system that's supposed to work together. Supposed see one team executing all these little steps together along the way. And let's draw a little line over in, in, in, in terms of like, let's try to optimize for some kind of financial reason or managerial reason or something. And let's try to, to, to, to, to game the system. You know, try to save some money or whatever by drawing a little line and, and saying, oh, well you're the only people that can go do this, and you're the only people that can go do this. And that's just not the way that it's supposed to work. So when I, when e even, even like even people that are experts in Agile, like this whole dual track agile thing that I was reading, like they do this all the time and I could see any, any lay person, anyone who's not an expert, Would see a, a diagram like that and be like, oh, easy. I'll just form a discovery team and they'll be the one that does all the discovery and con congratulations your waterfall. That's right. It's a two step waterfall, that dual track system in my view. Right? Yeah. So, so it's still waterfall, it's two steps, and it's, that's not in and of itself a bad thing. What is a bad thing is to your point, different teams are doing this. Yeah. Right. So you've again got the same one person tyranny, one person or one person or one person's tyranny. Yeah. So you've got the tyranny of, of, of, of distance from one another. Right. Which, which is a huge problem. So we spent a good amount of time on Waterfall Has there ever been a time when management mandated you know, forced working like this on you? But I mean, management is the if you go with Deming not to, not to shortcut our, our Future Deming podcast, but Deming's number was management has control of 94% of the process and only 6% is up to the workers. So if management basically says, Hey, I, I love this great system you have about taking customer's feedback and, and, and coding it back into the programs and, and making the software much more effective for the customer and making the customer happy. But also if you can draw boxes around like, well, all your testing happens over here, and all your, whatever happens over here, you can very quickly destroy an organization with, with a tiny little administrative pencil whipping change has there ever been a time when some, when management has done something like this, kind of forced something like this down and what, what was the, what was the effect of that? Well, I think, I'm sure, right? I'm sure there, there have been plenty of times when this happens. And it's because again, look at what they know. They the management, they know what they know. It's not the newer systems. Right? Yeah. So they say, well there's comfort in this do it this way because I, I've been in projects like that before as a manager. Mm-hmm. And all of these events, et cetera, they, the vernacular, everything's familiar to me. Right. Uh I know what, what, what project management is. So that's what we're gonna use. Mm-hmm so that, that happens all the time. I wanna talk about the hidden mandates as well. Yeah that's, that's what I was gonna say. I was like, may, maybe you should like pick, like pick a, pick a mandate that, like was, was handed down. That wasn't specifically like, Hey, use Waterfall. But it was like that, that the spirit of what they a, were asking. Was actually implementing Waterfall over maybe a more agile process or whatever. Yeah. I mean, lo most times that happens for companies that are looking to become more agile. Mm-hmm and again, it's the comfort factor, right? They don't know how to work in Agile. So they say, we're gonna be agile. Yeah. We're gonna work in an agile way, right? And they'll pick somebody, Mary Fred, right? You're gonna go ahead and create a project plan first, right? And you'll do this by yourself, Gord, cuz you're a project manager but we're agile, right? So what we'll do is we'll get together every morning for 15 minutes and we'll just talk about stuff, and that's our daily standup. But we're really not. So that, that happens all the time. People use agile terminology to execute in a waterfall. Way. Yeah. Right. That is the most common thing that I've seen. Mm-hmm in companies that are looking to, looking to transform themselves. Mm-hmm. They start there. What's, what's like, is there an example of like one practice that people mainly go to to push? That's an, that's basically I was gonna say anti agile, but what I really mean is like they're, they're pushing waterfall when they don't really realize it. Like, is there one specific thing that you've seen at companies? I think the, the most obvious one is to create a timeline and then tell you to execute to it. Right so I mean, that happens, that happens way too frequently out there somebody picks a date, Somebody usually fairly high up in the organization says, we want this, we want this by this date. Mm-hmm. Now, what I'm not saying here, to be clear is you cannot use the date as a driver. You can still do that because maybe you have regulatory requirements to meet by a certain date, or there's a conference happening at a certain time of the year, and you have to have something ready to show there. That's fine. Those can be, those can be used as drivers Yeah. For the direction you move in, but not the execution. Right in other words, you don't put those milestones in place and say make this happen by then, but we, we don't even know what this is right yet. Right, right. Well, if we don't know what this is, then they shrink back into, well, let's go, go find out all the requirements. Yeah. Yeah. So now we've squarely found ourselves in waterfall. Go find out all the requirements, and then when you've got those, guess what, give 'em to the architects or whomever to do the design work. Now you're squarely in the waterfall lane. Yeah. To me, where Waterfall gets its foothold in an Agile organization is, is this exact step that you're talking about is usually it's, it's, we aren't sure what the customer wants, or it wasn't clear or, so something happened where we, we realized it wasn't clear what the customer wanted. And responding quickly, more quickly is never kind of considered, like spending more time figuring out what the customer wants or locking 'em into a contract or whatever is kind of the way the organization goes because they're looking for safety, right? They're looking for safety and predictability and, and they go the road of separating the coding from the testing, from the implementation of production. And, and I would also add when I was on development teams the testing and the coding being pulled apart was usually much more difficult than the implementation of the code that was ready to roll out into production. And then, like sometimes production, you have a, a different set of tests, like a business acceptance kind of deal that happens when stuff rolls into production. Yeah, usually it's harder to separate the, the internal testers and coders than it is to separate the go to prod activities, like the platform activities, like I, I, I see those. Usually if, if I come into a company and I see the teams that are producing code are not also shipping it to production and then working with production users. And somehow there's a toss it over the wall to another team that rolls it out in a prod and does some kind of u a T activities or something like that. Then I, I, I have an indication that now there's some kind of problem and I might be waterfall. That, that's, that's usually the first thing I look for is like is it, are the teams building it, owning it all the way through the cycle? Um, because if not, then I think there's some circles around these boxes and, that would be a quick indicator to me, like a quick, like how, which way is the wind blowing? Oh, it's blowing in the direction of waterfall to let me know, you know? And then, and then you can, once that kind of takes hold, you can look back and be like, oh, well now we have people whose job is to talk with the customers and get the, all the requirements and then bring them to the development teams. And it's not encouraged for the development teams to talk to the like, Ooh, I don't wanna let my. Developers talk to customers. Oh, they're not good at talking to cus they're not quite polished. I'm gonna have my salespeople talk to customers and get all their requirements and and, and then it's just, it is just a steep, downhill roll from there to mediocrity. I agree. I, I, I think I just to go back to the point you made earlier about the structure of driving. The behavior of the organization. Right? Yeah. So, so there's a lot there. I mean, who are the developers report up through, right. Right. Those sorts of questions should be asked, but yeah. You have testers and they test Yeah. But there's nothing for them to test Right, right now, because we've just started development. So developers go code and then throw it over the wall at testers. Right. That, that's another smell that I look for as well. That's waterfall. I mean, you have a handoff right there. Yeah. It's also very demoralizing for, for the testers to just sit around and wait. It leads to basically this blame culture right. At the end when things don't get delivered you blame the testers. They didn't finish on time. Testers blame the developers. Yeah. Who didn't hand over in time. I mean, like you said, it's a steep downward spiral. Yeah. It's, and that, that was like to, to, to kind of put a bow on this category like that, that ever been a time where you're forced to use one of these methodologies where management kind of mandated one of these methodologies. Like, nobody, like again, my experience, nobody really mandates that use waterfall. Meaning, meaning all of the requirements of, although I was on a program one time where they did ask, they did continually ask, I want to know all the requirements for the entire project. Project for all the time basically. Yeah. So, so basically tell, tell me all the requirements for your product now and in the future. Which was like, when you say it like that, it's a ludicrous ask. Completely ludicrous. But, but that is what they asked. That is what they, that legitimately with a straight face, that is what they were asking. And and they were, they basically were, for every time that that manager asked for that, that ludicrous, uh demand it forced the program back to, well, I guess everybody has to participate in requirements analysis now and stop working on code because that, that was the only way that you could punch out a timeline that was 18 months in the future if we all stopped what we were doing for a couple months and just did requirements analysis and talk to customers about what they might, what they might want, not necessarily what they need or what they need immediately want or whatever. Right. And and, and yeah it was, that was always a constant fight on that program. You know, I've, I've lived that life in the past people spend hours and hours on creating polished PRDs and Sure. You know, they get signed off and versioned and all of that stuff. Right so it, these, these are little smells you can look for. I mean, is your organization looking or demanding a P R D from you? Which they then in turn, say, should be signed off by the customer, right? Mm-hmm. You're definitely not working in Azure way at that stage. Mm-hmm. Right? So what is it? You're gonna do all the requirements, sign 'em off, and then what, what's next? So immediately you're now into another step of the waterfall. Well, you're gonna, you're gonna do all the requirements, sign them off, and then ride off in the sunset. That's right. I think the summary of what we've said so far is Waterfall is not something that specifically gets implemented is something that sort of piecemeal gets pushed on you. It's, yeah. Yeah. That's, it gets defaulted basically, right? It's clandestine implementation. Clin clandestine is clandestinely a word?, clandestine ces Lee. Secretly, I don't know, secretly, emotionally, quietly steal. Definitely, definitely Stealthily. Yeah. Stealthily is definitely a award. But that's how it happens.. It happens in little concessions of like, management, oh, I need you to I know this, you're doing this now. Next later roadmap that goes out three, maybe six months. Nah I really need a 12 month plan. Yeah. Give a 12 month plan. Right. So that's go, that's covertly then as well. Covertly. Yeah. Yeah. Emotionally you're welcome, Clint. Like that one person enjoys my nonsense. We should move on to Scrum because probably a lot of people listen to this probably either are using or have used Scrum I'm super interested in jumping straight into, has there ever been a time when management forced you mandated scrum. I don't recall that in my experience, that they come in and say, you will use Scrum it may happen. I don't know. But what do you do in that situation, I guess is the author's question, right? I've been on the leadership side where leadership is going to the team saying, what are you using now? And then I'm sitting on the leadership side saying I don't know how these people forecast their work. I don't know what they do. Like they should use something. And if they're gonna use something, why not start with Scrum? I mean, you can change it later, , why not start with that? I think they were professing to use Kanban actually, and we'll get to this in a second with our Kanban discussion, but likes Scrum again, only my experience. Maybe your experience is different. Scrum is usually like the defacto, let's start trying to do something kind of framework. I think it also depends on the nature of your organization, right? If you're a software shop or lineage as well, right? I mean, if it's a reasonably new company, a startup, et cetera, you're more likely to use Scrum. Well, no. I mean my, my, every time I've ever seen Scrum, I actually have seen Scrum rolled out onto teams. Like the question asks, and every time I've seen Scrum rolled out, it's because the management or leadership, depending on the company, right? It is just says like, listen we need introspection points. We need, we need inspection and introspection points you to introspect your own work, us to inspect your work. We, and we need more transparency. We have to use Scrum. Go do it. And, and you know, whatever you set your cycle to like, let me know because I want to be there. I. You know, whatever, every two weeks, every week, every three weeks, whatever, you set your period of time. Like, I wanna be there for your demos to see what you've worked on. You have you, you can't go off in a corner and disappear for three months, and then I pay your salary for three months, and then I don't get anything after that. It's not a tenable business solution. So you're using Scrum I've, I, I have seen that before. So that, in that scenario, scrum is quote unquote mandated for the right reasons, I feel but I've also seen other reasons for example, the, the CIO goes to a conference and hears that that's what everybody's doing. So they come back and say, stop hands off keyboard. We're all gonna do Scrum now. Right? Yeah. Right. Starting right now. Right. I've seen that as well, and Oh, really? You know? Yeah. They don't regard whether their organization is, is geared up to, to use Scrum in an effective way. Nice. They simply say, Hey, my peers are talking about this thing called Scrum. We like it cuz everyone's doing it. We need to do it. Tell, tell me about that. Like, tell like where was that at? Like, oh yeah. Yeah. This was at a publishing company that they're not really the, the stalwarts of software development anyway but that's exactly what happened. The CIO went to a conference in Europe. Mm-hmm. And my client was in in, in Asia. CIO comes back, holds a meeting very next morning when he came back and he said, everybody stop the way you're working that that's not right. Oh boy, we need to be working in a scrum way as he put it scrum way. And you see some blank faces, you see some faces with glint in their eyes cuz they've worked in that way before and they were frustrated in the existing ways. Right. So going in into that kind of a meeting, You come out and go, okay, what just happened there? Right. This is good and bad combined, probably in different measures. Mm-hmm. And, and as a coach, you need to unravel all that mm-hmm. And figure out how you ready the organization to implement scrum. Right. It just doesn't happen at the click of a finger. Yes so I've seen that initially it was a rocky road for about four months or so, roughly. It was Rocky cuz you had to prepare the teams, the organization all the other functions within Right. Within the organization. But after that, they would never go back to the old ways. Right. So that was great the second year, so not the year he went to the conference, but the skipper year, second year, when he went back, he actually showcased his development area as having implemented s scrum effectively. So that that was a whole. You know, rainbow, right? You, you went from not doing anything agile mm-hmm. To working in an agile way quite effectively in two years. Mm-hmm. That's interesting because my first. Experience with Scrum? Was, I think an SPC like sold my leadership team on the Safe Agilist training. And then they try, I've told this story on the podcast before and and I remember the leadership team was offsite going through this training. When they all came back, they all had the little placard, the, the laminated placard. And they love walking people. Cuz they would go back to the, the placard and be like, no, it says you have to do all the PI planning during PI planning and you don't get to go back to requirements and blah, blah, blah. And um, they just dogma, absolutely augment. They, they, they only trained the leadership. They didn't train anybody. Person who actually is on any development team. That's a great way to indoctrinate religion. And then the, and then the leadership team came back and said here is the pi here, here are the PI objectives that we want you to achieve. Um, here is what you're gonna do in pi, in, in, in sprint. 1, 2, 3, 4, 5 at the pi. And they gave us the work items that we were gonna do. And and you know obviously it was, it was an absolute nightmare and train wreck. Like after the very first sprint, almost nothing got done and it all pushed to the second sprint and then that, that, that created a quote, waterfall effect of everything just moving. I think that what you've just described right there, I think it's pretty typical for any organization, especially adopting safe for the first time. Mm-hmm. Mm-hmm. But even even, even Scrum really you wanna hear cause they don't train people. You wanna hear the best part of that story? Go ahead. It was, it, the team was like 12 people, which included two mobile developers and a tester dedicated to mobile. So it there was absolutely no reason to be using safe for like 12 people or, or 14 people, whatever. What are you, what are you scaling it? There was, yeah, there was absolutely no reason at, in any way, shape or form. And, and the company didn't change their budgeting or their finances or anything like there was that was my story about has there been a time when something was, was implemented on you? You know what I mean? O over you, onto you on top of you, around you. So that is classic waterfall in five sprints Yeah. Was, or four sprints, whatever it was. Right. That's what it is. Because I, again, that's something that, that we see all the time, right? People say we're, we're, we're working in a SAFe way. Right? Well, are you right? And you look at that and you look for those smiles I mentioned earlier. Yeah. And one of the smiles is only leadership got trained. Right. Yay. Yeah. Right. People doing the work. so I actually, I told two, two stories. One, one where I was representing leadership forcing Scrum on the team. That's right. And the other one. But, but you were, but you had rationale for what you wanted. Right, right, right. Which is visibility, predictability, all the things that we know are possible through Agile. Mm-hmm. Right? Mm-hmm. So I think you were right to, to kinda look for answers to that. It's now the question is how did you go about it? Right cuz the devil's in the details. Yeah. Whereas leadership, just in my example, for, for instance right, the CIO going to a conference and his peers saying, we're all doing Agile, we're we're doing Scrum. And he would come back and the very next day, the town hall meeting, this is in person, so everyone's in the room, this big old conference room, and he said, stop, whatever you're doing. Mm-hmm. We're gonna work in Scrum starting tomorrow. Mm-hmm. Right. I mean, that is radical and people just left that, that meeting all worried like, what, what does this mean? Yeah. Do I have a job? I mean, the the, the disruptive, the details, like the disruptive side of that is I've been in quite a few companies where they've had questionable scrum practices, scrum, fall, questionable, questionable. And, and they brought me in as a product manager, right? Like, I'm, I'm playing, I'm playing the role, playing the role, playing the role, playing the role o of the product owner on their team as the product manager. You know, you sometimes the first product manager and the first, like real stress I have to encounter at the company is they don't have a backlog. So all these developers are looking to me to be like, what do we work on next? What, what, what's the I'm, oh, well wait, I'm supposed to only work on the highest priority, not whatever I think is important, or whatever. Okay, Mr. Product Manager. Tell me what to work on. If you, if you're the one telling me that I only work on the highest priority and then the stress is on about now I have to fill out a backlog. Yeah. Right. You have to have that runway. Yeah. Yeah, yeah. So that, so that's like, that's the when this gets, if I'm gonna take a product approach to looking at this question, although that's arguably the way the question was asked if I'm gonna take a product approach of looking at this question, I'm gonna look at it from the perspective of product management is, well now I have to make sure I have x number of sprints worth of work specked out in the future. You know, that we're ahead. So we have a forecast and all the stuff that product needs because I, cuz I like when I roll out Scrum with, with the team that I was talking about. It was because they had no forecast. There was no way to tell what, when the team was gonna be done with stuff and when they, when they were gonna start on something, even in a window. Like, just like, Hey, are you gonna get to my thing in the next three months? Three, three weeks? Yeah, yeah, yeah. Four weeks. But, but in your case, at least, you had, your organization had somebody in product mm-hmm. To deal with that. Mm-hmm. I'm talking about companies that come in and say, we're gonna work in a scrum way, and we don't have a product owner, we don't have any product person. Right. The highest paid person in the room dictates what the team's gonna work on. Oh, that's true. Yeah. That, that's the hippo effect. Right. That's, that's true so I mean, what are your chances of success there? Forget about the customer. The customers. Nowhere in this picture. Right. That's the problem. I'm gonna take a slightly different approach now as we go from this blend of like waterfall to, to scrum or mm-hmm. Whatever, whatever else, right? Mm-hmm. So my experience is companies that have been historically working on waterfall away mm-hmm. Looking to become more agile. They don't go and do a state transition like that, right? It's a gradual move and it goes through various things. They do waterfall still a few months out. Sure. They do some of the things they do day in, day out incorporate elements of Scrum, right? So they're doing things like the team gets together every now and then to talk about how they can work better, aka the retrospective, right? They have customers looking at stuff every month or so, let's say, right? Which is the, the AKA sprint review or whatever you wanna call it, demo, right? So it's, it's a gradual tale that kind of tapers off and then another rises as they get into Scrum, right? And again, there's nothing wrong with that. as an agile coach is that super frustrating or is that just part of the process of like, Hey, we're waterfall, what we do daily standups, and you know like that would, that would, as a product manager, it would really frustrate me to say it frustrated the heck out of me too in my early days. Right. It was really stressful it felt, I felt like Sisyphus pushing that rock up a hill, right. With people pushing it back down on me not, not Kate Bush running up that hill. No, no. Not running up the hill. Yeah. No, the thing that I, I have accepted now is there's a certain inertia built in. Mm-hmm. Right. And you can look to minimize it, but you can never eliminate that. So what you need to now look at is what I do day in there is look at where I can make the biggest difference today. Right. And then come back and a couple of weeks, which is one sprint. Mm-hmm. And see. Do I need to continue that? Do I need to pick up something else? Yeah. Or do both. Yeah. Right. And just rinse and repeat like that. That's the iterative approach. Yeah. So I still get frustrated to your question. But now I'm trying to channel what I do mm-hmm in hopefully in more effective ways. Mm-hmm. Instead of just letting it frustrate me. Hmm. Well these people just don't get it. Well, okay. I know they don't get it. Yeah. That's why I'm here. Right, right, right. So yeah, it took, it took a while to get to that stage. I mean, that, that's a great piece of feedback. I, I like the, the other piece of quote, implementing Scrum is that the company has a bunch of questions, and the scaling frameworks are the only thing that answers those questions. You know, the company has questions about well, how do I apply budgeting? Or how do I apply like I have a bunch of teams that are working together, or I, I have one BA backlog, but multiple teams, or I, maybe I don't maybe I'm scared to go hire 10 product managers for my 10 teams. And there's scaling frameworks for that. And you know, that like, yeah, like that, that's, that's the scary part about, about talking about implementing Scrum is. There's so many different people who've customized Scrum and tried to it's, where do I even start, you know? Yeah. It's, it's, it's a question of who do you go and who's peddling what. Right. Who do you buy your stuff from? Right, exactly. Everyone's got something to offer. Right. But what's, what's gonna fit your needs best here? And now that, that's often the trick and lot of times people fall foul of the glitz, you know that that's sold to them. Right, right. That's how people end up scaling when they only have one or two teams. You don't need scaling at that level. Right? Yeah. Yeah. Yeah. And, and the other thing I like to say, this is something that stuck with me and it's not I don't take credit for the phrase, but I like this phrase, if you're not doing scrum well, what are you scaling up? So the, the saying, the one liner that I like is nail it before you scale it. Right. Get scrum down, understand it, practice it, improve it, get to the point where your team is effectively running Scrum, and then look to scale cuz bad practices scaled up just look like bad practices. Yep. Yeah. Scaled up. Right? Just more garbage. So, yeah. Unfortunately, again, I've seen a lot of organizations adopt some kind of scaling framework even though they're not really good at running Scrum. Speaking of garbage I wanted to talk about Kanban. It's not, it's not necessarily, but that's, I don't understand the transition. I, I'm sorry. Like, transitioning that way wasn't cool. I wanted to talk about Kanban because like in the, in the example I was talking about before where I transitioned that team to Scrum they were using Kanban, except it wasn't Kanban because they weren't tracking any metrics and they didn't have work in progress and they didn't have any method of replenishing the backlog. And they didn't have any, it was, it was Kanban with no rules. So it was basically, it was chaos. There basically was no process. That's what I'm saying. Yeah. And they were calling it Kanban, which is sad because the system is. So simple and elegant in its execution and effective, I might ask and effective. Yeah, I, yeah, I would agree with that. It's, it's so simple and elegant that if implemented, you basically need nothing further from this list. And, and if, if it, if it team is doing it, you can scale that up in the organization and up and up and up at different levels to where everyone, like it's just a higher level kanban board that takes into account all the lower level kanban boards and suddenly you find yourself not needing any other of these heavyweight methodologies because you just scaled your, your very simple way of working. So what would what would those people that are selling all those glitzy methodologies do is, and you know, that's not even talking about people that are selling these tools out there. Yeah I agree with you first of all that Kanban is a very simple, elegant method. It's so very effective. However, It requires discipline for teams to do it well. Sure. Right. I would argue it requires more discipline to to work in a kanban way than it does working in a Scrum way. I agree with that an example would be sizing your work, right? In Scrum everybody gets together and you do the planning poker or whatever it is, right? But in Kanban, there's really no need for that. Assuming the team is advanced enough to break everything down to be about the same size, right? Then they can say, well, well, how how big is this? Is it one, is it two? Is it three? Just pick a number. Everything's about the same. It can be one or two up or down. Who cares, right? Yeah. Yeah. So you don't spend time on that. Again, adding to the efficiency and everyone's understanding, but I don't see that. You know, out there all that often. Yeah. People are just struggling with it. Which is funny to me because in all the places that I've been, where I've been the first product manager in the organization, usually when you're the first product manager, you, you're basically separating the role from a leadership team member. Mm-hmm. So like usually a founder or somebody like that. Yeah. And when you do that a, a great way to give them confidence is to come up with a leadership kanban board that has a swim lane for every member of the leadership team and talking about what, what initiatives they're kind of shepherding, kind of moving along that basically they, they, they stop moving. If the leadership team member stops moving them along, cuz they, they, they are like those single threaded leaders, like I talk about on the podcast that we've had where we talked about Amazon's working backwards and stuff like that with the Yeah, the organization, where the organization starts, specific initiatives and then or actually no, in a smaller company, it's the executives that start, that start the initiatives. Mm-hmm. So basically creating a swim lane where it say, Hey, these are all the initiatives that you started Mr. Executive, and here's the columns that they appear in.. If you do work in progress, you can see like, well, I've got executive you know, om the executive has started three things and he's got one thing in the, figuring it out column and one thing in the actively doing column, or maybe one thing in the budgeting column where he is trying to like, get money or find money for it or find market signal or whatever. Right. And one thing in the actively doing column, and then Brian has 10 things in the budgeting column. I'm like, Brian, you got a lot of things in the air man. are you really working on all these at the same time? Yeah. Because it just looks like you're actively looking busy and you're not really doing anything. Start starting and not finishing good. That's what what it looks like. Yeah. Yeah. But, but that, that was, that was one of the first things that I would do to separate the role of product is like, how, how many things do we have in the air? How many, especially when you're at the, again, here, here we go. This is downshifting to the product part of this podcast. Especially if you're in product and you're attempting to try different market strategies actively in the market. I just mentioned that today to someone like, Hey, I, I who was telling me, oh, I heard this competitor in our same market talking about this new thing. And I pointed out, I was like, that's them testing that signal in the market, and they're seeing how many people get back to them with that message to, to, to, to write it down and to keep score of like, oh, when we, when when salesperson A tested this method for a certain amount of time, it got back to us this many times. And when Salesperson B tested, This marketing statement, basically we can do whatever, you know right. It got back to us. This may, they're, they're testing messages in the market to figure out where they should sell to. That's just, that's exact same as testing product ideas yeah. You know, will, will our customers use this? Will they buy it? It's the same thing. I was like, you, you just don't realize it because it's, it's, it's coming from a different piece of the business, but an organization that truly is aligned with Hey, we're gonna try this thing. Well, it I was talking about the swim lanes being executives, what if those swim lanes were like marketing or marketing as sales or product. What if those were large divisions of the organization? And each, each of them could take a piece of the initiatives from the executives and try them in the field to help the executive understand if they're getting signal. Well, that would be great. And like everyone listening's like, wow, that's kind of cool. Brian is like, the whole system's working together. It'd be successful. Yeah, it is. We'll get to that in a second. But also like if, if it, if om the executive is asking people to try two different things and Brian's asking people to try 25 different things, like we need, we need to line up at some point to be like, look man you're a little overwhelming, you know? Yeah, you're absolutely right about the use of the Kanban way for executives. That's Kanban. Yeah. We, we use this all time in transformation efforts. Right. You, you create create a leadership Kanban board. Sure. Yeah. Yeah. And not only is it per domain or per executive, you can actually, the added benefit to that is you can map who's waiting on something from whom. Yeah. Right? Right. So you can clearly see that every time you meet them. Right. You can say, well, this hasn't moved. Oh, that's because Mary hasn't got back to me, or Fred hasn't got back to me. Right. Mary and Fred are around the table. Right. When's this gonna happen? So we can start actually moving things along. Right? Yeah and then the second point I wanna make is, directly or indirectly, you can certainly see all of those things stacked up in a given column. That's, that's your bottlenecking right there. Yeah. So you can identify those and smooth those out so you have a predictable flow. Right. Right, right. Those are essential elements of Kanban. If a development team is using that, It can work the same way, provided you are limiting work in process. Mm-hmm. Right? Mm-hmm. You are keeping that backlog replenished on some cadence. Sure. Or, or sporadically. It doesn't really matter as long as there's enough for people to pull from, right? Mm-hmm and then looking at and eliminating wherever you see behaviors that basically show you people keep starting and not finishing. Yeah. Right. It's, it's elegant in its simplicity. So like, I like kanban. I don't think I have a specific example where I've been forced, you know what I mean? Where management has come down and said, use Kanban usually it's me conflicting with a development department that's claiming to use Kanban. Except when you dig into it a little more, they're not using throughput metrics. They don't have work in progress. If it ends up being pure chaos, when you dig into it, And that has been kind of the root of my problem. I've very rarely seen Kanban used at a team level besides the example I talked about to, to truly like to truly effective results. It's like, I, I, I hate that I have to say that because like, I, I really think that Kanban is a great way of working and can solve a lot of problems. And also, and also at a leadership level, I think that's the only way that they work is Kanban. Even if they don't, even if they don't know that they're working that way, that is the way they work. Yeah. My, my experience is similar I've not seen an organization dictate Kanban as a way of working on the team and, and also at the same time in an agile transformation, I would use Kanban as an effective way to have executive engage in what they're trying to do. So then it's up to them to see what there is to be seen because it makes everything visible, the good, bad, and the ugly. Right? And then it's up to them to take the steps. But all I'm doing is really holding up a mirror right at that point saying, this is what you've got. Now what are you gonna do about it? Yeah. Right. Well, that's depressing we kind of dipped into lean while talking about Kanban I don't think of lean as a software development methodology. So Wikipedia says Lean Software development. It says lean Software Development's, a translation of lean manufacturing principles and practices adapted from Toyota Production System. So it's not a methodology per se. It's not a methodology, but there are, there are principles, just like in Agile, there are principles. The principles are eliminating waste, amplifying learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity, and optimize the whole aka systems thinking. Mm-hmm. And then there's a whole bunch of items in regards to eliminating waste. You can look on Wikipedia for all this and that. And also there's, there's the famous book well go Goldratt. Uh, the Goal by Goldratt was the original. That's the original lean book - Eliyahu Goldratt. Yeah. From, from the eighties. But that, that's not the one I'm talking about. What I'm talking about is eric Reis The Lean Startup. The Lean Startup by Air. Oh, yeah, yeah, yeah. I have that, that's the, I'm talking about. Yeah, that's what I'm talking about that's the one that people go back to when they're talking about software development. The Lean Startup. Yeah. Yeah. So lean really, I mean, it's, it's the, it's the adoption of those principles, just like agile. Yes. Exactly. Yeah. That, that's right. But lean's principles though originate in manufacturing, right? Manufacturing, yeah Toyota basically was the the thought bed where, where it was all kind of dreamt up, if you like. And coming back to the essence of that question I mean like at, at a time where like a company would come down or a, a founder would come down and say, maybe we've been running with all these different methodologies and now we're just gonna be pure lean. I've never, never experienced that in my life. Yeah. I think the closest thing I've seen to this is people saying, Yeah, we're gonna, we're gonna use some Lean six Sigma metrics. Yeah. Right, right. And that's where the word lean is kind of globbed together and in what they were doing, but it was never lean management. Yeah. Well as you know, as the principles would have you implement Lean All right, so that's lean. there are other methodologies, right? I know that the the writer only asked us before, but there are others well, XP is one. Yes, xp. XP is actually it predates scrum even. And it sure does. It's a fantastic methodology. However, I've never seen a company come in and say, that shall work in XP way. Actually I've seen actually the opposite is usually companies will say oh my goodness, you got two developers sitting at one screen, right? What, what? Oh, you're operating at 50% capacity. That's ridiculous. Why would you? Yeah, utilization is hard for what we need it to be. Which is funny because I, I could, I could have swore that there was a statement about, I don't know if this was. Alistair or if this was somebody else who said, we never imagined when we were talking about either Scrum or Agile. I can't remember. We never imagined anyone doing Scrum and not doing XP at the same time. I, that was the, I think it was Scrum that, that was the statement. I, I wish I could attribute that statement to the proper person cuz I I do recall it. But xp so I mean, the idea extreme programming, the idea is you have two people sitting behind the keyboard and writing the same bit of code. Which, which I, I will tell you like I, I, I think of all the shops I've ever worked in and a, a good majority of them would think that that idea is absolutely bananas. Yeah again, management would definitely think of it as bananas. Yeah if you look at the team level and say, let's look back and see how the last few sprints went. Yeah would it have been better to have two people tackle a problem at a time? Right. You still get more through in the end, people don't realize that. They just think well, you're only gonna get five things done, whereas you would've got 10 done. That's not, it's not linear like that. Yeah. Yeah. But the benefit of having two pairs of eyes on the problem is you get so much more creativity. You also, you also can potentially knock out those bugs that may have formed. Right, right. If one person is just attacking the problem mm-hmm you eliminate the bugs from happening in the first place. Mm-hmm. Not every bug granted, but you know, quite a few. So that justifies having two people on there. Mm-hmm. The other kind of hidden benefit is knowledge. It helps you become more kind of, T-shaped as a team, I'm saying now, right? Yeah. So you have two people working on this. Lo and behold, one person's out for a day, right? Things don't grant you a halt at that point, cuz somebody else can pick up the ball and run with it? So all of that increases your throughput in the end. So those people that are naysayers to this, like they haven't considered all this. The funny thing is I've been in the career field for like n a non-trivial amount of time. I've not seen this as a structured approach in your, whatever methodology you're using. I've just not seen it. Yeah. I, my, my experience is similar, not a structured approach, but I have seen offshoots that do this. Like, I've seen one particular team, I remember they were working on stories that they just couldn't finish. Yeah. And a suggestion was to basically do this, right. Pay a program. Mm-hmm They didn't exactly do that, but they would do what is currently now called mob programming, right? Sure, sure. So three or four people would hover around there, break the problem down into little pieces and say, somebody will say, I'll, I can do this. Somebody will say, I can do this. And then they come back frequently, even multiple times during the day that's kind of a variation, I guess, of uh oppe programming as XP called it it was quite effective. But it was short-lived, unfortunately, because management came down and demanded those metrics. Why have five people working on this one story? Right? Yeah, yeah the alternative is one person work on it, not finish it. That's, that's the alternative. Oh, one other thing I just thought about one of the, one of the nice things with XP when it's done right, before releasing anything into production, you had the customer looking at at least the test results, maybe even get involved with testing. Um, and, and when they were happy, you put something out in production. Right. So you are increasing your chances of a successful release because you're getting the customer to see what they're getting upfront right. Before putting it out there so that was like, for me it was a very positive thing cuz these days you don't really see that very often. Yes. They're there at your demo where you say, ignore the man behind the curtain, look Right, this works. And then you put it in production and it falls about their ankles. Right. That's terrible. So that was a big positive and again, not seeing many companies mandate xp, so we're not seeing that benefit. Yeah. Sadly. So we kind of cook through the majority of quote methodologies, the major methodologies. And I have this I have a note about when you Google software development methodologies, Things that come up that I've either not been exposed to or I don't agree that they're full blown methodologies. They're like, I think that they're processes and there are four of them. There are T, D, D and B. D, D, test driven development, behavior driven development. Those are tools. there's f, D, D, that's a methodology. Is it feature driven development? Yeah, feature driven development is a methodology. Again, it's very rare. It is rare, but it's a, it's a legit methodology. Okay. What about what about rapid application development? I've heard of it, but I've never encountered a shop, ever running rapid application development. Rapid application development, I think predates I think it predates Scrum in 1991, book rapid application development resulted in

rad. Jim Martin came up with it. Requirements. Planning user, user design and construction, and then cut over cutover. Cutover phase. Cutover phase is that the, when you cut over to the new system, remember this is the eighties, they used to do cutovers, right? So you run parallel from a, the old system. In the new system. You'd compare the two outputs and then you'd go, yeah, it kind of sort of works. You do a conversion of the data and that's the cutover process. I don't know any company that said let's use rapid applications. They use prototyping as it was called. Right. And there's even the term rapid prototyping. Yeah. They used that, but they meant this. Yeah, yeah, yeah. It's the same thing. They used it. Sure and then when Rep came about, they used that considerably. Now no companies that worked in erupt manner. Mm-hmm. Quite a few companies. And that's because of the heft of the likes of I B M, who actually. Mandated it probably. No, they bought it, mandated it, they used it themselves, right? Mm-hmm. This is before, before when I worked at ibm, they were already using it when I got there. Uhhuh. So what we would do is we'd grow our clients and say, we have this great method. Yeah. This is what we, how we use this is the method we use to develop software for you. Huh? Right? Huh? And it's fantastic and that sold it. Mm. So IBM put their weight behind it so I guess we've transitioned from RAD to RUP. Well IBM's not using, are, are they using RUP anymore or they, have they transitioned to more agile kind of, I think they have transitioned to more agile ways now. Hmm. That's interesting. I don't know if there's any summaries or takeaways to be made from this podcast other than, Hey, like forcing th like forcing square pegs in the round holes always is a bad time. Well, the only takeaway I ha I have as a kind of summary for this podcast is if your organization is stipulating or mandating a given approach tread carefully and keep that resume updated. Keep that resume updated. Yeah, that's right. So on that thought, , thanks for staying with us subscribe and like, that's right. That's, and let us go On our website, what you'd like us to delve into next. Thanks. Thanks, Mitch. Hugs and kisses. He, he said that in his email, so I'm just reciprocating are you sure? I don't, I might have just added that to get you to say hugs and kisses. But tha thanks Mitch for your suggestion. Uh and, and for anyone else out there you've got the arguing agile.com you've got the form on the website. And also like hit us up on LinkedIn or, or Twitter or wherever. That's right. Where, wherever you can find us.