 All right, thank you. Oh, good, we're on. All right, hey, I'm Zach. Glad you all could join us. I have a question before we start. How many of you have ever heard of Agile in the context of software development? OK, now here's my next question. How many of you have practiced Agile in the context of software development? It's not a trick question, I promise. And then my last question is, how many of you hated your experience with doing Agile in software development? OK, at least one or two. OK, that's not unusual. I actually, I was talking to some friends of mine the other day, I snoop on the programming subreddit. And it seems like every other post there recently is talking about how terrible their experiences are with Scrum or Agile or those sorts of things. And a few times I've hopped into those discussions and I've asked them some questions about what they didn't like about it and what they described to me sounded super terrible and toxic. And what I want to do today, I have a couple purposes that I want to list here. First off, give you an introduction to what Agile or Agility means if you're not familiar with it. Coupled with that, if you are familiar with it or if you think you are familiar with it, I hope to change your perspective on what Agile looks like in a healthy organization. I know that in my little bio, it mentioned that I am a Scrum master. So I'm going to start first and foremost and say, I am not attached to Scrum. It is just the certification that I hold. And that I have been a part of implementing Scrum in organizations that have ended up having the unintended impact of being in some ways more toxic than what we were doing before we adopted Agile. And the reason that that happened is because we implemented a tool and a process and a framework without understanding at its core what Agility is. And so at the end of this talk, I'm going to mention some specific things about Scrum, but I'm not going to really talk about it until then. We're going to talk about what Agile is, back to the basics. And basically, there's... Well, let me get through my purposes first, sorry. If you already are familiar, maybe a nudge to the next step of understanding and then just to be clear, this is not a prescriptive or framework-based talk. I'm not here to sell you on why you should do Scrum or XP or Kanban. As a matter of fact, we're really not going to mention any of those except tangently because those are not Agility. What I want to talk to you about today is the Harry Shoe. And the Harry Shoe is a mnemonic for us Americans that have a problem remembering the Shoe-Ha-Ri steps of Aikido in Japanese culture. A lot of lean manufacturing Agile thought process has come out of Japanese culture and so there is a lot of these words that can kind of tie back to that. But the process of Shoe, Ha, and Ri are essentially what we see here on the right, foundational understanding and mastery. And I like to think of them as imitation, assimilation, and innovation. And a really great example of this way of learning is in the movie Karate Kid, all right? When Daniel convinces Mr. Miyagi to teach him to fight, what does Mr. Miyagi say? Okay, wax on, wax off. Wax on, wax off, see, I did it the wrong way, you gotta go inside, right? Wax on, wax off, right? Paint the fence, paint the fence, right? And so Daniel does these chores for, I don't know if they mention exactly how long he does all of these chores, but finally he gets frustrated and he goes to Mr. Miyagi and he says, I want you to teach me karate, but you're just teaching me wax on, wax off, I'm just doing all your chores for you, right? And there's this really awesome moment where Mr. Miyagi says, do wax off, do wax off. And then he goes to punch Daniel and Daniel deflects the punches. And then he goes to punch him again, he says, paint the fence and Daniel just instinctively, he just gets these reflexes, right? Where he starts blocking these punches, right? Now, in the imitation phase, the shoe stage, essentially what that is, is you're just following a process and you don't really know why. And you might see some benefit from it, you might build up a little bit of that muscle memory from it, but it hasn't clicked why we're doing this thing yet. When Daniel has that moment with Mr. Miyagi where he realizes, oh, this is why he's had me do this, right? Daniel starts to understand some of the theory and he hits the ha stage. And then if anyone has seen the amazing Cobra Kai on Netflix, I'm a big fan, it is absolutely the most ridiculous over the top like karate has taken over this Southern California. Like nothing about it makes sense, but it is glorious, right? Then you see Daniel as an adult and he has not only imitated and assimilated, but he starts adding his own moves into Miyagi do karate because he has reached the innovation stage, the restage where he understands what he's doing and the theory behind why he's doing it so well that he then has the foundation necessary to create and innovate in the same spirit of the thing that he was learning. And so my hope with this talk, sorry, my mouth is real dry, is that for some of you, I might be able to help move you along this stage of agile knowledge and agile understanding. So now that I've said all that, sorry, I forgot I had a fun karate kid gift, I should have skipped to that. That's from Cobra Kai too, it was really good. Now that I've said all of that, especially for those of you who don't know what agile is, what is agile? Okay, agile is not a tool. I have seen lots of ads in my career. I'm a product owner primarily right now in my day job and I've seen lots of tools, use Jira and be agile, use GitLab and be agile, agile is not a tool and a tool will not get you to a place of agility. It will not happen, we'll talk more about that in a minute. A framework like Scrum is not going to get you to a place of agility because a framework is just prescriptive. It might help you in that shoe stage, hey, we're gonna change the way that we're structuring some things. When I first helped implement Scrum in a previous role, we changed the way we were doing some things and we did see improvement, right? Just going through that imitation and we maybe even dipped into that hostage a little bit like, oh, I understand why we're doing this thing. Like this has really helped, this has really been a benefit, right? But a framework like Scrum is not itself agile. Any prescriptive process, right? Anyone who says to you, if you do X, you'll be agile or I can come and I can teach this class to you and you will be agile and if you follow this process, then you will be agile. Those people are charlatans and they are selling you snake oil every time, every time. And I say that to someone, by the way, who does have Scrum certifications, right? They do have their place. They certify a base level of knowledge about a specific process but they are not in and of themselves agile. There is in fact only one definition of agile and it was written by a group of developers in the early 2000s who were super fed up of the way things were going in their industry. And this is it, this is that definition. They said, we are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value and it's hard to see but these items on the left are bold and they are not on the right. We have come to value individuals 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 they made sure to be clear with this last point that a lot of Agilists forget. That is while there is value in the things on the right, we value the things on the left more, right? They're not saying there's no value over here. They're saying that by the definition of agile, because these are the people that created it, it was a group of I think 30 some devs that came together and signed this document that they called the Agile Manifesto which you can find on some really old HTML only GeoCities look and site, agilemanifesto.org, okay? But they said, look, we value these, there's importance in these. But we are defining agility the way that it is improving our lives and our businesses by valuing these things more than these other things. Now, I'm sure all of you fully understand what agile is and what it means and we're good now, right? Like we can go home, right? This is why some of the frameworks are tempting, right? Because if you're talking to someone about a business, they're like, I want practical advice. I want you to tell me how to be agile. It's very tempting for a business to say, oh, I can spend a couple thousand dollars a person and send them to a class and then everybody understands agile and we just have this new thing and we do X and then we're agile. It's a very tempting idea, but again, it's not a good idea, right? Because they will teach you a process but they will not teach you the lens by which you should view that process. And that's what I wanna focus on here. I can't tell you how many times, especially early on in my agile career, I went to the scrum guide for answers to problems without understanding that the scrum guide was written with the understanding that I would have an almost religious reverence for the agile manifesto and the 12 principles and we will go through all of them and I'll give some examples for my career from those things. But scrum, XP, Kanban, they are all ineffective unless viewed through this lens. So what is, let me redefine agile even though I already said there's only one definition of agile. I'm gonna give you my pretend definition. Agile's a way of thinking about and approaching complex work that embraces short feedback loops to provide better outcomes for customers and builders. And then I added my own sort of dichotomy here, improvisation over choreography, right? And then I added my own caveat, it's not my own caveat, I copied and pasted it from the previous slide. That is while there is value in the items on the right, there is value in the choreography. We value the items on the left more, improvisation. So my wife and my daughters are ballet dancers. Well, my youngest is in the gymnastics because she is just a whole different person and it is great. I enjoy the ballet most of the time. Sometimes I have gone and been like, this is not my thing, right? But it's beautiful, you go in, they've worked for months on this one routine and you go in and they do this wonderful choreograph dance, the nutcracker's been the big thing, right? Every Christmas, if any of you know someone's in a ballet, like nutcracker's a really big thing in ballet. But sometimes I've been in there of like, I'm just not feeling that cracker this year. You know what, the show does not care that I'm not feeling the cracker that year. Like it doesn't care. It's going to go on regardless and that's fine, right? It's art, that is what it is meant to do. But contrast that with going to a comedy club or even going to see if we're gonna take it to like an extreme literal, an improv show. You go to an improv show and what happens? They might start their routine, but they're gonna go back to the audience frequently. Say, hey, give me a location. Give me an activity, you know, give me this, give me that. And there's this conversation that happens with the audience and the audience and the actors, even if it's just a comedian, right? As a comedian tells a joke that doesn't land, he's probably got 30 jokes like that in his head. And he's like, well, that one didn't land. So I'm not gonna tell those ones anymore. I'm gonna adapt my set based on the feedback that I am receiving from the audience, right? They're skilled in that way. And that is one of the differences in improvisation versus choreography. Choreography is just gonna happen. Improvisation can respond to, if you'll forgive my terrible analogy, the market demand, right, for some of those things. So let's talk about each tenant of that manifesto. First, individuals and interactions over processes and tools. What does that mean? What it means is that communication, the focus on communication is more valuable than a focus on tools and processes, right? Process and tools are only valuable when they help support that primary goal of communication. What is your feedback loop? I'm probably gonna say that like 30 times. I'm really sorry. But your feedback loop is so critical between you and your customers, you and your users, you and your clients, right? How often are you talking with them? How often are you showing them what you have built so far so that you can get that feedback and understand that you're on the right track, right? Now, every industry is different. Some people probably cringe when I said that and if Beth were in here, she would be like scope creep, right, like, you know, don't go back to your client and then they'll give you all these different requirements. And every industry is different and there are different ways to handle all of those pieces. We'll talk a little bit about when it's scope creep and when it isn't. Because I think that's a really valuable distinction. And there are times that scope creep might actually be really profitable for you, right? Depending on the type of project that you're building for someone. And so I think that just saying, well, this isn't what we had planned on building, so it's scope creep. And I don't know anyone who says that here, right? Beth certainly does not say that. But anyone who says, well, that's scope creep, so we're just avoiding it. You're on the other end of this. You've gone too far, right, in that direction. Working software over comprehensive documentation. What does that mean? Well, what is a minimum viable product? I read a book a while ago called User Story Mapping that proposes the idea instead of a minimal viable product, a minimal viable solution, right? You have a problem. What is the least amount of effort and work that you need to do to solve that problem? Okay, great, start there and show it to your client. Show it to your customer. See if that's something that you can get in their hands quickly, right? As long as it just solves that basis problem, then you can build from there, right? What is done, right? When we say working software, what does that mean, what is done? Y'all should write this down because this is just great. Someone wrote a cult of done manifesto. And by someone, I mean Bre Pettis and Keo Stark, they wrote it in 20 minutes because they only had 20 minutes to get it done. And that tells you exactly what you need to know about the cult of done manifesto. It is wonderful. It's its own thing. It could probably be its own whole talk, right? So we're not gonna go there right now. But it's worth looking at and exploring. It's just this fascinating idea. What documentation is necessary, right? Documentation is necessary, right? Again, just because working software is above comprehensive documentation does not mean that we don't value the thing on the right, right? We just value the thing on the left more. Do you need to write all of the knowledge base articles for this thing before it goes out? Do you need to make sure that the code is perfect and your linter passes everything? I mean, you probably should, you know, ideally. We'll talk more about technical excellence and where it plays a part later. Do you need to have full 100% test coverage to ship something? I remember a couple of years ago, some of you may know Patrick Rowland. And he was on a panel discussion at a previous word camp. And I remember him talking about a plugin that he released. And he was talking a little bit about his process. And I think it was some kind of panel on starting plugin development. And he said, when I write a plugin, I don't write any of the tests in the beginning because I just want to know, is there a market for it? Are people going to use it? And if it's something that people start using, then I'll go back and add the test coverage later as I build onto it. And there were several devs in that room that were personally offended that he said this. And they argued with him. And I remember he just sat back with not like a smirk on his face, but this is very much like, well, I'm right. But I think about that a lot. It's true, right? Why would you spend the time writing full testing coverage for something that you don't actually know yet if anyone's going to use, right? It's absolutely true that we focus on what is necessary, but we get working software out the door first. Customer collaboration over contract negotiation. Collaboration is important more than contracts. This ties very closely to the next one, right? What the customer needs right now might not be the thing they need three months from now. Let me give you an example in my personal career. I worked for a company here at Birmingham. Some of you may know it. I'm not going to say the names because I don't want to get in trouble. But I worked for a company that helped ensure the integrity of online exams. And we were working with a very, very large client who had a certification program that they were pushing out in K through 12 and schools, middle schools and high schools. And we were building all of this custom work for them to be able to do their exams with integrity in local classrooms with teachers as local proctors for these students. And then COVID hit and schools closed. And this client said, we need to change this because this obviously isn't going to work anymore. It would certainly have not been appropriate from a business perspective to say, oh no, no, your contract was for this. This is what we're going to build for you. Anything else is scope creep, right? That sounds absurd because COVID is a pretty big deal, right? But that totally derailed the project that we were working on. But there are some people who would say, well, that was your contract. That's what you agreed on. You have to go through this whole new thing that like, and we didn't do that because that would have been a terrible business decision. We immediately went with them, we replanned, we shifted, we used what we could and we changed directions and we saved that contract with them, right? Because having that plan ahead of time and sticking to it and refusing to adapt and change to the needs of the market, COVID is a very drastic example of that, right? But there's lots of different market needs that might change right in the middle of a project. And as builders, we should be receptive to those things, right? We got to renegotiate a contract with them and say, hey, yeah, absolutely. We're going to go ahead and replan this. But obviously, this is more complex now and we're adding all of these extra pieces, so we're getting a little bit more money from you, right? So in instances like that, that, I know jokingly, I don't think anybody really would call that scope creep, right? But that change in the market was profitable for us, but also we were able to help our client and give them that satisfaction of the tool that they needed at the right time. And then responding to change over following a plan. Change is inevitable. Change will happen. Depending on the timeline of the project that you're working on, it might happen more, it might happen less, but it will happen. Can it be harnessed to your advantage and to your customer's competitive advantage for these changes? Is what you're working on right now the most important thing? Or are you stuck in the sunk cost fallacy? I struggled with this at my job this week. We had been working on something that took us a little bit longer to build than we had anticipated and we are so close to the finish line, but a new need in our market came up almost overnight and our resources had to shift to a different project. And so that project got put on hold just so close to the finish line. And we will finish it in a couple of months, it will go out, but the market needs changed and I had to suck it up and take my own advice, right? And not get stuck in that sunk cost fallacy and say, you know what, yes, this is the most important thing that we need to do right now. And there's also the opportunity cost. Sometimes responding to change can mean you don't do anything about it, right? But it's important to ask those questions. What is the cost if we don't do anything? Is that a viable future, a viable plan? So those are the four principles of the Agile Manifesto. Those are the strict, excuse me, four parts of the manifesto that are also 12 principles that provide a little bit of extra guidance and a little bit of temperament of some of the others, right? And remember, these are not prescriptive. This is not telling you you do X in your Agile. This is a way to think about things, right? So I said earlier that I look at these sometimes with an almost religious reverence, right? If I'm encountering a problem with my teams or in the businesses that I'm working with or consulting with, I will go not to the scrum guide like I used to, right? But I'll go to these 12 principles that we're about to go over in those tenets of the Agile Manifesto. And I'll just think about the problem while I say, are we prioritizing, responding to change over following a plan? There's not the following of plans bad. Sometimes that's good. But are we making the right priorities and trade-offs there? So the 12 principles are awesome. I love them. I think they are more helpful than, they are more helpful for me to help interpret the four, I guess, tenets. And the first principle is this. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. What does that mean? Get something into their hands quickly. Get that feedback from them. Get that loop going. Understand better if you're on the right track. You can have that comprehensive documentation here, all of the things that they're going to need. And you can go in a silo and you can build that whole thing and then come back and present it to them. And it might be great, right? And depending on what kind of project you're building, that might be really suitable in some ways. And it might be really terrible in other ways, right? But get something in their hands early and then deliver continuously. Consistency is the key here, right? If you're delivering and then it's like another month before you get something else out, that's not really consistent or a continuous delivery of that software. The faster you can get something working into your user's hands, the faster you can get that feedback. Welcome changing requirements even late in development. Agile processes harness change for customers competitive advantage and maybe the seller's bottom line. We've already talked about some examples there. Scope creep can be cash money or it can really strangle your project if you're not careful. I know Beth and some of her talks she's really, she talks about like the limits that you need to put in your contracts and say, hey, we're not going to go past this point, right? You need to have those sorts of boundaries because scope creep is a real thing and it does happen. But when it happens as a result of market change, it can be beneficial for you and your client to address it. Deliver working software frequently from a couple of weeks to a couple of months with a preference to the shorter time scale. A lot of places that I've seen that do scrum, as an example, the standard seems to be like two week sprints. Every two weeks we're going to deliver a thing, right? Most places I know that do that, the devs don't really love it. And interestingly, some of you might be terrified of your core when you hear this and you might love this, right? I talked to some developer friends of mine recently who work here in town and they were talking about how much they love the environment that they work in right now. And they were bragging about how they did 30 deploys that day, like per day they're doing 30 to 60 deploys directly and not directly, they've got their staging environment, right? But they've got their process set up in such a way that they can push to their customers that frequently. And there are amazing benefits to that, right? Because that probably means there's really small changes, right? Which probably means if something goes wrong, it's a really easy small fix, right? But when you bundle even up to two weeks worth of work and release it all at once, sometimes you have to untangle two weeks worth of work to figure out what just happened, right? So that is why the preference to the shorter time scale is important. This is written in the early 2000s where it probably was not feasible at all to have 60 deploys a day. But interestingly, the devs, I know they're the happiest and they're at rolls right now, that's the kind of stuff that they get to do. So the preference for the shorter time scale is a boon for many reasons. Business people and developers must work together daily throughout the project. All right, don't tell Beth I said this one, project managers are not always business people in this scenario, right? And this says business people and developers, right? It can be very difficult for a development team to be working on a product when they have never talked to a user of that product. There's one thing if you're building a client site and you know, okay, all I need to do is I just need to make these pages and I need to look a certain way and this is the content that needs to go on them, right? But if you are building a plugin as a part of a team or something like that, if something is being dictated to a developer about what they need to build but they don't understand the users or they've not talked to the users, they don't understand the problems that the users are having, they can solve problems in really weird ways, right? That are really, really counterintuitive for users. I, oh man, I really wish I had put this slide in. I wonder if I can describe it. There's this video I saw. You know those toys that kids have where they get all the little shapes and they have like a bucket that has a cutout on the top of the bucket of all the different little shapes. And this video was titled, Software Developers Watching QA Test the Product. And so they've got all these shapes, it's like, okay, you see this? I've got a square. Which hole does that go in? That's right, the square hole. And he puts it in and the developer's like, yes, great, it's working. It's like, all right, look at this, a circle. Can you guess which hole this goes in? That's right, the square hole. And it goes and it fits in the square hole. They're like, all right, see this bridge shape? I wonder which one? And then every single shape ends up going through the square hole, right? And if developers don't understand how users are using tools, that scenario can play out at a much larger scale. I've had many conversations with developers who say something like, well, why are the users doing it like that? That's stupid. And it might be to be totally fair, right? But if you don't understand your users and you don't understand how they're interacting with your software, those are the kinds of pitfalls that you're likely to run into. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. I can't stress enough how important this is. I've been in situations on teams that they might have like the corporation or whoever has decided, this person is the team lead. They're gonna be the final, you're gonna get the final stamp of approval from this person as the architect, right? And we go into a planning meeting and we talk about how this new feature is going to be built and you have a junior dev sitting in the corner and the senior dev, the architect, whoever, is saying, yeah, we're gonna build things this way and this and we're gonna do this and that and nobody questions it. But that junior dev is sitting there the whole time going, this is gonna be a train wreck. But they're not gonna say a word because their authority on that team has told them this is how we're going to do things, right? And in that team, that self-organization was harmed. It was not a safe environment for a junior dev on that particular team to stand up to the senior dev or even to suggest, hey, did you think about maybe this thing over here that might cause this issue? And inevitably it ends up in this situation where the junior dev is like, well, yeah, I thought that might happen. Why didn't you say something? Well, it wasn't my place because so and so said we were going in this direction and they get the final, you know, so you wanna make sure that you're creating an environment where your team can self-organize and they can have these open discussions. I'm not saying that you shouldn't have those types of roles on their team. The Scrum Guide does say that. Scrum Guide says you shouldn't do that, right? I'm not being prescriptive there. I'm just saying that your culture needs to be set up in such a way that anyone can feel free to voice their opinions or concerns because when that team is self-organizing, the product that they end up with on the other side is going to be better for it when everyone's voice is heard around that topic and planning. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. This has been a really interesting topic during COVID but I still think it's true and I think you can do it over video calls though I don't think that's ideal, right? Everyone knows the stat that like 70% of your communication is non-verbal, right? I have been in rooms and I have seen it happen on a Zoom call where the situation that I just mentioned might play out and someone would say, yeah, we're gonna do things this way, we're gonna tackle this, we're gonna do this thing and I see someone else kind of squirm a little bit, right? Or like they shift or they kind of get this look and be like, hey, Jane, why did you, when Steve said this thing, you kind of, I don't know, what were you thinking about when he said that, right? And pull that out of the team because you want to create that culture where they feel comfortable coming forward and saying something, right? But if we were all on a Zoom call with our cameras off, I would not have seen that, I would not have known that. Could the products still have succeeded in the end? Maybe, probably, right? But the input that I got from that team member and this actually happened several times, right? The input that I got from that team member when I just saw they were a little bit uncomfortable with what was being said and I pressed to ask them why, inevitably changed the architecture of the thing we were building every time and that would not happen if I couldn't see them, right? So I'm the kind of person, I'm that weird guy and my company that I join every conference call with my camera on, even if I'm the only person, right? Just because I want to try to facilitate that culture and I think there's value in that and I know that some of you are probably cringing so much right now that I said that and I get it. I understand I do, but I think that when we can see each other especially when we're planning that we can build better products together. Working software is the primary definition of progress or primary measure of progress. Here's what that means. If you're not delivering software, you're not making progress. I have been on teams where our devs are working 50, 60 hour weeks, burning themselves out and things are not being delivered and the sad realization in that instance is that we're not making progress. I don't think that's a failure on the dev team, right? Generally that failure comes from planning on the product, on the business side, things shifting too quickly without adequate communications. There's lots of potential issues that can happen there, but the truth is when something like that happens you're not making progress. And also it's worth asking if your devs are spending 50 to 60 hour weeks and you're not shipping that software is it actually even as valuable as you think it is? If your customers can go that long without receiving the thing that you're building is it really the most important thing for you to be working on right then? That's a hard question sometimes. And I think when I see a lot of toxic agile implementations I see stuff like this get put on the dev team. Why is this happening, right? Without the ownership of the business side about why these things are happening because it's the business that needs to answer questions like if we haven't actually shipped this is it really as important as we thought it was? And there's important questions to ask. Speaking of working 50 to 60 hour weeks, another agile principle is that agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace. I hate the word sprint because it's dumb because who can sprint 24 seven and maintain a constant pace? Nobody can, right? I hate that that terminology exists in agile the way that it does because in my opinion when we go back to the definition of agile which are these principles in that manifesto using the word sprint feels like a violation of this that we should be doing something sustainable that we can continue doing, right? And we should always be asking is this a sustainable thing that we're doing when you see that your devs business people, right? Or as devs and you feel like, hey, this is not a sustainable thing we should feel empowered in our organizations to raise the flag and say, hey, we need to change how we're approaching this because we're gonna burn ourselves out. Continuous attention to technical excellence and good design enhances agility. Technical excellence is not something that you sacrifice to be agile. You don't focus so much on getting stuff out the door that you never write those test cases, right? But by writing those test cases, right? By making sure that you have that test coverage that enables you to get to a place where you can do something absurd like 40 to 60 releases a day, right? That enhances your agility in the long term. And so we don't sacrifice technical excellence. We still pay attention to good architecture. But what we don't do is try to plan every possible thing ahead of time in a way that if we try to change it later we have boxed ourselves in because of the type of architecture that we're using without some sort of significant migration. This is my favorite one. Simplicity, the art of maximizing the amount of work not done is essential. And I love this because it doesn't say do the minimum. It says maximize the amount of work not done. Be very intentional about maximizing the amount of work that you don't do. I've been in a room with devs and we're planning something in a dev rightfully so. We'll say something like, oh yeah, that's a great idea but what about if this happens? This would be a nightmare to untangle. If this thing happened to the user we have to plan for that, you know here's all the ways that this kind of thing would go wrong. And I have been sort of derailed in that conversation and we really get into like problem solving all of the potential issues related to this edge case. And then after we have already a problem solved or even worse after we problem solved and then went and executed to make sure that we write all of the code to prevent this weird edge case. So how would this happen to a user? Oh, well they'd have to do this, this, this, this and like it would be such a catastrophic comedy of errors, right, almost zero percent chance that that thing would ever happen but we've wasted all the time as a team planning, we've wasted all the time as a team developing, right? So asking those sort of questions on the front end which has been a big failure of mine in the past how likely is this thing to actually happen can save us some of that time and resources to build the things our customers really need because we're maximizing the amount of work that we don't do. The best architectures, requirements and designs emerge from self-organizing teams, this echoes the previous one, but making sure that your team has the culture set up where they can push and challenge each other. Did I copy this slide? Sorry, it threw me off that that idea was in there twice. And then this is the last principle. At regular intervals, the team reflects on how to become more effective than tunes and adjusts accordingly. How do you do that? Well, let's talk very quickly about some of the prescriptive frameworks and some of the words and terminology that they add. Some of you may have heard some of these glorious buzzwords like retrospectives, reviews, sprint planning. This one I hate because it's amazing, but nobody understands it. The daily scrum, daily standup and then refinement. Now, when I said that if you start implementing something like Scrum, but you don't understand Agile first and the purpose of those things, first there might be some pitfalls that you get into. It is shocking. The number of people that I've talked to for this daily, they say, well, it's called a daily standup, so you better stand. No one's allowed to sit down. It's the stupidest crap I have ever heard in my life. Like that's just, that's not the point, right? Or in the scrum guy that used to say for a daily standup, here are some suggested questions. What did you work on yesterday? What are you working on today? Did you have any blockers? I see devs cringing right now. I see it, I see you, okay, I see you. Because that is just mentioned in the scrum guide, as here are some suggested conversation topics. But because the scrum guide said, here are some things that you can use. People took it as gospel without understanding why we were asking those questions. And then a daily standup or a daily scrum becomes, oh, here's what I did yesterday, I'm doing this today and I have my blockers. All right, great, can we get this over with? I have stuff to do, right? That's terrible. That meeting is awful. And for all of you that have ever been in that meeting, I am so, so sorry as an agile practitioner that we ever let that happen to you. It's super common and I hate it. And I will speak out against it all the time. The purpose of each of these events in scrum, the retros, the reviews, the planning, the dailies and the refinement is to support what scrum calls the pillars of scrum. In the beginning of the scrum guide, there's this section that says, here's the scrum values. Here's the scrum pillars. First time I read the scrum guide, I looked at this as like, this is just the preamble, this isn't super important. I want to get into this stuff, tell me how to do what I need to do, right? But when you do those things, you miss that all of those events are about transparency, inspection and adaptation. Every single event in scrum is about those three things. So if you're not doing those three things, you're really not doing scrum. And agile at its core is all of these three things as well. Transparency enables inspection. The work that is being done has to be visible in some way because inspection without transparency is misleading and wasteful. Inspection in turn enables adaptation. Inspection without adaptation is pointless. Why are you inspecting something if you're not going to take any action on it? It doesn't make any sense. Scrum events are designed to provoke change in every single event. Your daily standup is not, what I did yesterday, what I need today, no blockers. Your daily standup is, hey team, we've got 24 hours until this next meeting. How can we make the most of it? How can we come around, support each other? How can we plan the next 24 hours worth of work to maximize our output, right? Hey Joe, I see that you've been working on this task for three or four days. We didn't estimate it that high. Do you need help with that? Can I, like, can I, is there something like, I think if we did this thing or, hey, I know you're touching that code and it's a little bit buggy, but I've been in there before. Can I help you with that piece, right? That is where a daily scrum is. It's not a freaking status report. And don't let anybody tell you that, right? If you have to do that in your jobs, find a way to come together as a team and do your daily planning or whatever you want to call it and have your own meeting that meets this definition of transparency, inspection, and adaptation. I'm just going to skip to these real quick. These are the scrum values, right? So at the beginning of the scrum guide, it talks about transparency, inspection, and adaptation, and it talks about these values. It does that at the beginning of the guide, because within the scrum guide, these are the lens by which you should view everything else in the guide. Courage. The courage to do the right thing, work on tough problems, say the hard things to your team, right? Say I'm struggling. No dev wants to say I'm having trouble solving this problem. I know many, many devs. Not one of them has ever wanted to say that thing, right? But it's important. Focusing on the work, meeting the commitments that the dev team has set out, not the commitments imposed on you, treating team members with respect and being open. These fall back to the values, the principles, the manifesto that we read earlier, and that's the lens by which scrum should be viewed. So if you've been in those toxic agile, those toxic scrum environments, I'm really sorry. I hope though that this discussion has given you some, maybe some encouragement, maybe some ammo. I don't know what your culture looks like or how much you might be able to influence change in your organization, but I hope that you can understand that agile is actually pretty cool, but a lot of implementations of it are terrible. They're really, really toxic. And so I hope that you don't just immediately shudder when you hear agile and that you all have a little bit of understanding and you're a little bit further on in that Shuhari path. Here's some additional resources. Agilewatercooler.com is a community that I started when I started learning about Agile, because I realized it was not something that I could learn on my own. I really needed people to challenge me. In the last several years, it's grown to over 1,000 folks. It's on Discord. We have weekly calls where we talk through some of the challenges that we're facing and we kind of think through together a good way to solve some of those. It's an awesome community. If you're interested in learning more, I would recommend that. Called Done Manifesto is awesome. This book, The Goal, is actually written about like lean manufacturing. But if you just think about all of the widgets that they're making as lines of code, I promise you it still makes sense. It's an amazing, amazing book. Phoenix Project and Unicorn Project are both about a really giant dev project from different points of view. One from the dev outside, one from the developer side. And it's a pretty great book that takes the principles of The Goal and applies it to software development a little bit more. I'm sorry, captioners, I'm talking really fast now. And this last link, if you can Google Agile is Dead, Dave Thomas is one of the original signatories of the Agile Manifesto. And he wrote this blog post recently that said Agile is Dead, Long Live Agility. And it echoes a lot of what I said. A lot of people co-opted Agile to try to sell you something and they forgot what it was about. And so if you want to understand a little bit more what it was about from one of the people who invented it, that's a really great blog post to read. I'm Zach, thank you all so much. I'll talk to you soon. We've got five minutes for questions. Questions? Come on, I know you guys have questions. Zach? I just can't see, that's my problem. Hey Zach, great talk. Question, how does this apply to distributed teams? So I have team members in Portugal, Brazil, Australia, India. So we can't do daily stand ups or retros very easily. Do you have any thoughts on how you would apply this to a more distributed team? Yeah, so one of the things that I meant to mention in the talk that I didn't, right? As I was trying to be very careful not to be really prescriptive and one of those reasons is every organization looks differently, right? So by kind of internalizing the Agile manifesto and those principles, you have to look at your unique situation and figure out how you might best achieve some of those goals. I work primarily with an offshore team. They're in Belarus, but we do have, there's enough of an overlap in their work schedule that I get to meet with them on at least a semi-regular basis. One thing that I think is interesting is when you look at problems that your team might have deliverability-wise, when you look at it through the lens, and when I say team, I don't mean dev team. I mean like your whole team, like in the scrum guy when it talks about a team, that's talking about the business people and the devs, right? If your team is having deliverability problems, looking at them through the lens of the manifesto and the principles might lead you to something that might not be the problem you thought it was, if that makes sense. I know that's not super prescript. I'm trying to avoid being super prescriptive, but finding a time for your team to be able to, okay, if there's one thing that I can say that would be really beneficial for your teams to be able to do if they're distributed is even though this is technically a scrum-specific thing, it's in the spirit of the adjuvant manifesto, find ways to hit that transparency, inspection, and adaptation cycle, help your teams to understand that cycle and why it's important and why it's valuable. One issue I ran into is the language barrier. I use the term bottlenecks a lot, and my team members thought the bottleneck that I was like getting on their case, right? When I said bottleneck, like we have a bottleneck in QA and the QA people got really upset and they're like, we're not a bottleneck, we're not a bottleneck. I was like, no, no, no, there's always a bottleneck. That's why this book, this is why this is awesome. The goal, this book, the goal teaches there's always a bottleneck. It talks about the theory of constraints and the goal of every business really is to make money in the end, but in theory of constraints, you find the bottleneck and you exploit the bottleneck until there's, that bottleneck is not the bottleneck anymore and then you find the new one, right? And you do that through that transparency, inspection, and adaptation cycle. So if you teach your teams the importance of that and help them understand like bottleneck's not a bad word, then I think you can make some pretty neat advances and collaboration with them. Yeah. I started out in software but moved more to project management. What do you see as the advantage of Agile for project management? Well, I, okay. When I started learning Agile, and Beth and I talked a lot about this too actually because she ribs me a lot because she says Agile doesn't work. And she's right in the flavors of Agile that tend to exist in the wild, right? Some of the toxic environments that we've talked about. Agile and waterfall, when I was learning Agile initially, these things were pitched as like polar opposite approaches. But I don't think waterfall the way that I was taught waterfall exists in opposition to Agile actually exists anymore, right? I think most people recognize and understand the value of some of those shorter time scales. Like no one, by and large, there's not giant three, four year contracts being planned and then no one's gonna touch or renegotiate that thing over time. So what I think I've seen is a lot of the principles of Agile pulled into what I would call traditional project management or what was previously called waterfall project management. If you look at the, if you've got your PMI certifications, the new Pumbak project management body of knowledge has a lot of these Agile principles in it. There's even a whole other companion guide on like Agile project management that they have. So I don't think that they compete so much as I just think it's important for people to understand that it's core the spirit of Agile because I think even if you're doing a project that someone would consider like a traditionally project management thing, there's lots of opportunities to improve that project if you just look at that project through the lens of some of the things that we talked about. So I'm not trying to be like super prescriptive and say traditional project management is bad, Agile is the way to go. I think that there's this really neat meld of them coming together, right? Like this doesn't talk about, when you look at the Agile manifesto, it doesn't talk about risk management as its own like separate thing. That is something that a project manager needs to know that that's not here, right? And so I think that those things work in tandem a lot of people think scrum, Agile, whatever replaces the need for traditional project managers. I don't think that's necessarily the case but I think that that requires that the project managers understand a little bit more about what this cycle looks like and how to embrace that change because in the past, I don't think all project managers were taught to do that. I don't know if that makes sense as an answer or not but I think that they're really, they really can synergize really well if you're willing to embrace that piece. All right, thank you all so much. Thank you so much, Zach, everyone. Thank you.