Why Retrospectives Matter - Learning from the Past to Build Better Businesses

Welcome to Building Better Developers, the Developer Noir podcast, where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We are the Building Better Developers podcast, also known as Developer Noir. This season is Building Better Businesses. I am Rob Broadhead, one of the founders of Developer Noir, also a founder of RB Consulting, where we go out and help businesses wrangle the tech that is out there, take that technology sprawl and turn it into something that is a benefit and not a headache or some sort of other drain on your business. Yes, there is a cost involved, but the important thing is that you want to look at it as an investment and not a sinkhole or something like that. Sometimes we even take a lemon and turn it into lemonade. The way we do that is through simplification, integration, automation, and even innovation. We sit down with our customers, we make sure that we are clear on what their business is, what their goals are, where they at, where they want to go, and then we help through that initial technology assessment to turn it into a project technology kind of roadmap. And then we can either help them go ahead and execute on that roadmap, or we will walk side by side and partner with them to execute as well. Good thing or bad thing? Good thing. I had an interesting thing a couple of weeks ago. I don't know if I actually mentioned this on the podcast at all. I play hockey and I got run through a couple of many, this is a few weeks ago. Had a lot of good stuff that, there are a lot of neat little stories that came out of it. The key thing was I didn't get hurt or anything, ended up having to keep one of my sons from beating the guy up that took a run at me. And it didn't seem that bad at the time to me, but it actually was on video. And so for another reason, there were some people looking at the video later, some of the officials, and when they saw this guy take a run at me, it looked so bad to them that they, after the fact, suspended him for a game. He didn't get anything in the game, but after the fact, they came back and they suspended him. So that was a good thing. And even I, when I was looking at it afterwards, I was like, wow, that looked a lot worse than it felt. He should be thrown out. And he was. So good thing, the good guys, the blind guys, they know that people know as refs got one right. Bad thing. This is bad for a lot of people. And this is not an uncommon thing. Around here in the greater Nashville area, one of the things they're doing, and it's, I'm not sure who all is doing it or how they're doing it, but because properties are growing in value on a very regular basis, they've decided to pull this little like slight a hand thing and they've dropped the, they've lowered the tax rates, but they've also gone through and done a sweeping assessment of everybody. So while your rate is lower, it's going to be on a much higher property value. For example, the house I just sold, I was looking at it, it basically added about 50% on top of its prior value. And while they may drop the overall percentage rate, the money that they're going to take in, the fee is going to be bigger. So it's a bad thing. So one of those, I guess is good when your property values are going up. The bad thing is, is the tax man is out there looking for his share and his cut of the same. Michael, however, is going to introduce himself. And if he asks you for money, just say no, because you don't owe him a thing other than your attention. So go for it. Introduce yourself. Thanks Rob. Hey everyone. My name is Michael Mollosch. I'm one of the co-founders of Building Better Developers, also known as Developerner. I'm also the founder of a company called Envision QA, where we offer a variety of services for businesses to help you with your software, be it quality assurance, software development, or quality control services where we come in and we can be your testers. If you are building software and you don't really do a lot of testing, we can bring a small team in and we can help you test your software. We can also come in and help you get that project across the line with multitudes of developers in many variety of languages, or we can just help you figure out what it is that your business needs to help you put together that assessment, put together that software requirements document. So you can actually build what you need or go buy what you need for your business. Good thing, bad thing. Well, good thing. Let's see. Well, there's been a few things recently. I've actually completed quite a few projects recently that have kind of been blocked on a little bit, so it's kind of a good, bad. And with that, I've finally been able to not entirely disconnect, like Rob's been doing really good with these, like turning off notifications, digital fasting. I'm getting there. I'm not there yet. So I'm still, so this is a good and bad. I'm improving on that, but it is still dragging me back in, unfortunately, in ways that I don't like. I have not fully been able to just turn off notifications and sit back and relax one evening and just play video games or watch a TV show. So it's kind of my good and bad this time. So this episode, this is sort of a good and bad kind of topic in itself. We're going to talk about project, product, really like project or phase retrospectives. Now, if you're in the world of Agile and Scrum and things like that, there's a retrospective that occurs at the end of every sprint. And so that's, it's a very regular thing where you basically, to give a little more definition and background, essentially what you do is you look at what happened in the previous couple of weeks in that sprint and look at ways to do better the next time around. Now, the ways you can do better is you may do more of the good stuff, less of the bad stuff, or go find something new because there are some problems that you need to address. It is really what the goal is for any retrospective is to take a look at what was done, how it was done, what were the results, and how can we learn from this essentially? How can we be better? And I think this is something that used to exist more often. I do not see it as much in the modern business world where there will either be a period or a launch or a product or a service or something like that that completes, and then there is a retrospective or a postmortem that is done on it. Now, if you're doing it as a reference project or something like that, then yes, you will probably see that because you're writing up all of the things that went on, and then there is that postmortem to say, here is what we went right, here is what we went wrong, here is what we are doing better, things like that. But we should be doing this on a regular basis. It depends on what the length of your projects are, but if they are lengthy and heavily involved projects, you probably should do it at the end of every project. If you're taking months to go through it, and this is even if you are a solopreneur, even if you're doing a side hustle and it's just you, I think it is worth it on a regular basis, essentially being at the end of each of these projects. And if there is a lot of them, maybe every second or third project, but on a regular metric where you can say, yes, this is my third project, I'm going to do a retrospective, or this is my third project, I'm going to do a retrospective on the last three projects. And the reason we do this is really, it is, it's going to look at now that you are done, to step back a little bit and look at what occurred for ways to learn from it. Now, the way we're going to do this is you don't just, it tends to be very often, it tends to be that we look at the last week or two of the project, because that's the most fresh. Hopefully, you have been documenting stuff along the way, whether it is status, whether it is maybe a series of emails or documentation, it may be a history of documentation as that evolved. But that's what you really want to do is look back, where were you when you started? And ideally, you have sort of some sort of milestones or something like that, that is a documentation of your journey. How long did we think this was going to take? How long did it take? What was involved? And looking back, it may have to require you to look through some emails or notes or slacks or slack messages or stuff like that. It's like, what went wrong? Where are some things that we, oh yeah, we had that struggle, we had to get through it. So it's not just, yes, it was important we had that struggle, but how did we get through it? And maybe now looking back, is there something that we learned that now we can avoid seeing that in the future? That we can get out ahead of it so we don't have to essentially fight the same fight. If we do, how can we prepare ourselves so that we can fight that fight better, that we can get it done easier, things like that? This is why, and one of the things is, if you're getting to a point where now you're sitting here going, I don't even know how I began to do a retrospective, that's why you're here. And that's why we're talking about it. Because one of the things you need to do is have some sort of a paper trail, have some sort of a list, a roadmap that you went through, something along those lines that you can look back and you can hang your hat on those points and actually go back to them and see that, yeah, we were working on this, we struggled with that. If you're a developer, it may be going through commit comments that have occurred over a long period of time. It could be if you're giving regular statuses to a customer or if your team has been giving you regular statuses. It's going back and looking at those status documents. It's looking at updates that you gave your customer over time, or whoever the product owners or the stakeholders are. It's going back through that so you can remind yourself, and if you've got some sort of a daily journal or blogs or something like that, even better, so that you can remind yourself what occurred, what went on, and now that you are not in the thick of it, particularly because now you've seen some of the fallout that occurred from some of those things, some of those decisions and actions, now you can say, you can judge them a little better. Was that good? Was that something that was avoidable that we really need to avoid in the future? Was that something that's like, eh, it wasn't that big a deal, we panic, but now that we know how to do it, it's not going to be a problem in the future? There's so many ways you can go with it. It really is taking the path that you took, looking at the markers, whatever they happen to be. It may be milestones, but it may be points where there was a really good week or a really good day or a really bad week or a really bad day, and assessing those from a distance and saying, how do we do more of the good stuff and less of the bad stuff? I know it is a very generic approach to a retrospective, but that's sort of where I'm at, is trying to just give you some starting points because everyone is, of course, unique in and of itself. So it's like, how do I have a little bit of a framework maybe that is a loosey goosey framework that I can work with so I can go back and figure out how to do things better? What are your thoughts on this and maybe some of your experience with it? Yeah, so many different ways to go with this. So like Rob mentioned though, the agile scrum, hopefully you're doing some form of this within your business or within your projects, because if you're not, your retrospectives are probably not going to be fairly clean or are going to be maybe a little conflicted or confusing, because if you're doing agile and scrum and you're doing your daily standups, you're doing your bi-weekly, you know, retros, you should be able to correct course at any time during the project and things should be moving along in a positive way. That doesn't mean you're going to not go off the rails at some point, you know, and the retrospectives, coming back at the end of a project and doing a retrospective, this is the time to really cut the bullshit and put everything on the table. You know, be honest, be brutally honest. This is one of those times where you create a safe space where, hey, everyone, let's throw it all at the wall. What was the worst thing? You know, what possibly went wrong? Did go wrong? You know, throw it out there. Create a space, but give everybody a nerf bat. Or a scrunchie ball. But do it in a way, make it fun. You know, this is going to be a very contentious thing that you do, because some people may have built up frustrations or pent up, you know, aggression towards some things they did not like to happen during the project. You see this with any software company. I mean, there's almost no project I have worked on where you get to the end and everyone is all roses and unicorns and rainbows. I never see that. But there's always a good and a bad to any type of retrospective. Make it a game, but make sure you encourage the bad. You want as much negative feedback or what people did not like about the product. You want them to be open about it. You want them to spill their guts, so to speak, of everything that happened during the project from beginning to end. If you don't foster that, if you leave that app or you block that, or you block that, you are not going to grow as a company. Your next project is not going to be as good. You're going to repeat the same mistakes and you're not going to get better. Things are, you potentially could go down a path where your company self explodes because you are not learning or correcting course when you need to. That is to me what these retrospectives are. You do them to figure out, oh crap, okay, maybe this was my first project I get in. I think it was great. And then everyone tells me that crap. No, okay, I'm a bad leader or oh, we missed so many milestones or there's always an or let it come. Try to be, what's the right term? Try to be separated from the conversation when it is the negative part. Listen to it, absorb it, take it in. Don't get emotional. This is not the time to get emotional. You're at the end. You've made it. You finally cross that finish line. This is what can we do better? And the only way you can do better is to carve out all the problems that happen along the way that maybe you were aware of or maybe you weren't. And then what you do is you put them on a whiteboard. You put them on Post-it notes. You organize them in a way to say, here's the good, here's the bad. What can we do to improve and what should we do next time? And then you build the roadmap, you build the processes, and if you're doing agile correctly, you're already kind of in that cycle. So this should be fairly simple to do for the next project. However, if there are some critical missing pieces, you might have to take a pause or make some judgment calls if the problems with the project, with the retrospective, is not necessarily the project itself. Sometimes you have problems. It could be lack of talent, the wrong talent. You might need to adjust for your next project to ensure that you have the right people working on the project because you might have had the wrong group of people trying to get something across the board. You might have hired the wrong talent or misaligned the talent to the goals of the project, which can throw everything in chaos. It's like, oh, this person knows Java, but hey, this is a Python project. What the hell is he doing here? Yes, he can code, but is he the best talent for this project? Did he slow us down? I know I kind of went everywhere with that, Rob, but what's your response to that? I do want to bring up that it's one that you do want to have, you want to elicit feedback as much as possible. Just like we asked for an email where I don't care if it's good, bad, indifferent, you want the feedback because, granted, not all of it's going to be valuable, but you need all of it so you can sift through it and figure out what is valuable. One of the things that I want to make sure that you bring up is that when you do this, is a lot of times we'll get into a project and there will be a point where it's like, we're not going to worry about assessing the situation as much as we just need to move forward, need to fix this and move forward, and you're not really assessing it. Take note of those things and now is the time to go back and assess those. What went wrong? How do we do that? How do we avoid that in the future, assuming it's a bad thing? How do we go in and correct for that? Now, it may be a situation where this is a bit of a come to Jesus or a house cleaning or however you want to refer to it kind of moment where you say, you know what, this is, maybe this team needs to, you know, we need to get more people, we need, we're lacking a skill set or we have too many of a skill set or we have a wrong skill set. That's particularly from a project level. Those are some of the kinds of things that you can run into definitely. And I would say that one of the problems with retrospectives, particularly when you have a longer period of time, you know, if it's a three, six, 12 month project or something like that, there's a lot that's going to come out of your retrospective. So what you want to do when you're looking back, when you're doing this postmortem is have some action items going forward. It doesn't have to address everything. It'd be great if you can, but set yourself up for success and pick some reasonable number or reasonably achievable goals that come out of what your feedback during this, you know, this postmortem, during this retrospective is I wear now that I know this essentially now, what am I going to do? It says, so, so now what I know what went wrong. I know what went right. So now what do I do with this? And you should spend some time figuring out what is your plan? How are you going to adjust? How are you going to change your resources or your approach to resources or maybe it's your, you know, your costs, your expenses, your estimates. There's so many things that go into projects. Where are you going to focus to get better? And maybe, you know, with that, you're going to take some of the things that you're not going to change and you're going to say, maybe it's a one-off, maybe it only occurred this time. And instead of just forgetting about it, track that so that the next time you get through a project, let's go back and say, did we hit those again? So are the, is this a trend? Is this something that we do regularly? Or was it truly, you know, a one-off or something like that? So I think those are all key areas to look into when you're doing this retrospective is, is gather as much information as possible, make it as safe as possible for everybody there. And if you are getting sunshine and roses and unicorns and everybody's loving everything and it's awesome, dig deeper. There's got to be something in there that, you know, that, that isn't that good. There's got to be something that's wrong. And that's where a lot of, and if you, if you haven't done this, look at some of the recommendations for doing retrospectives at the end of a scrum and some of those kinds of things, there's tools out there that you can use because they are built to say, yeah, we've got some good things, but we want to make sure that we also list the bad because otherwise we're lying to ourselves and we're not getting the information we need. We're not getting the complete picture so that we can actually address it and improve. This also could include things like, you know, did we bring people in at the right time? Did we start testing at the right time? You know, did you have environments set up at the right time? You know, retrospectives can mean many things to many people, but these are all the things that really need to be discussed in a retrospective. Yeah. Timing is definitely going to be part of it. It's looking at saying like, maybe we did it, but we could have done it better had we done it sooner or later or differently even. So there's a, there's a, maybe we didn't, we pushed too hard, put too many resources on this and we need it, you know, things like that. There are a lot of adjustments you can make and some are going to be small and some are going to be major, but what you want to do is have the information because you may do nothing with it because you're like, I'm just, I can't, but at least you have the information and so at least you've got something going forward and even if you don't explicitly do something, which you should, if you don't, at least it'll be in the back of your mind and hopefully you can make adjustments moving forward. As always, this is where we do, you know, our, I guess, podcast episode retrospective of tell us how we were doing. We can tell ourselves all kinds of stuff, but we want an email from you, info at development.org.com. We would love to hear from you or any of the feedback mechanisms through that is whether it's through YouTube, whether it is through the podcast, whatever device you're using to listen to podcasts, you can reach us on development.org.com. We have a contact us form. We're happy to hear from you there. You can send us something to at development or on X. You can reach out to us on our development or face page, Facebook page or face page, whatever you want to call it. I'm old. I combine those things. That's okay. Any of those areas, we would love to hear from you as always, like I say, if you're listening to this and you're not watching it, feel free to check us out on YouTube, the development or channel. If for some reason you just want to listen to us, we have a podcast wherever you want to listen to it. So you don't have to listen to the YouTube thing, but then you're going to be missing out on the bonus material that we do provide basically every show, whether before or after. That being said, I got to throw a challenge out to you. And that is to look at wherever you're at in a project. If you're whatever you did last, take a look at that. It may be quite a while back and spend this like a mini retrospective, just take like 15, 20 minutes. What are some good and some bad things out of it? And the reason I want you to do this is one, maybe some things you can adjust right now so you can help your current project. But two, maybe when you look back at that and you're going, I have no idea what was going on. It will be a clue or a nudge for you to do a little more documentation of some sort, do something while you're going through this project so that you do have a roadmap, milestones, some sort of paper trail that when you get to the end, you can do a retrospective on this project. That being said, we will wrap this one up, go out there. We just got a couple more episodes left and we will wrap up the season. But for right now, it's just this episode. So go out there and have yourself a great day, great week, and we will talk to you. Thank you for listening to Building Better Developers, the Develop-a-Nor podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.