have you ever had a retro that kind of went like this you and your team get in a room everyone with the best intentions you all are willing to approach the conversations in a blameless manner you're not pointing fingers you're not trying to throw anybody under the bus and you identify areas that need improvement whether it's in the team process maybe it's some kind of management issue or product issue maybe you're just looking back and you're saying i'd like to change the way we think about x y or z simple adjustments that you know are supposed to be a part of a good retro the retro ends and you go back to work and nothing really changes at all again everybody had good intentions but for one reason or another whatever you did in the retro didn't really pan out didn't really translate into mean any meaningful change at all in today's episode i'm going to give you two specific ways to improve the outcomes of your retros improve the likelihood the likelihood that you're actually going to make changes now this doesn't mean that just if you do these two things that things will get better automatically it does still require some kind of discipline to follow through but there is likely a problem in how you are defining the retro outcome if you think about the retro outcome as a process and the process having some kind of input and output requires that the output be compatible with some other process think about it like the interface to the rest of your process specifically if you're looking at retro you want to have a good interface between your retro and the rest of your process so if you're looking at retro you want to have a process that's going to be compatible with some of the other processes that you're going to be and the rest of your process the things that it's trying to change very often the kinds of things that we end up saying in a retro looks something like this we don't like the way that we do our deployments so we should have somebody look into that or we're not really sure how we're going to make that thing happen so maybe we should do some planning for that our alert channel in slack is too noisy we should do something about it these are hopefully obviously bad outcomes from retro it's not that the assertions themselves are bad you've identified important problems perhaps but the outcomes the decisions for what to do about it are not very good at all let's compare these to two other frameworks that we use for defining some kind of task we can think about the smart framework for defining goals that's the specific measurable actionable relevant and time bound these particular goals or adjustments that we're defining have none of these qualities maybe they have relevance but that's about it if we look at the way that we define something like user stories typical user stories or tasks in a backlog whatever your task management process is we're going to have to define some kind of pretty much all of them would require more than just do something about it they might require something like acceptance criteria or they might require some kind of technical specification that the team all agrees on in any case our retros the outcomes from our retros are often ignored for their specificity and so i recommend that you do two simple things two simple things these are the tips that I have for you today to improve the outcomes from your retros. The first one, we're going to steal from the smart framework, but we're just going to steal the S. Specific. What specifically are you going to do? If your alerts channel is too noisy, what specifically would you want to do about it? Or if your answer is that you just want to look into it, you're not really sure what you want to do about it yet, be specific about who and when. The more specific you can get, the more likely the outcome turns into a task that can actually be executed. It also avoids another problem when you're defining the problems of looking back retrospectively and just saying that you're not going to do it. You should be smarter next time. Sure, we don't say it in those words typically, but a lot of the time our retro outcomes sound something like think further ahead next time or maybe be more careful. Take more steps. Test more. These are all essentially in the same bucket, the endless treadmill of improvement where your only answer to a problem tends to be some formulation, of do better. So by being specific, we are trying to identify what can we do next time. What trigger should we pull or what kind of process should we automatically assume when we get into this situation in the next round? And this brings us to our second tip, and that is to respect uncertainty. Another way of putting this is treat everyone as a friend. Every outcome from a retro as an experiment. If we say, well, next time we should test better. We should do better. We should think further in advance. We should be more careful. There is no need for further adjustment. If we were to say, well, exactly how much should we test? The answer maybe in the old retro version is however much is enough to ensure that we test. However much is enough to ensure that we test. However much is enough to ensure that we test. However much is enough to ensure that we test. At the end of the day, going to have a problem. This is, of course, a fool's errand when it comes to software. No amount of testing can 100% guarantee that there are no bugs in your software. And so when we choose a specific adjustment, what we're doing is we're formulating a hypothesis. We're saying, we believe that if we were to have tested for one more day, that we could have prevented the problem. The important difference here, when you say, next time we're going to test for one day, is that you are accepting that there's inherent uncertainty and that whatever adjustments you're making in your retro are experiments rather than fixes. When you experiment, you adjust one thing, you measure and you adjust and you measure, and you evaluate and change. Choose better pathways iteratively. A retro does not perfectly and definitively provide the right boundaries for a given problem. It doesn't give you a prescription for a solution. It observes a problem, it reacts to the problem, and then it does it again and again and again. That is the point of doing regular retros. If your team does regular retros, this is the intention, not to choose a singular big hammer, we're going to solve the whole thing, this sprint kind of solution. Instead, accept that uncertainty is a part of your job. It's a part of your life. It's a part of reality. And so we make adjustments. We run experiments. And then we measure and we do it again. Thanks so much for listening to today's episode of Developer Tea. I hope that in your next retro, you will make these two adjustments. One, be specific. And two, respect uncertainty. Turn those outcomes into experiments in that next retro. Thanks so much for listening. If you enjoyed this discussion, you almost certainly would enjoy further discussions in the Developer Tea Discord community. Head over to developertea.com to join today. Thanks again. And until next time, enjoy your tea. Bye.