Pragmatic 90: Agile

Welcome to Pragmatic. Pragmatic is a discussion show contemplating the practical application of technology. By exploring the real-world trade-offs, we look at how great ideas are transformed into products and services that can change our lives. Nothing is as simple as it seems. This episode is brought to you by Clubhouse, the first project management platform for software development that brings everyone on every team together to build better products. Visit this URL clubhouse or one word dot IO slash TEN the word for more information. We'll talk more about them during the show. Pragmatic is part of the Engineered Network to support our shows including this one. Head over to our Patreon page and for other great shows visit engineered.network today. I'm your host John Chidjy and I'm joined today by Casey Liss. How you doing Casey? Hello. How are you sir? Very well. Very well. Thanks for coming on the show. It's been a little while since we've had a chat? Yeah, the last time was slightly antagonistic because I was explaining to you why metric units are silly, and at least I believe that was the last time. Yes, well, I just love the way you phrased that, and that was not exactly my recollection, but you know what, yes, listeners, if you'd like to go back in here. I poke fun because I laugh. No, just before you get a million emails, "Imperial units are dumb with the exception of Fahrenheit." defend Fahrenheit until my dying breath, but everything else that we do in America is silly. So we can just move on as quickly as possible. And on that point, by the way, because I actually agree with that and I have occasionally referred to temperature in Fahrenheit to my family and they look at me funny and I just smile. So never mind that. But today we're not talking about Fahrenheit. We're going to talk about, I would like to talk about something else, something that has more recently come into my professional life and something that I think that you've been enjoying/dealing with for probably longer than your career. That's very accurate, very well put. So yeah, and that's Agile software development. You ready for this? Yeah, yeah, let's do it. Okay, so I just want to start at just roughly a little bit of a history and timeline of Agile, not to go into too much depth, but during the 90s, I think a lot of people in in the software space in particular sort of said, well, we need to look at some way of doing development differently 'cause software is different, software is special. So we're gonna try some different things. And so in the '90s, there was this rapid sort of series of ideas every few years. And one of the first one that I could find that it was tangentially related to Agile was something called Rapid Application Development or RAD. Not one I personally came across, nor was the next one, the Unified Process in '94. I'm not sure, did you ever come across either of those? - I've heard of them, but I can't say I've ever practiced, or knowingly practiced either, but I've certainly heard of them, yeah. - Yeah, so this is the thing is that I sort of, I was aware of them, but it wasn't until Agile that some of their methodology sort of became, oh, okay, so that's what everyone now calls Agile. So the next one was Dynamic Systems Development Method, or DSDM. Apparently that was quite popular, apparently. I actually had never heard of it until I was doing the research. But this is the one everyone does know in 95 and that's Scrum. So, yeah, we're going to get to that. And then 96 was extreme programming. And that's where I started to write. Yes. Okay. I came across extreme programming and then 97 feature driven development, which when, when I said that was a programming methodology that came up in 97, I thought that's, isn't that the way it was always done? But no, apparently there was a specific. Anyway, whatever. So bottom line is all of these rolled up and certain elements of them in 2000 or 2001. So the story goes, apparently 17 developers and there was a list of names, I'm not gonna read them, but anyway, they went to somewhere in Utah, again, not too concerned where, but it was in Utah. And they came back with a manifesto for agile software development. And that's more or less where the whole term agile came from and a lot of things being attributed to agile over the last, over the 10 years since then, in that decade, led this group, they call themselves the Agile Alliance. And in 2011, they published the Guide to Agile Practices, just like a reference book of sorts. There's a link in the show notes if you're really keen and interested. I actually find, because, yeah, in my, as I'm trying to ramp up my understanding and knowledge of what the heck Agile is, I've actually found that site to be very, very helpful because people will fire off some term and I'll be like, what? And they're like, oh, that's agile. So I'm like, oh, okay, great. So I have a look in this, oh yeah, right. Okay, that's what that means, okay. So I'm kind of glad they did that. And to be honest, in my personal experience then, I'm an electrical engineer, I do control system software development, but the funny thing, I say funny, well, the thing is that in engineering in my space, it's taken a bit more time to sort of encroach upon our area of development. And it has in the last probably two to two and a half years. And that's just been the company that I've worked in has had some, shall we say, consultants of whatever, and they're from some of them have had extensive experience in Silicon Valley. And so several things came over with them when they came over to consult and Agile was one of them. to the point at which our entire organization is now embracing agile, which is in fact one of our, I don't know what you call them, tenants or whatever else. It's one of those mottos that they go on and talk about regularly, embrace agile. So, can you tell me a little bit about your history with agile at all, Casey? Yeah. So, most of my development career, pretty much everything I did up until my very last regular job was doing consulting. So it was either government contracting, which is kind of a corollary to consulting. It's consulting, but it isn't. Or just regular straight up consulting. And so what that means is a company, Acme Widgets Incorporated, comes to my company and says, "Hey, we have this software that we need written custom for us. Can you provide us a team to do it. And so I was doing project-based consulting where it was a team of myself and my coworkers would get embedded with a team of the clients and we would work as one unified team to create a bit of software. And typically that meant that there were either no developers on the client side or just one or two. And generally speaking, there would be a product owner, which we'll probably end up talking about later, on the client side that's kind of directing things and making decisions, but for the most part, it was just myself and my coworkers doing all the work. And that was most of my career. I definitely, especially in the government contracting, which was very early on in my career, we had something, we definitely worked more in a waterfall method. So the two kind of poster children for the two generally accepted ways of doing software development that are not that radical, one of which is waterfall, which basically my summary and I'll let you correct me John is let's figure out as much as we possibly can up front so writing the software when we finally get to that point it's almost paint by numbers you know it's as much as possible has already been figured out all of the all of the weird edge cases have been figured out all of the decisions have been made and by the time you're starting to write software if everything goes according to plan then there there are no questions left to be answered you just have to write the code is that kind of a fair summary? Yeah, I think so. And I definitely do think that it's those are the comparison with Agile that people most regularly make is Waterfall is what it's Agile versus Waterfall. And the funny thing I always thought about Waterfall is back when we were doing engineering development, we didn't actually call it Waterfall, we just called it like, you know, programming. So I don't think it's exactly quite as clear cut as a retronym or or something like that. - Sure. - But I do think that it was just something that, yes, that's what it was called, but no one talked about it like that. But since Agile came around, yeah. And I think your description of waterfall is pretty accurate. The way I describe it is you've got extensive requirements definitions, you do a detailed design, development or implementation comes next, then you do your verification and tests, and then you hand over and maintain. And that's kind of the waterfall methodology. Whereas Agile's not designed quite like that. It's more about- - No, not at all. - No, and I always, and so this is my turn to have a stab at Agile. So tell me how it goes. That requirements are essentially whittled down into very small deliverable components and documentations generally very light, then development and tests are part of each iteration and with each idea and each iteration is a single usable component. And then the result of that is used to inform the next iteration, whereby the requirements can change along the way based on each iteration can actually impact the final direction, rather than having a complete set of detailed requirements up front. - Yeah, yeah, I think that's exactly right. So the idea is in Waterfall, you're not actually writing any code until pretty much all the decisions have been made. And again, there's gray areas in everything we're saying, but the generally accepted version of Waterfall is let's figure out all our requirements, let's figure out how we're gonna test it, and then let's write the code, and then let's test it, and just like you said, then let's deliver it. Whereas with Agile, the idea is, hey, we may not even know exactly what we want. And the only way we're really gonna figure out what we want is to start using the thing, the widget. And so let's break off, just like you said, John, let's break off a small piece of this widget that we really need to get done and let's try it and let's see how it goes. And then based on how this small component of the widget is, then we can either continue down the same path we had before, or we can pretty violently swing, you know, left, right, up or down, and make different decisions now that we've actually had a chance to use that widget. So the idea is that you are constantly delivering something of value, and you're constantly changing your direction based on those deliverables. You could say, John, that you're acting in an agile manner, and hence the name. And so if you look at the manifesto for Agile software development that you had brought up earlier, I think there's a small portion that is worth reading verbatim. And this is from the original 12 or 15 or whatever authors. And it says, "Blah, blah, blah, blah, blah. Through this work, we have come to value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan." And then it continues, "That is, while there is value in the items on the right, which is processes and tools, comprehensive documentation, contract negotiation, following a plan, we value the items on the left more. individuals and interactions, working software, customer collaboration, and responding to change. So my understanding of the history of agile, and the spirit of agile was, in summary, let's put a team together, let them figure out their own team norms, you know, let's let them figure out how they want to work and just start working and then change if something isn't working. And that's basically it. Now, what's ended up happening, though, is because business and because big business, there has become a kind of accepted series of steps and rules and processes in order to do what is "agile." As you were saying earlier, John, I think what's kind of unfortunate about agile and waterfall actually is that they've kind of become these all-encompassing terms that are basically distilled to, "Do you figure it out in the beginning and then write code, or do you write code and figure it out as you go along?" kind of the big difference if you were to distill it as much as possible. And so I really like Agile and I've seen it work really, really, really well, but I've also seen it work really poorly. And unfortunately, in my experience, it is way more likely that you will have a poor implementation, for lack of a better word, of Agile than you will a successful one. And certainly whenever you're ready, we can start talking about what I see is the differences between the two and my recommendations for them. But I think that the crummy thing about Agile is that I really do believe in the spirit of what it's trying to accomplish. And I even believe in the kind of prescriptive way that most companies, at least here in the States, tend to do it. But all too often, it gets twisted up and mutated into something that will also often derisively be called scrummer fall. So scrum is a generally accepted component of Agile, which we'll get to in a minute. And then waterfalls exactly what we described. And so what ends up happening is you kind of end up with waterfall where you get together for a 15 minute meeting every day to talk about how things are going. But everything else is waterfall. And that's not really agile at all. And that's a trap that's easy to fall into. Oh, for sure. Absolutely. And it's one of those things that I've observed as well is that if you were to adhere more strictly to the whole intent of agile, then, I guess ultimately organizations, the whole thing that you said about how people get together and figure out how it works as they go, kind of thing is it's sort of a bit fraught with danger because sometimes you can sort of get off on totally different tangents, typically have different ideas about how it should work or shouldn't work. It's interesting and they have this idea of an agile coach and a lot of teams have an an agile coach to try and prevent some of that stuff, which is another interesting role, but nevermind, I'll talk about my experiences of that a little bit later on. But so I guess from my take then is the ultimate aim of Waterfall is to ensure that you have well-documented, detailed requirements up front, agreed and understood. And you accept the fact that detailed design is gonna take a significant amount of effort up front. But the ultimate aim is that if you design it right with the correct objectives from the very beginning, then you only need to do one implementation and that will avoid scope creep and it'll avoid rework. That's the theory, anyhow. Agile, on the other hand, aims to ensure that you just keep those requirements to a bare minimum set to make something that a customer could see or use that they can agree quickly. And then rather than document it to death, you just iterate a small step at a time until you've got a happy customer with that outcome. And you just keep doing that until you reach something where they're like, "Yep, we're done." That was another way I think of sort of like spinning it. But another way of thinking about it is predictive versus sort of adaptive whereby Agile is intended to be more like an adaptive sort of a technique with a much looser change control when you can adjust direction as it develops. Whereas predictive, which is more like the waterfall approach is more about you have strict change control. And if you wanna actually change scope and change your requirements and such, you have very strict rules around actually ensuring that doesn't happen unless it's costed, funded and so on to reduce the scope creep that would otherwise affect your deliverable deadline. In any case, whichever way you want to think about it between Agile and Waterfall, it always comes back to the customer because in the end, the customer or the owner, the fact is that the people do change their minds irrespective of what model you want to use. As we do do iterations, people learn things as they go and they feedback that back into whatever project you're working on. And the other problem is of course, that as time progresses, that can change requirements as well. So, you know, markets change, you know, so suddenly we've been spending six months developing something for a certain purpose, though that's no longer required anymore because some other technology in the marketplace has completely and utterly made that, you know, no longer relevant. So I guess my thing is with, my take on Agile, generally speaking, is that it was born out of that fast paced sector, and I don't wanna say that all development is like this 'cause it isn't, but I think it's come more from the fact that it's like maybe a Silicon Valley sort of VC backed, maybe a bit web centric or consumer software areas, where there's a lot of movement in the market and to be relevant and successful, you have to be agile, or otherwise you get left behind, I think. And I think that seems to have been where the whole idea was really born and is driven from. Yeah, and I think what you said a moment ago about, you know, the customer or the product owner will change their minds. I think that's kind of the critical piece here is that inevitably the person you're delivering software for or persons you're delivering software for, they're going to make a change or decide that they want to go left instead of right. And what Agile is about is embracing that change and trying to uncover that change as quickly as you possibly can. So the idea behind Agile is let's just do little pieces at a time and let's see what happens. So the times that I've seen Agile work really well is when we have short sprints, which is to say for usually about two weeks, we will bite off a chunk of work and say, "Okay, we are dedicating ourselves to complete this work in two weeks." And generally speaking, the chunk of work you bite off, which we'll get to in a minute, with story points and things like that. The chunk of work you bite off, that may not be that much because it's typically better to underestimate your own speed than overestimate. And every developer I've ever met always thinks it will go easier than it ends up going. So, the idea is each developer and the other members of the team will bite off some chunk of work that is pretty clearly deliverable within a two week or whatever your sprint length is, but typically it's two week timeframe. And then the idea is you work, work, work, work, work, get through those two weeks, and hopefully at the end of those two weeks, you have something tangible to deliver to the customer, or at least demo to the customer. And then the customer or the product owner can say, "Oh, I like this, I don't like that, "I like this, I don't like that." And that will inform what the next two weeks, the next sprint will be. And generally speaking, there's some ceremony around that. You'll typically at the end of each sprint, you'll have a retrospective, which is a meeting wherein you say, "Okay, this is what did work, this is what didn't work. Let's change this. Let's change that. Typically, you'll have planning at the beginning of the sprint where you'll figure out, okay, you'll do estimation and figure out, okay, how much time do we think each of, well, I shouldn't say that. How many points do I think each of these things will take? And again, we'll get to that in just a second. And then we'll figure out, okay, well, John, you'll do this story. Casey will do this story. Susan will do that story. And Jennifer will do this story and so on and so forth. And then we'll just kind of go into our corners, if you will, and work, work, work, work, work until the end of the sprint. Now, what I've seen go terribly wrong, and I've already made that mistake myself, is where you judge effort based on time rather than relative difficulty. So there's no real prescription, if you look at the manifesto, for how you manage what work you're doing and when you're doing it. But the generally accepted way of doing Agile, at least in my experience, is you use something called stories and story points. So a story is an executable thing. And oftentimes it'll be written in the form of, as a, some kind of user, I would like to do something in order to accomplish something. So as a user, I would like to register for the service so I can use it as an example. So it's clear who is interested in this, what the persona is, what it is they want to do and why they want to do it. And that would be your story. And of course, there's other requirements and things and whatnots and addendums that may be involved in that. But at its core, a story is as a user, I would like to register for the service so I can use it. Then what you do is during the planning period or planning meeting or what have you, and sometimes it's called grooming, you'll see very different names for this that serve ever so slightly different purposes, but the idea is sometime before the sprint begins, you and your team will get together and figure out, okay, how difficult is this to accomplish? How difficult is it to allow a user to register for this service? And the idea is you want to use relative difficulty. So you don't say this'll take me eight hours because it never takes eight hours. It either takes two hours or 40 hours. So don't describe it in terms of hours. Just describe it in terms of how hard is this. And sometimes you'll use what I've often heard called t-shirt sizing. So you'll either say it's small difficulty, medium difficulty, or large difficulty, and that's as granular as you need to get. Occasionally you'll see that, but more often than not, you'll use story points, which is a Fibonacci, is that right? A Fibonacci sequence of, oh God, it's been a while since we've done it now. So one, two, three, five, eight. No, that's not right. One, two, three, is it right? Something like that. I, I, yeah, but yes, Fibonacci indeed. Yes. That. I'm a little out of practice cause I haven't done it in a few months, but, But you get the idea. And so the idea is, okay, what is the smallest tangible change that we can make? And let's call that one. So maybe it's changing a color on a web page. Maybe it's changing copy on a web page. Or maybe it's moving a button on an iOS app or something like that. What is the smallest piece of work that we can all agree upon? Everyone in the team. Let's call that one point. Okay, well with that in mind, with changing the background color of a web page being one, is allowing a user to register for the site, is that twice as hard? That would be a two. Three times as hard? Well, guess what? You've got a three. Is it five times as hard? Well, now you've got a five. Maybe it's eight times as hard. Now you've got an eight. And this continues on to 16 and whatever else comes after. But generally speaking, in my experience, if you find something that is more than eight times more difficult than whatever you think a one is, then it's probably too complex to be one story and you probably want to break it down into, you know, kind of subordinate or child stories. But I don't come into a point here. I promise. The idea is each of these stories, you will, as a team, you will figure out, okay, this story is one point that's six, or six isn't an option, five points, that's eight points, and you will kind of figure out, okay, what is the relative difficulty of each of these stories? Yeah. And for the first sprint or two, you just kind of bite off some arbitrary amount of points as a team. So maybe as a team, you think, thumb in the air, we'll do 20 points this sprint. And maybe you accomplish 15. And so the next sprint, you'd maybe bite off 18 because you think that first sprint was a little weird. And maybe the second sprint you accomplish 14. Well, after you get a couple sprints under your belt, you start to figure out that no matter how optimistic or pessimistic this team is, history tells us this is how many points we can accomplish. And this is where agile gets to be magical because you now have a history and unemotional, it has nothing to do with estimates. It's just a history of how much work this team can get done. Well, now if you keep your estimation of story points, pretty consistent across sprints, now, you know how to plan because you know that your, it's not cadence. What's the word I'm looking for? Velocity. Your velocity is 15 points, and I'm making that up, of course. Well, you know that this team tends to be able to do 15 points per sprint. And we have a backlog, we have a list of stories that's 300 points long. I'm not going to do that mental math because I'm too lazy, but you know that that will take X amount of sprints to get through those 300 points. And suddenly you've gotten a very predictable outcome in terms of real world time, even though at no point during the Agile process have you said anything about how many hours this is going to take. And this is quite the contrary for many waterfall implementations where you'll say, okay, that unit of work is 16 hours, that unit of work, at least the way I've done it, is 24 hours, etc, etc. But inevitably, like I said earlier, no matter how many hours you think something is, you're going to be wrong. So the key is, screw talking about time, let's just talk about relative difficulty. And again, don't Don't trust what your developers think because we're all idiots. None of us, I mean, I'm sorry, John, but I'm going to lump you in there. None of us can estimate worth a darn. So let's just say how hard is this and about how much work is it, have we demonstrated we can accomplish? And then that's where it becomes so great because now it becomes predictable. I've been talking for a long time. Does that make any darn sense at all? The scary thing is that all of that makes perfect sense. And the interesting thing and okay, so you covered a lot of ground there. So let's just go back a couple of steps or points. Anyhow, that wasn't funny. Sorry. Sorry, delete reaction on that one. That's all good. Anyhow, so all right. So on the story points, with the velocity, just before I get stuck into my little rant is did they ever do different teams and have different KPIs for their velocities? Then they sort of play them off against each other. this team's doing this falsely, this team's doing it. Did I ever do that to you? - Yeah, occasionally. So a KPI is Key Performance Indicator. And a lot of that's very trendy these days, that all of your work as a developer, as a product owner, as a designer, as a QA engineer, should be at what am I doing to affect the key performance indicator, whatever that may be. And yeah, that's the problem, is that if you really do Agile right, every individual Agile team could have a wildly different velocity. So as an example, maybe John and I think everything is impossible. And so all of our estimates are like 8 points, 16 points, you know, 24 or whatever points. Sure. That, I wouldn't advise that, but that's okay because as long as we're consistently overestimating, then it's fine. But you can't take our estimates, John and Maya's estimates, and compare it to Jennifer and Susan's estimates because they might be actually quite a bit better at estimating where a one is really a one and eight is really an eight and so on and so forth. forth so yeah playing playing teams off each other is a terrible terrible terrible idea. Yeah and that's why people do it generally because it's a terrible idea. I just you know it's just it's it's just something with me that I find very grating it's like no no no sooner had I learned what story points were did I find out that there were different teams already being graded against how much they could get through in terms of points I'm like seriously guys anyway all right not Not wishing to go down that road too much, but in any case, the thing that I find interesting about Agile versus Waterfall is that the way in which the points and the collaboration, the collaborative nature, I guess you'd say, before the sprints actually kick off, you know, you actually get into them. Yeah, that whole discussion is, it's more collaborative and that has both positives and negatives. In Waterfall, the way it's been previously done, is my observation, is that it'll go to whoever the senior designer is or the senior developer is. And they'll be told, okay, well, how long is it gonna take this? And they'll draw based on their knowledge of the individuals involved, throw in some fudge factors for how long, how many interruptions they think they're gonna get with other activities, other calls on other people's time during, 'cause if you're outside of a sprint, you've got all sorts of distractions and so on, and you have to account for that in your time estimate. So, the old rule thumb was, if you have a long you think it is double it and add some. - Yup. - And yeah, exactly right. And so you start building out that schedule all based on experience, based on, rather than a prescriptive, like this team can produce X amount of points in this amount of time, generally speaking, based on previous cycles and such. With Waterfall, it's all, most of it seems to come down to a negotiation. And the problem, this is the next part, is in negotiation, when schedule, because you're dealing with time, you will often be butted up against a project manager and the project manager is gonna say, "Wow, could you shave a few weeks off that? Could you please, that'd be great." And I've had many, many an argument with project managers in my career about, can you deliver this sooner? And I'm looking at it and I'm thinking, have you read the mythical man month just for a start? (laughing) And are you feeling pregnant today? And of course it usually goes right over their head, but in any case, that's, yeah, anyway, nevermind. So the funny thing is that I actually liked the approach of two parts of this with Agile, which is the first one is the decoupling of time from it so that you're based on points. I always found Fibonacci to be a bit weird, but then I sort of understood the thinking behind it is to provide that decoupling. So it's more based on effort than time. And it's also about relativeness. I was gonna say relativity, but no. (laughing) Relativeness, yeah. because effort of how hard is this function versus this function versus this function, humans are really good at telling the difference between is something bigger or smaller and when it's put side by side. But if you give them something on its own and you say, well, is that bigger or smaller than something else that you can't observe, then people are like, well, I don't know, maybe. So I do like that concept. And I also like the fact that it's more collaborative and that's really good. Now, those are the positives. And the negative side of that is that I have also found the whole Story Points thing to be quite, it can become very, it's like any group think kind of situation where you've got a group of people and I find that sometimes the estimates tend to be either way too aggressive or way too relaxed. And certainly that's something that gets refined the more sprints you do, but that all assumes that you've always got the same group of people in the same environment in each subsequent sprint. And that has, my observation has been that is not the case. And maybe that's just because we've been doing agile stuff when we've been in the midst of reorgs and so on and so forth, and people come and go from different teams. And maybe we never had enough time to settle over a longer period. It's possible that my perception of that is tainted by the environment that I've been in. I'm not sure. Did you ever see anything like that? Oh, absolutely. And the tough thing is, in order to really have a velocity that counts and that is repeatable and accurate. In order to do that, you need to allow yourself two to four similar sprints where you're not having a lot of interruptions, or if you are having a lot of interruptions, there's a similar amount of interruptions across each sprint. But it isn't until sprint three, four, or five that you really start to settle into a velocity. Now, that doesn't sound that bad until I remind you that each of these sprints is at least two weeks. So two sprints means you need at least a month of real-world time before you have even a prayer of knowing what your velocity is. And even then I would argue you haven't really settled down for another one to two sprints, which means up to two months before you've really figured out a velocity. And that's the tough thing is that I think Agile's promise is that it's a silver bullet that will give you repeatable results immediately, when in reality, it will give you those repeatable results, but you've got to give it time to kind of settle out and debounce itself and figure out what is this team's velocity. And to come back to your point earlier, yeah, I mean, it is unfortunate when everyone thinks everything is easy, and it's also similarly unfortunate when everyone thinks everything is hard. But as long as you are treating that team in isolation, and as long as that team is consistently saying everything is easy or consistently saying everything is hard, the velocity will reflect that. Because if you have a team that was constantly saying, "Oh, this is cake. That's one point. That's two points. That's one point. That's two points." Maybe your velocity is five for a team of six people. Maybe you're only delivering five points every two weeks. And that's okay as long as you're consistently estimating everything as being super easy, because the velocity will be super low. Similarly, if you think that everything is eights and thirteens and whatever's, as long as you're consistent about it, maybe that team's velocity is 60. And the key here, and this is what you've been saying a couple of times, John, and I can't agree with you enough, is that you have to treat that number in isolation. My 60 on my team could be even slower than the 10 that your team is getting. It's just about the way in which that particular group of individuals estimates. And so you just have to look at, okay, I have 60 points of sprint, but I might have a backlog of 7,000 points. You have five points of sprint, but based on that, your backlog is only 50 points, you know, and so it ends up that even though your velocity is numerically lower, because the way everything shakes out, your real world velocity, your speed at which you're going to deliver the final product is actually quicker. Yeah, exactly. And that's something that's not always cleared when people get involved with an agile. And they try and turn it into - well, my experience is that some managers tend to turn it into a KPI driven sort of contest and I find that really, really irritating. And mind you, I also have general mistrust of KPIs no matter what they are but irrespective of that. So, just to focus on something in particular and it's something that technically, and I said before, it was a 1995 thing, Scrum, and it sort of becomes synonymous with Agile and the whole idea of sprints as well. And if you haven't been involved in one of these things, I don't know, maybe I'm just deluding myself that there's any software developer in the world right now that hasn't ever done any Agile. Surely, I think at this point it's been around for well, over 15 years. I think most people would have at least had some experience with it, but how would you best describe the process of a sprint, let's say? Yeah, so again, every team, if you really follow the spirit of what Agile says, every team will come up with their own process. But the generally accepted way of doing Agile is that either at the very beginning of the sprint or even better toward the end of the prior sprint, you will have grooming is what we typically called it, which is to say you'll look at the next, I don't know, 5 to 10 to 15 cards on the backlog, the things that are the most important things to be done next, and you'll point them. You'll say, "Okay, that card, that story, that user story is one point, that's eight points, that's five points, that's three points, etc." That's step one. And then sometimes in the same meeting, sometimes in planning, which is a different meeting occasionally, you will actually start saying, "Okay, given our velocity is 10, Casey needs three points, John needs five points and Jennifer needs, you know, what does that eight to two points. And, and let's just, you know, that's kind of fish out this work and let's get, let's get everyone situated for the next sprint. Then occasionally people will do a kickoff at the beginning of the sprint, but typically not. But basically once the sprint begins and once planning has happened, everyone just kind of goes into their corners and does their work and is mostly left alone. If all goes according to plan, except for a daily scrum and the, the idea behind a daily scrum is let's all come together, typically for 15 minutes or less, and say, "What did I do?" either today or yesterday, depending on if it's an early scrum or a late scrum. But basically, "What did I just do? What am I about to do? And what's in my way?" So, oftentimes you'll find these done in the morning. So it's typically yesterday, today, and blockers. So yesterday I worked on the foo widget. Today I'm working on the bar widget. And my blocker is I need a design from our designer for the bar widget. And that's a nice way to force the entire team to come together, talk to each other, and figure out kind of the state of the world. And this predates Slack. This predates most IM services. I mean, it doesn't predate IRC, but you get the idea. It forces everyone to come together and talk to each other. A lot of companies will actually force you. Well, first of all, they'll call them stand-ups rather than scrums, and that's because they will literally force you to stand up. Because the idea is, if you're sitting in a chair, you'll be more than happy to talk for three hours about all of your particular problems and quibbles and so on. But if you're standing up, you and everyone around you is going to want to get the hell out of that meeting room as quickly as possible so you can go sit down. And when it's done well, scrums can be very effective because it lets everyone understand what everyone else is doing without really slowing the team down too much. The pitfall with Scrum or stand-ups is that oftentimes it becomes, "Let's engineer a solution to a problem right now in this 15-minute meeting." That is what everyone does. I've done it a thousand times, and it is completely the antithesis of the idea of what that stand-up is. The stand-up is to say, "Hey, I, Casey, am having this real hard design challenge. I'd like to talk to John about it, and can we do that after the meeting?" That's the purpose of standup. But what ends up happening is John says, "Well, wait. What's going on?" And I say, "Well, let me tell you, John." It just spirals out of control. But again, in principle, I am fully behind the idea of a standup. The problem is it is so easy to execute on this the wrong way. And that's why agile coaches, which John, you brought up a while ago, that's why they get paid is because an agile coach's job, among many other things, is to say, "Whoa, whoa, whoa, whoa, whoa, Casey, bite your tongue. We'll talk about that after the meeting, but let's continue on with standup." And it seems so silly. It seems preposterous that you would need a full-time employee to do that. But some of the best run Agile teams have a full-time either Scrum Master and/or Agile coach in order to facilitate those kinds of conversations because it really is that easy to screw it up. Yeah. And I'm really glad you brought that point up actually, Casey, because when I first heard Agile coach, I almost threw up in my mouth. I thought it was a ridiculous thing. I was like, what? But the funny thing is that the longer I've sort of, the more I've been involved, I should say with agile methodology and agile teams is that they actually perform a function that ordinarily the senior design lead or design manager or lead developer would actually would have or would simply say, right, okay, you two in the back, quiet. But by taking that away from someone, it's sort of like you're offloading them to actually just be a developer and you can sort of like take that aspect of the senior role and someone else can deal with that. And the funny thing is that that actually can work really well. But it all comes down to personalities, obviously. If you get a dodgy coach, then you get what you get. But the point is that, so positives and negatives with agile coaches, and I'll talk a little bit about some of my experiences in a minute. But the other point about the sprints that I just wanted to focus on is that for me, and I thought your description was perfect. And I think that the key aspects for me are that there's a lockdown period and that's usually two weeks. And they just, I think empirically arrived on two weeks as a period of time where you can have sustained focus on a set of tasks to deliver an outcome and be too much less than that. And it's not efficient, too much more than that and people lose focus. And I realized that it's not a hard and fast rule. Some people do three weeks, some people do one week, short sprints, long sprints, whatever, whatever. But the reality is that two seems to be the, I think globally accepted best compromise. But in any case, the point is that the whole idea is that you have a group that are locked down. And I call it lockdown. That's just what I used to call it. The idea is that you're in a sprint, you're not doing anything else. So, and one of the interesting problems that I've observed in organizations is that organizations typically have a maintain component and they have a development component. And obviously, depending on what industry it is, what, how mature it is, depends on how many people are involved in those different arms of the organization. Yeah, so if you're a company that's running, you know, let's say it's, I don't know, I was gonna say Google, that's really, I don't want to talk at Google. I'm trying to think of a company that's pretty, let's just say Microsoft for the hell of it. Okay. Well, Apple, whatever, it doesn't matter. You've got a bunch of software that's already out there that you have to maintain. Someone files a bug report, go deal with it. Yeah, someone's having a problem logging into their account. Yeah, trivial stuff, whatever. You know, that's sort of levels of support, first level, second level, third level support. And then you've got your actual designers and developers and they'll be developing the next set of features. but the reality is that sometimes things get past that first level, sometimes it get past the second level and then you need to have your experienced designer or developer come in and actually have a look at the problem and resolve it. So they can't always wear that hat of saying, I'm just doing new feature development, don't talk to me about anything else. It doesn't matter if I wrote the code, it doesn't matter if it was my bug, someone else can deal with that, right? And I found that in larger organizations where you have a reasonable pool of resources in either side of that, Agile can work very well in terms of the sprint component anyhow, because you can actually get those people, you can afford to put them in a room and say, don't talk to them, they're focused on a sprint, leave them alone. Whereas in organizations that are trying to be, I would say that by nature have to be leaner or where people have to wear two hats because of either the organizational structure or simply because there's a large and high priority maintenance component. And it could just be that if things fall over in the system, you need to actually get them back up and running again as quickly as possible. There could be all sorts of reasons why that is, but in any case, that's where people being locked in a room doing a sprint can actually become a problem. And of course, once you start taking people out of that room and saying, "You know what? I need you on this, I need you on that," or whatever else, then the whole thing collapses. So it's a difficult balance and what I've observed is that essentially, if it doesn't quite fit the balance in the organization, then Agile is almost doomed to fail in terms of the sprint component of it. Anyhow, it's difficult to actually deliver on its promise and then people say, "Well, Agile failed." It's like, "Well, no, I did it." Or was it more the fact that the organization couldn't support it properly? And I've observed some of that. Yeah. I agree mostly with what you just said. The only thing I would disagree with is that in principle, if one or more of your team members is getting distracted constantly, in theory, that would be reflected in your velocity. So maybe your velocity was a steady 20 points sprint, and then suddenly there's some catastrophe that runs across multiple sprints that causes your developers to get distracted. Well, theoretically, then your velocity will fall. Maybe it'll fall to 15 or 10 or something like that. Now that's clearly not what you want. I agree with you, John, that really this is not desirable behavior for anyone involved. But the good news is if you really believe in Agile, if you really trust Agile, hypothetically, that'll all kind of come out in the wash and you'll just have to react to the fact that your velocity has gone way down. This is also why Agile and Sprints oftentimes have these kind of weird cards that are not deliverables. So, Casey needs to consult with John about some thing, just because that's what John needs in order to get his job done, even if he's in a completely other team. And maybe that gets like three points, which really is a bastardization of what agile is supposed to be because now you're kind of implying a time-based component to what a point is. But the idea behind it, and the reason people do it is because you're trying to manage the fact that work is being accomplished, even if it doesn't work against your actual goal. And I'm of two minds whether or not this is a wiser, poor choice to do those sorts of things. But no matter how you slice it one way or another, it should be reflected in your velocity, either because your velocity will go down or because you'll just have all these other cards that suddenly appear on your board that take up time. But one thing I think that you were kind of glancing off the outer atmosphere of, and I think is very important, is that especially in consultative roles, the The place that I've seen Agile both work tremendously and work terribly is the product owner. The idea of a product owner in Agile is that some human being has to be where the buck stops. My understanding of the way Apple works internally is that they call this the DRI, the directly responsible individual. At some point, it will all roll down to one human being to make the decision about when we go left and when we go right. Typically, if you're doing Agile the way most people like to, that individual is not a developer and is not even a member of your own company, potentially, it's a member of the client. So again, I'm speaking from the perspective of a consultant. So for me, I am working for Acme Widget Company. I want somebody at Acme, not my company, but not Cases Consulting Incorporated. I want someone at Acme that I'm building the software for to be the product owner. And I want them to be a product owner darn near full time. That's the other thing that often goes wrong is they'll say, oh, well, this person has 300 other responsibilities, but yeah, they'll make time for you. No, no, no, no, no. You want a full-time product owner that will be there at a moment's notice to answer questions and help steer the ship. And if Agile is really working properly, then you'll have the experience that I had once several years ago with a product owner at a local insurance company. We were building an intranet thing for them. And the product owner, I believe her name is Jen, she had said to us at some point, "Oh, I'd really like this other thing to get done, this brand new widget that we've never talked about before. I really, really, really want it to get done." How many points do you think that will be? And the skies opened, John, and angels fluttered down and you heard that "Ahh," because that is exactly what she should have said. She shouldn't say, "When will it get done?" She shouldn't say, "When can I fit it in?" She should ask us, "How many points will it be?" Because if we tell her it's five points, then she can look at her own backlog, which is really our backlog, but you know what I mean? She can look at her own backlog and say, "Okay, if I'm going to slot in five points real soon, then what five points am I going to postpone to be later?" Suddenly, you as a team of developers and designers and QA engineers, and the broader team, including the product owner, now your currency becomes story points, and it's an understood currency with understood value. Then all of these angry negotiations that you were talking about earlier, again, completely agree with you. "Well, don't you think you could skim off a couple of weeks from that thing? That would be really great because I got to deliver my stuff by such and such date and that means it's your problem." All those conversations, they just kind of go away because now it's up to Jen or whomever to say, "Okay, I really, really, really, really want this new thing I never told the team about, but the team has told me it's five points. So that just means I got to move five other points somewhere else and then everybody's happy. Does that make any sense at all? Yeah, that's absolutely. And I guess my experience is I've yet to come across a product, an owner who actually spoke that. So I'm glad that you found someone like that. In my space, it's still people are still getting used to this. And I think that that hopefully will come in time and then we can be speaking in the the same sort of language. So I think that that is awesome when you can get to that point and that is awesome. I guess I just wanted to circle back quickly and talk about just quickly on agile coaches. One of the things I said before about people being able to like being locked in a room to actually focus on the sprint and not have too many distractions, I mean, I guess my problem was also with that is that the agile coaches and one of my first experiences with an agile coach by the way, was when I had an engineer who was given to a sprint and by really, really, really, really needed him to address an issue that was causing us a lot of grief. And I went down to what they called the engine room. I kid you not, they actually called it that. I don't know if that's a common terminology but I hadn't come across it before but in any case. So, I went down to the engine room and was trying to speak to my guy and was promptly escorted to the door by the agile coach, we're in the middle of a sprint, you're not allowed to speak to them and you need to look at the folks who are delivering. And I'm like... Yeah, that's kind of their job, but that is not a very friendly way of accomplishing their job. No, it was pretty, yeah. It was pretty confronting for me because technically... Oh, totally. Yeah, because I mean, like he was, you know, he worked for me, he had deliverables and other things and he was essentially promised by someone over my head and said, "Oh yeah, we can have this person for the next two and a half weeks or whatever it is of which the majority of that time was a two week sprint. And during those two weeks, you won't be able to access your guy. And I'm like, well, hang on a minute, but I really need it 'cause this thing was broken, this part of the plant was down, I really, really needed his help and I wasn't allowed to get it. So we had to fumble our way through it and took us two or three times as long to figure it out. I mean, we got there in the end, but so where the sprint won, the rest of the business lost kind of thing. It's sort of, that was when I had that realization that when you have a critical maintenance function that you're performing and you've got developers and engineers wearing two hats, then the balance of that will drive how successful Agile can be in that sense. But in any case, Agile coaches, yeah. I mean, like you said, that's their job. And I didn't appreciate that at the time, but as I've sort of like gone along a bit further, they're kind of like playing the bit of like the good cop. Well, not really like the person that directs where agile is not being followed, but they are also a bit of an enforcer in saying, well, you know what, you two in the back stop talking. Oh yeah, no, you can't have him, he's in a sprint. Yeah, whatever. So I see them as a necessary component. And I kind of like that fact anyway, because in the end they take some of that stress away from what did it be previously something born by managers. - Yeah, very much so. And I think just to build on what you were saying that oftentimes a scrum master in my world will also be a project manager, the sort of person who would work at a Gantt chart in Waterfall World. A lot of times I've found that my best project managers/scrum masters, what they do is they are total jerks to their own team in favor of advocating on behalf of the client, but then they'll turn around and be total jerks to the client in order to advocate for the team. Does that make sense? They're kind of the taskmasters, but that's kind of their job. Really good project managers, in my experience, will defend the other party that isn't there because that's kind of what they need to do. And just on a quick other note, that experience I had with Jen, the product owner, that was a once-in-a-career kind of experience. I have done agile projects, had been doing agile projects for something like 10 years, And I think I had that kind of experience once, maybe twice. So don't be discouraged if you, John, or anyone listening to this has yet to have that experience. It is very rare and very difficult. And it only really works if you've gotten all of the other stuff squared away, where you've got repeatable, reliable story points, you've got repeatable, reliable velocity. It takes a lot to get to that point, and it is very difficult. And I think that's where Agile gets a bad reputation, is that so often it's done half-heartedly or it's done not terribly religiously, and that probably implies something I don't want to imply, but hopefully you get the point, that you have to kind of go all in on Agile, and if you don't, then it's not really going to work the way it's designed. And you could treat that as a detriment, you could treat that as an advantage, I don't know, but don't feel bad if you've never found that product owner, because there's a product owner out there for you that will be that way. You just got to give it time. Absolutely. One of the other things I want to talk about a little bit as well is the standup. It's funny when you mentioned that before, circling back to that, is that standups have existed as a concept long before Agile was even discussed in the 90s. When I worked at Nortel, for example, that was when I first came across that. that. I was in 1997 and yeah, basically the- I walked into a meeting room, literally as the chairs were being wheeled out of the meeting room. And I'm like, okay. So, we walked in this meeting room. There's now no- there's now no chairs. And it wasn't that we needed more standing room. And the manager says, this is a stand up. You have 15 minutes. Go. And I'm looking around. I'm like, yep. So, we talk now. Because I'd I'd never, you know, and the whole idea that you like the whole concept in has been attributed I think by some to agile, but the fact is that no, it's simply a good way of stopping people waffling on, which is kind of good. So in any case, I also want to talk a little bit about the whole, the utilization of visual management boards. I'm not sure. Yeah. One of the things is that I found that during stand-ups, there's a lot of, you tend to stand around that visual management board and sort of like go through each of the key things. Well, when you talk about what you're doing, then there should be something up on the board that's talking about that. You shouldn't be doing something necessarily that isn't in some respect represented on the board. So the thing is that Kanban and I guess, the thing is I always call them Kanban boards, But I think Kanban is also more broadly another methodology, but Scrum also utilizes a Kanban-like board. And hence the names sort of get a little bit conflated, but in any case, the bottom line is it's, my understanding of the differences is more about how often it's updated. So if you're updating a board, a Kanban board could be representative of a continuous process or a project or a team, whereas the Scrum board is specifically focused on the sprint, even if it's representing the same kind of board. That's my take on the difference. - Yeah, so to kind of back up just a half step, a lot of times it's very useful to see a visual representation of where the work is. And so typically what that's done, the way that's done is either via some sort of software or via a literal whiteboard somewhere in your office, you'll have a board with several columns and maybe the first column is backlog, maybe the second column is like in progress, Maybe you have in test, maybe you have in review and maybe you have delivered. You know, and those don't have to be the exact four or five, whatever columns, but something along those lines. And you have literal cards, usually post-its or what I can recommend is something called Slicky Notes, which is, this is not a sponsor, but at ecostaticink.com, these are basically like post-its, but they work via static. So you can slide them around, which is really, really cool. Um, anyways, you have something that, that represents, okay, this card is in this column, which means it's in that part of the process. And, uh, I suspect that our sponsor this week probably does something like that. Uh, where you via software, where you can kind of see where things lie. Um, but one way or another, be it via, via Slicky Notes, via Post-its, be it, um, you know, some other software, then it's a really nice way to visually see where the sprint is. Because typically speaking, you will find that at the beginning of a sprint, all the cards are on the left-hand side of the board, whatever your columns may be. And over the two weeks or however long, all of the cards are hopefully moving over to the right side of the board, which means done. And that's a really nice way not only to visually see what's going on, but also to kind of manage your scrums. Because typically, the way you do a scrum is either you go around the room person by person, or you go around the board card by card and say, OK, who's working on this card? What's the status? And yeah, I quite like doing that. It obviously becomes very difficult and you kind of really need a software solution if you are a distributed team, but if everyone's in the same spot, having, you know, slickie notes or post-it notes on a whiteboard is tremendous. - Absolutely. And actually, since you brought it up, it's probably a good time for me to quickly talk about our sponsor for this episode, and that's Clubhouse, the first project management platform for software development that brings everyone on every team together to build better products. Clubhouse was built from the outset with agile development in mind. What have we just been talking about? And with an intense focus on intuitiveness and responsiveness. With their web app backed by Fastly CDN, it really feels like a local app on any platform. Clubhouse delivers developer-centric tools for everything from Kanban boards to epics, milestones, cards, with different card classifications for features, bugs, and chores. But it's more Clubhouse's ability to interconnect all of them together that's so impressive. Users have reported creating less duplicates, navigation is very fast using a common board, but with as many configurable workspaces as you'd like to customize that board for whatever purpose you might need. Morning standups for different teams, sub teams, or all the teams, it's entirely up to you. Ultimately, any collaborative project management platform has to be as low friction as possible, and not just for software developers, but for everyone in the organization. Marketing, support, management, you name it, the lot. so everyone can contribute and actual collaboration actually happens. Finally, the other part of Clubhouse that really shines is its ability to zoom out from individual tasks to the overall project status that not only keeps project managers happy, but keeps the team connected on how their part contributes to the greater project and keeps them focused on what matters, delivering a result their customers will enjoy. There are others in the market, but they're not like Clubhouse. And what makes Clubhouse so different is the balance between the right amount of simplicity without sacrificing key functionality structured to allow genuine cross-functional team collaboration on your project. Clubhouse is a modern software as a service platform with seamless integrations for popular tools like GitHub, Slack, Sentry and lots more. And if the tools you want to integrate it with aren't available out of the box, that's okay. There's an extensible REST API in Clubhouse that makes integrations straightforward. If you visit this URL clubhouse or one word.io/10 the word, you can take advantage of a special offer for Engineered Network listeners. Of course, you'll get the 14-day free trial, but if you sign up, you'll get the first two months free and because this is a team-centric solution, this offer will work for your team, not just for you. The offer is only available to Engineered Network listeners for a limited time, so take advantage of it while you can. Thank you to Clubhouse for sponsoring the Engineered Network. So yeah, just then circling back to the whole physical versus virtual thing. When I first came across Agile, it was only, well, as I said, about two and a half years ago, like I knew I'd heard of it, I knew what it was basically, but my first true experience with it was only two and a half years ago. And I walked into this room and they had this visual management board up and it was just a whole bunch of, they weren't even posted notes. They were using the magnetic clips. So you clip a small square card into kind of like a clipboard clip style thing, but it's got a magnet on the back of it. Now we're holding that up on the board. And I looked at all this and I thought to me, well, that's how beautifully archaic. It's like, come on, what century is this? 'Cause as a software guy, I'm looking at it thinking, there's software that can do this. Why aren't we using software and a big screen? And of course, it came down to, it was a preference of the agile coach and it was a preference of management who are more tactile. And, you know, they're all generally older people that weren't, you know what I mean? They were happy to use a pen and paper. Whereas there was me with my iPad and my Apple pencil. I haven't used an ink pen in four years. And you know what I mean? It's like, but here we are shuffling around bits of dead tree on a, anyway. But those posts that you mentioned sound really cool. I'm actually gonna look into that for a completely different reason, but you know what? That sounds really cool. I've made a note of that. Thank you. Yeah, the only caveat to them is they only last like a couple of weeks when once they've actually been stuck on a board. You know, if they're sitting in the package, I don't know what magic is happening, that it's fine, but as soon as you take them out of the board, you've only got like a sprint or two before they're going to start falling off. But man, they are magical during that first couple of weeks, two to four weeks when the static electricity is really clinging. So when they fall off the board, does that mean you don't have to worry about them anymore? Like that's. - That is what I have tried many a time, John, and it has yet to stick. - Dang, okay, well, it was worth a shot. Anyhow, very good. So I guess my experience with them, as I say, is that this is a fixation on them being physical boards, despite the fact that we are supposed to be flexible in our work location, because one of the things that they've also done in our recent reorganization is that we've changed buildings and then our new building, It was a new building, fresh start kind of thing. And there's not allocated seating. And they finally figured out Skype as a thing. I mean, my business was a bit slow in that respect, my current employer, but they're finally on board with that and it's fantastic. So I mean, I can work just as effectively from home as I can work from the office, which is important since technically the number of people versus the number of seats, if everyone showed up to the office on one day, then not everyone would get a seat, But hey, I guess. Anyway, the bottom line is that I think that a visual management boards, like a software version of one having up on a screen is nine times out of 10, the better result because in the end that gives you ultimate flexibility into where you can be. And it's also a reference for others. So anyone can log in and have a look at the board depending on how you set up your sharing, of course. But the fact is that to see a physical board, you have to physically be in that physical room. and sometimes it's just not possible. And if you wanna catch up on the high level overview and status of whether you're red or green and whatever part of the project you're working on, then you have to be in the room to tell that. And that's the only downside. But that also leads into the discussion is what's the value of the board and what's the value of like who gets value from it. And I've always had this concern with the reporting of statuses of projects. And no matter how, if it's through KPIs, if it's through a visual management board, or whatever it is, who is it really for? There's one group, one school of thought that will say, well, its sole purpose is to keep the team focused and to, so the team knows where they're at and where they should be pushing harder or where they know they're on track. And the other school of thought as well, it could also be for management to have an idea of where your particular sprint is up to, so they can get an idea of how you're tracking. And the problem is that if everyone's doing these visual management boards, there's lots and lots of them all around the organization. Generally speaking, people don't actually have time to go and ingest all of that. And generally speaking, from a management point of view, most of the managers will come down, will simply look at the red green and then keep on walking and not actually comprehend the content of the board. So I say all of that considering the flip side that ultimately people still need to comprehend. So if a manager comes in to have a look at what's going on and see where everything's up to, then they need to have spent some time comprehending speaking to the scrum master or the product owner, they got to comprehend what's going on. It's not just enough to have a board and you walk past and say, "Yeah, that's great." So I've always believed, I firmly believe that the value of the board is for the actual team that's doing the work more than anything else. Yeah, I agree. I think that there's something to be said for an at-a-glance way of looking at what the state of the world is. doesn't necessarily have to be this kind of Kanban-y, you know, Scrum board, but I do feel like it is a nice way to do it. And like I said, it's, in my experience, maybe just because I'm a worrier by nature, but as I see us getting closer and closer to the end of a sprint, and I see more and more of the kind of weight of the board being on the left-hand side, which is, you know, in progress or not even started yet or something like that, then I know that if I've been goofing off, I need to stop goofing off. And I know that it is really time to put the pedal to the metal and really crank if I'm going to make my obligations and commitments for this sprint. And again, it doesn't have to be a board to do it. You could just have like a speedometer style needle if you wanted. But one way or another, I think it works out really well. I completely concur with what you're saying about management oftentimes not getting the nuance of these sorts of things. But nevertheless, I do think it's useful. The other thing I've seen useful from time to time is a burndown chart, which I'm going to butcher the description. But Basically, the idea is if you are keeping to this current velocity, this is how many points you should be doing each sprint. And given the backlog of items, this is how long it will take to complete this entire project. And you can see how you track against your velocity, are you doing better or worse, and what the final real-world end date is for your entire effort, assuming you keep this velocity. so kind of useful to know, because especially in the consulting world, like typically a project or a project team or maybe just an individual is going to be booked by a client for some number of months or years. And if you're coming to the end of that some number of months, you see that that burndown chart says you've got another month after that before this project's done. Well, that's time for some contract renegotiations, I'd say. And so that's sometimes can be useful too. Absolutely. Alrighty. - Well, I just wanna refocus a little bit now and look at some of the consequences or common issues that they come across if you apply the agile methodology and work practices. And there's a couple that I wanna talk about. You may well have your own short list or longer list, but in any case. So when the first comes to mind is, it's all about motivation and what are people's motivation? And the more we motivate people to actually execute on functionality driven by a product owner, ultimately, that preference will always be product owners want the shiny, shiny, they want the features and functionality. They don't necessarily want all of the code to be written as beautifully and elegantly as possible. You can debate whether that's right or wrong, but the reality is my experience is that the technical debt is more problematic with Agile because generally speaking, people will wanna have a better velocity and to have a better velocity, you will typically take a faster solution rather than actually having a more scalable, flexible implementation that's gonna take longer to design and develop, but will give you something that once you're finished will be easy to maintain. - Oh, absolutely. I think you've absolutely nailed it. This is very, very common because what Agile values is literally reading from the manifesto, working software over, now they say comprehensive documentation, but you could also say working software over a flexible software. Now that's probably a little bit unfair because I would bet the writer, the authors of the Agile manifesto would say, "Whoa, whoa, whoa, whoa, whoa, whoa, you can have working and flexible software all at the same time." And that's true. Sure. But it is just like you said, John, it is much more difficult to have both working and hyperflexible software than it is just to have something that works. And I think one of the most difficult things of software development is something that I still struggle with 15 years into my career is when do you design for flexibility and when do you not take shortcuts, but just, you know, do the more direct path. And sometimes I make those calls well, and sometimes I make them very poorly. And I think one of the ideas behind Agile is it should become relatively obvious, relatively quickly, what sorts of things the product owner is going to want to renege on or change their mind about, and maybe those are the things that you should be more flexible about. And then there are other things that you know are unlikely to change. And in the spirit of moving fast, you're just going to have to take, again, maybe not take shortcuts, but kind of hard code things or just be more direct in your implementation. But yeah, I completely agree with you that technical debt is always a problem, always, no matter how you write software, but especially with Agile. And that's why a lot of times after several sprints of work, a lot of teams I've worked on will take like, I forget the term we've used, but like a kind of a breather sprint where we'll take a full sprint's worth of time, a full two weeks or what have you, and just do cleanup and kind of batten down the hatches and kind of reset everything and fix some of those shortcuts that we had taken in the past. And it doesn't always work out well because you're now delaying the final deliverable in terms of real-world time. Oftentimes clients don't understand why you need to do that. Like, "Why didn't you write it right the first time?" But oftentimes I've found that can make a tremendous difference in the robustness of software and the ability for the software to bend in the future, you know, when the same product owner does make a different choice. And a very quick tangent kind of off of this, another thing I've seen a lot, especially when you're working with a client, and especially when that client is a very big business, like something banking related, for example, where there's a lot of security problems and things like that, a lot of times I'll see what's called a sprint zero. And what that means is, let's spend a couple of weeks just getting the administrivia taken care of. If we need to use a laptop that is owned by the client, does every member of the team have one of those laptops? If we don't need to use a laptop owned by the client, can we get on the client's VPN? Do we have the user access that we need? Do we have access to the database servers that we need? Do we need to stand up a database server or web server or what have you? And we'll spend one to two sprints just getting the administrivia done. Because inevitably, if you don't do that, what happens is you spend that same month doing those things while you're supposed to be delivering. So let's just embrace the fact that this is going to take some time and just cart it out and treat it as a sprint. Yeah, sprint zero is an interesting name actually. I hadn't heard that one. I've heard people refer to that sort of thing as a chore sprint where you basically are Yeah, same thing. Yeah, same thing. Yeah. And I think that's fantastic. And for me, it comes down to the powers that be accepting that that is a thing as opposed to it will just happen magically. Like here's a whole bunch of stuff that you need to deliver. And it's all the administrivia. If you don't do it upfront, you essentially you're set up to fail. You know, and it's like, well, what's the point of doing a sprint? 'Cause that'll directly affect your velocity. So what are you gonna do? - Exactly. - Yes, it's, but that's a good one actually. All right, so just on the product owner, actually just quickly, I've also struggled with the concept that one person, and I know that this is a common problem in no matter what part of business you want to be in. One person to make the final decision. Finding a person that can honestly and realistically comprehend the relative importance of all the competing objectives. It doesn't matter if they're the client or not. That's a hard thing to find. And my frustration has been that a good product owner has a good focus and a good grasp of what needs to happen and what rather what needs to be done, what they really do need as an owner. But the reality is that that's a very rare thing. Most of the time, my experience has been that these client representatives, I guess you could call them in the more waterfall strategy approach, or product owners, they tend to be, they tend to blow on the breeze a bit. They tend to be distracted by the new shiny, shiny. They don't fully comprehend the trade-offs. No matter, if you can get a conversation about points, that's fantastic. But generally speaking, they just, or how hard could that possibly be and not comprehend? (laughing) So that's my frustration with that. And to be honest, that's nothing to do specifically with Agile. It's more the fact that Agile empowers the owner with so much power insofar as directing where the work goes. Whereas in more of a waterfall approach, it's more of a negotiation of, well, if you want this, it's gonna take this much more time and that's gonna be equal to this much more money. And we have all these other things you've already agreed to that we're halfway through working towards and there's six months of momentum in our documentation and you're now saying we've got to pivot and do something else. And so agile sort of empowers a lot of that, but that's in the flip side being that's the whole point of agile. So, you know, it's like you're empowering people that if they're too wishy-washy and blow on the breeze a bit and change their minds, then that can have a massive blowout in your ability to deliver something. So that's been a frustration of mine. I'm not sure how often you've come across that, if at all. - Yeah, I definitely have seen that for sure. But again, if everything is going according to plan, that will be drawn out or kind of spelled out in the burndown chart or the lack of good velocity. - True. - And I feel like that will often fix itself in the wash. What is more challenging to me in a corollary of what you were saying is I have definitely had occasions where we've had a very engaged, very, very interested, very skilled product owner. And that individual is great, but the organization they work in is a disaster. And what ends up happening is you have a product owner that is doing everything right by the team, but they're not empowered on the client side. So they know exactly what they want. They know exactly how to get it done. They have a general understanding of what the rest of the business around them needs and wants. But then you'll have some higher up that feels like they just want to make their appearance. We used to call this a swoop and poop. A bird swoops in, poops, and flies away. Oftentimes you'll have a product owner who is engaged but not empowered, and then you'll have the product owner's boss or boss's boss or boss's boss's boss come in, swoop and poop, and say, "Oh, no, no. Don't do it that way. Do it this other way." And suddenly, three sprints worth of work, just like you were saying, John, just goes up in a puff of smoke. And that can be very challenging. And again, the best product owners are ones who are not only engaged, preferably full-time, but I didn't say this earlier, also empowered. Empowered to make decisions for the product in order to get things done. And finding someone that is both engaged and empowered is very hard. You will very often find either somebody that is engaged but not empowered or empowered but not engaged. - Yeah, absolutely nailed it. And then that, exactly. And I've unfortunately had too many bad experiences with yeah, with never finding both. And it's quite frustrating, but that's not the fault of Agile, let's be clear. Necessarily, it's more about the power that they wield and hence by not getting that right mix right in an individual can have more negative consequences than you would get in a waterfall is more the point. But all right, next issue with Agile that I've seen, And I don't know if this is an issue with Agile or Paul, again, getting back to it's how it's implemented, overreaching on each iteration and just essentially taking on too many tasks and the effect that that has on the overall, the stress level and indirectly, therefore the velocity. And then if you have too much of that, then that will drive constant context switching for an individual trying to deliver on all of these things. and it's not actually possible to do that in the timeframe. And that drives inefficiency. And the funny thing is that this is something that I know that you'll say, well, in the longer term that'll balance out. And it's like, well, yes, but what I've observed is that if there's too much of this KPI driven attitude, then that may not happen. And there will be this drive to churn through points and to improve that velocity. And taking on more is the natural reaction try and get through more to improve the velocity to drive the KPI. And then that creates a behavior which is where you continually overreach. And maybe that's the job of the coach to stop. I don't know. Yeah, I think you nailed it. I think the coach or scrum master or whomever should be putting the kibosh on that. But ultimately, if you're overenthusiastic about signing up for cards, you're just ruining things for yourself. Because again, if you're realistic about how much work you're getting done, then the velocity becomes accurate and then everything falls into place. But so often what'll happen is exactly what you described and the team will overreach and they'll sign up for 50 points worth of work, but maybe 30 points of which are actually delivered and 20 points of which are in this kind of nebulous zone where they've started, but it's not really delivered. And then that just means the velocity is just an arbitrary number. It doesn't really represent anything. And so my recommendation in those situations is try to force yourself and your team to be conservative because it is much better to only complete five points but get them all the way out the door, written, tested, approved, etc., than starting 50 points and delivering 10 of them. And so what I try to do in teams that I've been managing either in terms of being a scrum master or like a technical lead is to try to encourage people to do a couple of things. One, don't bite off more than you can chew, just like you said, John. But number two, try not to context switch if you can avoid it. So yeah, you might think you can do 15 points worth of work just yourself, John, but only pull into the sprint five points worth of work until you are sure that those five points are done. As much as you can get done on them, they are done. Preferably they've been tested and maybe they haven't been approved yet, but at least done and tested. And at that point, sure. Pull in another five, even if it wasn't originally slated for the sprint, because then guess what? That means your velocity was, you know, your team's velocity was 15, but because John did a great job this time, maybe it's 17 next sprint again. Like just trust the system. And like, I'm yelling in your direction, not at you, but trust the system, man. And it'll all work itself out. Yeah, absolutely. Right. And the whole thing about context switching is just good advice, no matter what you're doing in any aspect of anything. 'Cause I find that the more you keep trying to juggle all these different tasks at once, the more you're switching out what you've got to focus on, it just completely, your efficiency just collapses in a heap. And the funny thing is that people need to think about things as like, I'm going on a very long walk. How do I get from A to B? Well, you take it one step at a time, right? And that's the whole point is that every step is a task, do that task, then go to the next task. And then once you've done all those tasks and you've got through all those points in the context of Agile, you'll look back and you'll say, "Oh, wow, look at all the stuff I did." As opposed to, I'm gonna try and jump between all these different things at once, get a little bit of a progress on each of them and then end up achieving very little net movements. Kind of like I'm kind of wandering slightly in a circle sort of spiraling outward slightly. So I've kind of moved a little bit that way, but not really far enough. But anyway, dear me. Okay, so two more issues then that I wanna make sure we talk about is burnout. And that is not burned down as in a chart, but burnout from burned down or something. And that's terrible. Anyway, the point is that my observation is that people in a sprint environment, particularly if there's a lot of management pressure an organization to have multiple back-to-back sprints. Probably you could argue too close together, which from a churning through a large number of points is a tendency I've noticed in some organizations. And I think, and this is the problem is I had to dig to see if there were any actual documented studies about whether or not engineer programmer burnout was higher under Agile than under Waterfall. nothing definitive but there seems to be a lot of noise in that space. And I sort of thought about this and it's like, well, it doesn't matter what methodology you use, you work your people too hard, they're going to burn out. And it doesn't matter. That's not necessarily a failing of agile but I think that it's something that if you do have too many sprints, they're too close together and they're back to back, you're basically going to work people too hard and ultimately, you can't sprint constantly. Yeah, I think that's true of really any engineering, I was going to say software, but really any engineering I think can fall into that trap. I don't think it's unique to agile. Something that my last company did that I really, really liked was that it was either once a quarter or a couple of times a year, like once every couple of quarters, I forget exactly what it was, but they would allow us to basically just go goof off for a half a day. And so sometimes we would go and race go-karts. Sometimes we would play mini golf or something like that. And these are not terribly expensive things to do. And it also helped that this last company was a product company, not a consulting firm. And so us going away for four hours doesn't have a direct difference on our bottom line. But nevertheless, they would fund us going and goofing off for a little while. And I cannot recommend that enough. I don't think that offering, that having the team leader whatever, say, "Hey, let's go get drinks after work," is the right answer because A, not everyone drinks and B, after work time is sacred to a lot of people, myself included. But if your company is flexible enough that you are allowed to do something that preferably has no financial input from the team members, even if it's as silly as going out to lunch but having the company pick up the tab and letting that lunch be like a one or two hour lunch instead of the 20 minute run, grab something and run back, you know, dance that a lot of people typically do. Um, I found that that makes a world of difference, especially if it's something more than just lunch, you know, lunch is a good start, but something more than just lunch going out to, to watch a movie together or to, to race go-karts or I don't know, do any number of things. I was going to let my American come out and say, you know, go target shooting, which is weird because I don't even own a gun, but anyway, um, you know, do something hopefully less American than that. And I feel like that makes a tremendous difference. Obviously, I think Americans especially, and I don't want to speak for Australians, Americans especially have a very complicated relationship with what we call vacation time. I believe you call it holiday time. And oftentimes Americans will get to the end of their year and have some of their paid time off, some of their holiday or vacation time unused. And I'm of the opinion that vacation time should be compulsory. Like it is a big problem and it is a big ding on your record if you do not take vacation because that is critical. That time away from work is critical for you in order for you to be an effective worker. Not everyone feels that way, but that's the way I feel. And I think just being aware of your team's morale is something that the technical lead, the product lead, and or product owner, and especially the project manager/scrum master, something that the three of them, well, typically that's three people, but you get my point, the three of them need to work through and pay attention to because you're exactly right. Especially if it's in a high pressure situation, especially if the team is firing on all cylinders, that's almost worse because that means everyone has just been cranking. And this is what you were saying a minute ago, you know, when everyone's cranking at some point, you need to release that, that, that pressure and you need to let that valve open. And my, my favorite way to do that is during work hours because that doesn't necessarily affect families. It doesn't necessarily affect the person's personal financial world. You know, it, it, it, and it's, and it's like a treat that you get to miss work for a little while, you know? Yeah, absolutely. But, but see, that's, that's the key part is that, you know, it's an acknowledgement, um, by the, by the organization that, uh, we value your sanity and therefore, um, exactly. Yeah. Take a few hours on the company and go and unwind. And you know, it's like, and that's fantastic. Right. And it's been, I think in my case, well, we've just been through a bit of a rough time in our company in terms of downsizing and such, but the reality is that we used to regularly go out every probably month or so for like a team lunch. It was like a very extended team lunch. So normally you mentioned the mad dash out, go out, grab something, come back kind of thing, and try and get it done in an hour, in a lunch hour, lunch break, what have you. This is actually was more like a, we'd head out on a Friday afternoon, typically once a month and most people wouldn't come back to the office if you did, you'd meander back at maybe 2.30 or something like that. And it was pretty easy in the afternoon after that. But yeah, actual team building or getting out there and getting the go-karts and everything like that, that's something that periodically when you're in a high productivity environment is absolutely critical. It's an acknowledgement from the company that you know what, you're a human being, you're not a robot. And so far as the holiday thing goes, I'm almost applauding when you were saying that because my problem is that that is a thing here too, where people just stack up their annual leave and they never take it. And so we have this thing, it's not actually called this, but we refer to it as the naughty list. And the naughty list is essentially, if you have more than 20 hours of leave, then you're yellow, you're in the yellow. If you've got more than, sorry, 20 days, if you've got more than 30 days of annual leave that hasn't been booked, then you're in the red. And if you're entering the red, you're on the naughty list. So I went beyond the warning list and into the naughty list. And my boss said, "Right, John, you're gonna be taking some leave, aren't you?" And I'm like, "Well, of course, yes, of course I'm taking some leave, yes, absolutely. I'll take five weeks." And he's like, "Oh, no, no, no, you don't have to overdo it." I'm like, "Oh no, I'm taking five weeks." And I tell you what, I'm so glad I did. I feel so much better. And I literally only been back at work two weeks since then. So, that beautiful holiday bubble where you chill, it's still mostly intact. So, I'm happy with that. Good outcome. - I had a coworker at my last consulting job and I could not do this personally, but the way he favored doing things was he would take literally no days off for the entire year, but then every single year, it was just understood that he would be gone from roughly American Thanksgiving, so the third or fourth Friday in November, until the next year. So he would take all five or whatever weeks of his vacation, all in one shot, all the end of the year. And that's what he did every year. And I think that's bananas personally, like I couldn't do that all the time, but for whatever reason, that's the way he liked it. And that's what he did. And every time, you know, January came around and he was quite a bit more refreshed than he was in late November, you know. - Yeah, absolutely. I'm not sure I could do the same thing every year either, but, 'cause this is actually the first year I took five weeks off in one block. And yeah, I'd like to be able to say I'll do it every year, but I think common sense will prevail. I won't do it every year, but at least two weeks, I think, at a time is the minimum. 'Cause if it's only a week, then you just sort of getting into the swing of things and then it's back to work again. I think to sort of decompress, you really need that second week, but in any case. So interesting aside, but not necessarily to do with Agile, but anyhow. So we're just gonna circle back into Agile again, just to, while we sort of wrap this up a little bit, is one of my other frustrations with Agile is that it tends to lead to poor documentation. And I know that that's the intent, but I guess my problem is that I've always been brought up on the value of documentation. Like in engineering in general, software is just another form of engineering. So I've always believed in it, but the problem is the debate about how much needs to be documented. Yeah, and I feel like there's the code is this, What's the saying? The code is the documentation as opposed to the documentation is the documentation and the code is the code. And I guess the problem with that is that code is never going to be as good as documentation in so far as you'll never be able to describe in code as easily as you could read English, sorry, whatever language you're programming in versus whatever language you're speaking and vice versa. I mean, you're never gonna be able to write unless you're gonna write something like pseudocode. But if you're starting to write pseudocode to describe code in a specification, I'd suggest you've potentially lost the plot. 'Cause I seriously had a manager tell me to do that in my younger years and I looked at him with a raised eyebrow and I'm like, "Are you serious?" So anyhow, I've always believed that when you're developing any formal software that you need to have a few essential components in terms of your documentation. The first one is a coding standard. And that's just more of a common comprehension so that everyone in the team or the company organization can follow what other people have done, just basic naming conventions for variables, object structures. And I know some people say, "No one reads the coding standard." It's like, yeah, well, you're gonna read my coding standard when I write, you're gonna read that. But anyway, the point is that I think that that's an essential cornerstone. It should not be ridiculously prescriptive, but it should have the basics. The next thing you've gotta have, I think, is a functional specification about what you're actually delivering, meaning just what it has to do. Doesn't have to be ridiculously detailed necessarily, but there needs to be something saying, this is what our widget's gonna do. And then finally, you need to have an interface specification for all of your points of interface with whatever it might be. Sometimes you don't actually have any if it's a fully self-contained product, but generally speaking, you're going to have something. And in my world, we sort of tend to combine the interface specifications and the functional specifications together because our primary interfaces are just a human machine interface or HMI. So we wanna say like what data points, what's logged, what's alarmed, what screen the information is displayed on. But we're gonna stop short of saying, well, it's 10 pixels down, three pixels across, or something like that. We don't bother with that. We don't do detailed mock-ups generally, 'cause that's just too much detail. So, 'cause after all, finally, whatever you produce will be vetted by the end user anyway. So, what's the point of doing that other than simply saying, well, we're gonna have the following items on the screen, and we'll show you the iterations as we go, and you can give us feedback along the way. But what I found with Agile is that, and I guess your mileage may vary depending upon the Agile coach maybe, but in the end I found that it's, that follows that idea of just barely good enough. And for me, just barely good enough isn't good enough, but that's just, I don't know, that's just my take on it, what do you think? - Yeah, it's tough because as you said in the beginning of what you were just talking about, that the kind of tenet of Agile is not to document. But this is especially complicated when you're talking about a consultative role, because at some point, the team that wrote all this code is going to go away. And it's up to the client to maintain it oftentimes. And so then the client is looking at this hopefully really great piece of software with zero documentation on it. And I think that I agree that not having enough documentation is a very common ailment with Agile. But I would argue that if it's something that's really important to either the team or the client, then you can build in time for that. You can either build it in in terms of just assuming that it's part of a delivered story. You can build it in in that you could make an entire story for documentation. You know, there's several ways in which that you can kind of build all this in and have it work within the system of Agile. But I 100% agree with you that it is a very common pitfall that has happened to pretty much every Agile project I've ever worked on. And it is kind of disheartening to get to the end of a project and then realize, oh, I have like one to two to four sprints worth of work that is nothing but documentation. Most developers, myself included, don't really enjoy that. And so if you can avoid it and kind of keep an eye on it from the front, I strongly recommend it. Fair enough. All right, cool. So honestly, I guess just to sort of wrap up a little bit Now, I feel like the fundamental problem with any kind of, whether it's waterfall, agile, whatever methodology you might choose to use, the common thing in all of them is us, like human beings. The fundamental rule with human beings is that we're, well, we're lazy. We don't like responsibility, generally speaking. And what I mean is we don't like to be held responsible necessarily. I think people, that's as a general rule that holds, there will always be some people that are happy to be responsible for everything, but I don't know, maybe they end up being basket cases or something in the corner at the end of the project. But anyhow, people also, I think, generally confuse activity with productive activity. And I think that just because people are scurrying around doing things doesn't necessarily mean that that is actually, you know, to borrow one of those industry expressions, moving the needle necessarily. And I think that ultimately, whatever system you choose to come up with, any system can be gamed. Because the problem with humans is humans think up a system, whichever it might be, waterfall or agile, and then all the other humans implementing it, will then think about ways they can game the system because they are lazy, they don't wanna be held responsible, and they're happy just to be active, but not necessarily produce anything. And I realized that that's generic, but it's meant to be generic because I don't think that Agile wins or loses over Waterfall for exactly these reasons. It's an attempt I think, and I think largely successful in certain environments, it can be far better than Waterfall where you don't have high documentation requirements where you do have to pivot because the success of your business, depends on it being as agile as possible because if you can't pivot and actually change the direction because the product or the market has moved in a different direction. If you don't do that, you'll just cease to exist. So, and when you're threatened with that sort of thing, you have to work very hard and compete very hard in order to survive. And that's just the way it is with survival of the fittest. So applied to Silicon Valley terms, I guess, but anyway. So I don't think that agile in the end is bad in isolation. I think the problem is that agile and I think you may have even led into this from the very beginning is that it's, there are lots of little pitfalls and people can let their egos get in the way, people try to game the system. Ultimately, it can be just a bad implementation just because people don't understand how it's supposed to work. They haven't comprehended what it's intending to do. And in the end, it's given Agile a bit of a mixed reputation. Some people love it and embrace it. Some people can't stand it. Some people say it's just the latest buzzword methodology that is this going to, in another five years, not only talking about it, but in the end, I think that the overall, the software industry as a whole is better for it than without it. Yeah, I think you're right that as with anything, it is easy to fall into the trap of this is not really working for my team or for my company and for whatever reason, and maybe it's innocent, it's been sabotaged, whatever. But I have lived many, many poorly done Agile projects, and they are a slog, and they are tough, and they are frustrating. But I've also lived at least a handful of really good Agile projects. And I can't stress enough that in that perfect scenario, when everything really, really works the way it's supposed to, it really is like magic. and you have repeatable results, predictable results, which is what Waterfall really strives to be, is deeply predictable. You have that in Agile. I've seen it in Agile. But you gotta trust the system, and you gotta have an environment where the system can work. And obviously, I've had very, very many prescriptive thoughts about what I think is a good implementation of Agile. But ultimately, if you really trust Agile through and through, you've gotta figure out your own system that works for you and your organization. But in a perfect world where story points aren't really ours in disguise and where product owners understand the trade-offs and where you're not getting swoop and poops all the time, in a perfect world, Agile is an unbelievably fun and reliable way to write software. And so I don't see it going away anytime soon, but it is one of those things where you know, we've given you a length of rope that you can quite easily strangle yourself with, but you can also fashion it into a very nice knot. And so I hope you end up with a knot and not a noose. Nice. And in, in the end, ultimately it comes down to, um, you know, people in the end, how motivated they are, how aligned they are with delivering an outcome, you know, keeping it technical, listening to the, the leads involved in the product owners and just, and delivering on that. And I think that in the end, people that are determined to not make agile work will be determined to not make it work and will then complain and that'll be evidence to say, "Well, that's why it doesn't work." So I feel like if you do, like you said, if you actually go all in and you actually work within the methodology, then it can be - it can actually work out quite well in the right situation and it may well be magic. I'll be honest with you, I haven't actually seen that firsthand, but I do know that it's possible. So I'm not going to be too old and curmudgeonly and say anything about, Agile is just never going to work or whatever else. No, no, not at all. Not at all. I think it has some interesting merit. So in any case. Alrighty. Well, if you want to talk more about this, you can reach me on the Fediverse at [email protected], or you can follow engineered_net on Twitter to see show specific announcements. We also have a YouTube channel with more content going live regularly if you're interested in that. If you're enjoying Pragmatic and you wanna support the show, you can. Like some of our backers, Carsten Hansen and John Whitlow. They and many others are patrons of the show via Patreon and you can find it at patreon.com/johnchidjie or one word. Patron rewards include a named thank you on the website, a named thank you at the end of episodes, access to raw detailed show notes, as well as ad-free high quality releases of every episode. So if you'd like to contribute something, anything at all, there's lots of great rewards and beyond that, it's all really appreciated. Beyond Patreon, there's also a PayPal for one-time contributions at paypal.me/jheg. But if you're not in a position to support the show that way, that's completely fine. There's lots of other ways you can help, leaving a rating or review on iTunes, favoriting the episode in your podcast player app, or you can share this episode or the show with your friends or via social. And all these things help others to discover the show and can make a huge difference as well. to thank Clubhouse for sponsoring the Engineer Network. If you're looking for an easy to use software development project management solution that everyone can use, remember to specifically visit this URL clubhouse or oneword.io/10theword to check it out and give it a try. It'll surprise you just how easy it can be. Pragmatic is part of the Engineer Network and you can find it at engineer.network along with other great shows like Causality, which is a solo podcast that I do that looks at the cause and effect of major events and disasters in history, including the Deepwater Horizon just recently, the Columbia Space Shuttle, Concorde, and lots more. Causality is on track to overtake Pragmatic. It's growing in popularity. So if you haven't yet checked it out, make sure you give it a listen. If you'd like to get in touch with Casey, what's the best way to get in touch with you, mate? I am on Mastodon somewhere, but almost never pay attention to it and don't remember what my handle is, so I'll just skim right through that. But you can find me on the dumpster That is Twitter at Casey lists Casey YL ISS you can also find my website at Casey list comm and My other podcasts that I do the external tech podcast is an ATP dot FM and analog is that relay dot FM slash? Analog spelled either the correct way or the way that has a unit Smooth okay, well once again a special Thank you to our patrons a big thank you to everyone for listening and as and as always Thank you once again for coming on the show Casey. Yep. Thank you John It's oh, it's always a pleasure. I appreciate [MUSIC PLAYING] (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (Music) (upbeat music) (upbeat music) [Music] (upbeat music) ♪ ♪ [Music]