Detailed Notes
In this episode of the Building Better Developers podcast, Rob Broadhead and Michael Meloche explore the power of retrospectives in business. Learn how to reflect on past projects, identify wins and challenges, and make actionable improvements for future success.
💬 Topics covered: • What is a retrospective? • Why retrospectives are vital for agile teams • How to run a retrospective in any business • Lessons learned and challenges faced • Creating a culture of honest feedback
📌 Episode Challenge: Take 15–20 minutes and conduct your own mini-retrospective!
🎧 Subscribe for more episodes: [your website or podcast link] 📬 Contact us: [email protected] 🌐 Visit: https://develpreneur.com/ 🐦 Follow us on: * https://facebook.com/Develpreneur * https://x.com/develpreneur * https://www.linkedin.com/company/develpreneur/ 🔔 Don’t forget to like, comment, and subscribe!
#retrospectives #businessgrowth #agileprojectmanagement #postmortem #buildingbetterbusinesses
Transcript Text
[Music] I kind of an idea for next season. Okay, let's ask AI. Oh, we could do that would be fun. is just each uh each episode we just go out to like a chat GPT and say what would be a cool Yep. episode. Let me I'm gonna do that real quick. I'm gonna see if it gives us anything even halfway useful. Let's see if I But but I mean but I mean because we've been doing like the build building for three seasons and I kind of want to do something a little more fun and I think that would just be fun. That would be interesting. Let's see if it'll come up. It could be off the rails like totally off the rails. But let's see what would be a good but we could even do it in such a way is let oh I know what the season could be. let's ask AI and we come up with like we start out with like a general topic for AI and we like just start asking and then we discuss its results or are interesting is just going let's see okay great episode topic for the developer podcast should align with its core audience developers entrepreneurs and techminded professionals looking to grow in both business and technical skills here's a strong topic idea uh let's see episode topic from side project to startup turning code into cash. See, uh, subtopics to explore. How to validate a side project idea. When to start charging users, real examples of successful bootstrap developer products, tools for solo developers to handle marketing support and growth. Mistakes to avoid when trying to turn a project into a business. Would you like an additional episode topics or a content outline for this one? All right. So, yeah, it basically is the stuff that we've already done. But I do sort of like it would be fun to do a have like a conversation, do our episode, kick the the stuff back into it, and then ask a question and then see where we can go. We could play around with that. That would actually be pretty fun. So, all right. We all right. I I just And go ahead. Continue. Yeah. I thought that would be a good idea for next season is we Let's ask AI. We come up with kind of a general idea. We ask AI and we kind of build off of the conversation like what does it come back with? What are our thoughts on it? Things like that. I think that could be really fun because we could take like news of the week or something like that and throw a couple of things into it and just say like, okay, what would be a great thing to talk about and then we'll figure it out and maybe we'll throw like randomness into it or something like that to make it a little bit crazy and do you Yeah, because we can do some of that. we can like give it a different personality or something like that and then just say, "All right, let's see where that goes." So, and in between that, we could do the interviews like we've talked about. Yeah, I think that would be that would not be a bad one if we can fit in a couple interviews and that would be a good combo. All right, this episode though, uh, project retro. Yeah, project retro retrospective for a project. Let's see how this one turns out with a three, a two. Well, hello and welcome back. We are the building better developers podcast, also known as developer. This season is building better businesses. I am Rob Broadhead, one of the founders of developer, 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 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 assess assessment to turn it into a project technology kind of roadmap and then we can either help them go ahead and execute on that road map or we will walk side by side and partner with them to execute as well. Good thing bad thing. Uh, good thing I had an interesting thing a couple weeks ago. I don't remember if I actually mentioned this on the podcast at all. I play hockey and uh I got run through a couple many this a few weeks ago had a lot of good stuff that have there 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 was 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 fact, they came back and they suspended him. So that was a good thing. It's like, 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 the blind guys they know as that people know as refs got one right. Bad thing. This is bad for a lot of people. Uh 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 uh properties are growing in value on a very regular basis, they've decided to pull this little like slight of 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. Uh, for example, the house I just sold, I was looking at it, it basically added about 50% on top of its prior value and uh, while they may drop the, you know, 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. It's one of those, it's I guess it's 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 Malash. I'm one of the co-founders of Building Better Developers, also known as Developer. 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 uh requirements document so you can actually build what you need or go buy what you need for your business. Good thing, bad thing? Uh well, good thing. Um let's see. Uh well, there's been a few things recently. Uh I've actually completed quite a few uh projects recently that I've kind of been blocked on a little bit. So, it's kind of a good bad. Uh and with that, I 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, 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. Uh I 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 you know give a little more definition and background essentially what you do is you look at what happened in the previous you know 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. That 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 post-mortem that is done on it. Now, if you're doing it as a 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's where we went right, here's where we went wrong, here's what we're doing better, things like that. But we should be doing this in a regular on a regular basis. almost I don't know 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 you know if you're taking months to go through it and this is even if you are a soloreneur 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's a lot of them then maybe you know every second or third project but on a regular like you know a 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 uh 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 you know 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 uh 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 you know some sort milestones or something like that. That is a documentation of your journey. How long did How long did we think this was going to take? How long did it take? What was involved? What And looking back, it may have to require you to like 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, you know, 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, you know, 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 begun 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 road map 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. Uh 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 uh updates that you gave your customer over time or whoever the you know the the product owners or the stakeholders are. It's going back through that so you can remind yourself, you know, 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 the fallout that occurred from some of those things, some of those uh decisions and actions. Now you can say you can judge them a little better. Was that good? Was that was that something that was avoidable that we really need to avoid in the future? Was that something that's like, h, it wasn't that big a deal. We panicked, but now that we know how to do it, it's not going to be a problem in the future. Um, and there's there's so many ways you can go with it. So, it really is taking the path that you took, looking at the the markers, whatever they happen to be. It may be milestones, but it may be points where there was a a really good week or a really good day, 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? That is a 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 some starting points because everyone is of course unique in it 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 you're already your retrospectives are probably not going to be fairly clean or are going to be maybe a little conflicted or confusing. Um because if you're doing agile and scrum and you're doing your daily uh standups, you're doing your uh 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. Um, and the retrospectives, coming back at the end of a project and doing a retrospective, this is the time to really put cut the 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 what possibly went wrong did go wrong? You know, throw it out there. Safe space, but give everybody a Nerf bat or a scrunchie ball or something. But do it in a way make it fun. You know, this is going to be a very contentious thing that you do. Uh because some people may have built up frustrations or pent up, you know, aggression towards some things they did not like that happened during the project. You see this with any software company. I mean, there there's almost no project I have worked on where you get to the end and everyone it's all roses and uh unicorns and rainbows. Um I I never say that, right? 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 out or you block that, you are not going to grow as a company. You are 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-exlodes 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 to I think it was great and then everyone tells me that crap, nope. Um, okay, I'm a bad leader. or oh we missed so many milestones or there's always an ore. Let it come. Try to be what's the right term? Try to be um 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 crossed 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 happened 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 road map, 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 misalign 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. Uh what the hell is he doing here? You know yes he can code but is he the best talent for this project? Did he slow us down? So, I know I kind of went everywhere with that, Rob, but um what are your what's your response to that? I do want to bring up that it's one that you do want to have um you want to elicit feedback as much as possible. Just like when we ask for, you know, an email where like I don't care if it's good, bad, indifferent. You want the feedback because and 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. Uh, one of the things I want to make sure that you bring up is that uh, when you do this is a lot of times we'll get into a project and there'll be 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 and correct for that? Now, it may be a situation where this is a 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. Um that's particularly from a project level. Those are some of the kinds of things that you can 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 3, six, 12 monthth 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 post-mortem, is have some action items going forward. 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 uh achievable goals that come out of what your feedback during this you know this postmortem during this retrospective is where now that I know this essentially now what am I going to do? It's 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. 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 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 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 uh 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 uh you know did we bring people in at the right time did we start testing at the right time you know did you have environment 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 a is definitely going to be part of it. I was looking at I say like maybe we did it but we could have done it better had we done it sooner or later or you differently even. Uh so there's a there's a maybe we didn't you know we pushed too hard put too many resources on this than we needed 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. [email protected]. 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 podcast. You can reach us on developer.com. We have a contact us form. We're happy to hear from you there. You can send us something to develop onx. You can reach out to us on our developer face page, uh, Facebook page or face page, whatever you want to call it. I'm old. I combine those things. That's okay. Um, any of those areas, we would love to hear from you. Uh, 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 developing channel. If for some reason you just want to listen to us, we are 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, uh I got to throw a challenge out to you, and that is to look at wherever you're at in a in a project. Um if you're whatever you did last, take a look at that. You know, 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 there's 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 road map, milestone, 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 this 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 next time. Bonus material. So the biggest thing with these retrospectives is you have to create that safe space. You definitely have to make sure that you have an environment where people are open and able to communicate what went well, what went wrong with the project. Because if you don't, you're never going to grow. you're just gonna always hear, hey, you're always on track and you're you could potentially run into that wall because you're not changing course and then your business collapses. So, make sure you take the time to do these retrospectives. You get the feedback you need. And it's not just feedback from your own people. Talk to your customers. Get feedback from your customers. We didn't really touch on that in the episode, but you know, your customers are the greatest source of feedback. How did you do? You know, give them a safe space. Hey, hey, be blunt. Be honest. You know, what did you think of the project? How did we do? You know, were there things we could do to correct? And listen. And then I if you get that negative feedback, make sure you do take the time to listen to it, digest it, and hopefully change course and make things better for the next time. I'll throw a little different twist on this for the bonus material is uh one of the things that is worth looking at uh actually particularly from a project project level um that you're probably not going to spend as much time on and really analyze even if you're doing sprints is what is still on your backlog when you get to the end of your project. What are the things that you thought at some point you needed to do and then somewhere along the way they weren't needed? Um they got duplicated, they you know got pushed because they weren't that important. Whatever it is because those things in themselves there is definitely lessons to be learned there is like where did we bite off more than we can chew? Did we end up having to scramble at the end? Did we estimate things wrong? Were we a victim of time frames and deadlines and things like that? And particularly in those, are there things that you really wish you if you could have done it again that you would get those things done? Because that may help you prioritize the next time around. Uh it may help you, you know, say, you know what, we're not even going to bother with the next time because we know we're not going to get there. It's really not that important. Why are we wasting time thinking about it at all? But it may be something which is the more bigger concern is there is something that we didn't get to we really wish we had and so we're going to find a way to work that in to adjust our priorities or whatever we need to do to make sure that that does get covered the next time around. Just like every single episode there are certain things that we say we do we ask for and occasionally we're like we get to the end and we don't even cover those. But this time, I think we got them all in the podcast part of it. So, we're not going to waste your time anymore. We are going to run off into the sunset of some sort. Uh, and however, we will be back because there's always another day where we will come back. We will do another couple episodes as we're wrapping this one up. Uh, let us know any suggestions, recommendations you have for future topics. U if if you want to be interviewed, let us know because we are going to be opening back up to interviews as we move forward. uh we threatened to do it this season and then we just never really had anybody step up and get into our very busy schedules. Hopefully, we'll have more bandwidth moving forward. As always, we appreciate your time. We appreciate your attention and all that you have done for us. Love to hear from you, good, bad, or indifferent. We'd love to, you know, give you a little kudos and stuff like that. A shout out if you'd like that as well. As always, go out there and have yourself a good one and we will talk to you next time. [Music]
Transcript Segments
[Music]
I kind of an idea for next season. Okay,
let's ask AI.
Oh, we could do
that would be fun. is just each uh each
episode we just go out to like a chat
GPT and say what would be a cool Yep.
episode. Let me I'm gonna do that real
quick. I'm gonna see if it gives us
anything even halfway useful. Let's see
if I But but I mean but I mean because
we've been doing like the build building
for three seasons and I kind of want to
do something a little more fun and I
think that would just be fun. That would
be interesting. Let's see if it'll come
up. It could be off the rails like
totally off the rails. But let's see
what would be
a good
but we could even do it in such a way is
let oh I know what the season could be.
let's ask
AI and we come up with like we start out
with like a general topic for AI and we
like just start asking and then we
discuss its results or are interesting
is just
going let's see okay great episode topic
for the developer podcast should align
with its core audience developers
entrepreneurs and techminded
professionals looking to grow in both
business and technical skills here's a
strong topic idea uh let's see episode
topic from side project to startup
turning code into
cash. See, uh, subtopics to explore. How
to validate a side project idea. When to
start charging users, real examples of
successful bootstrap developer products,
tools for solo developers to handle
marketing support and growth. Mistakes
to avoid when trying to turn a project
into a business. Would you like an
additional episode topics or a content
outline for this one? All right. So,
yeah, it basically is the stuff that
we've already done. But I do sort of
like it would be fun to do
a have like a conversation, do our
episode, kick the the stuff back into
it, and then ask a question and then see
where we can go. We could play around
with that. That would actually be pretty
fun. So, all right.
We all right. I I just
And go ahead. Continue. Yeah. I thought
that would be a good idea for next
season is we Let's ask AI. We come up
with kind of a general idea. We ask AI
and we kind of build off of the
conversation like what does it come back
with? What are our thoughts on it?
Things like that. I think that could be
really fun because we could take like
news of the week or something like that
and throw a couple of things into it and
just say like, okay, what would be a
great thing to talk about and then we'll
figure it out and maybe we'll throw like
randomness into it or something like
that to make it a little bit crazy and
do you Yeah, because we can do some of
that. we can like give it a different
personality or something like that and
then just say, "All right, let's see
where that goes." So, and in between
that, we could do the interviews like
we've talked about. Yeah, I think that
would be that would not be a bad one if
we can fit in a couple interviews and
that would be a good combo. All right,
this episode though, uh, project retro.
Yeah, project retro retrospective for a
project. Let's see how this one turns
out with a three, a two.
Well, hello and welcome back. We are the
building better developers podcast, also
known as developer. This season is
building better businesses. I am Rob
Broadhead, one of the founders of
developer, 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 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 assess
assessment to turn it into a project
technology kind of roadmap and then we
can either help them go ahead and
execute on that road map or we will walk
side by side and partner with them to
execute as well. Good thing bad
thing. Uh, good thing I had an
interesting thing a couple weeks ago. I
don't remember if I actually mentioned
this on the podcast at all. I play
hockey and uh I got run through a couple
many this a few weeks ago had a lot of
good stuff that have there 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 was
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 fact, they came
back and they suspended him. So that was
a good thing. It's like, 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 the blind guys they know as that
people know as refs got one right. Bad
thing. This is bad for a lot of people.
Uh 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
uh properties are growing in value on a
very regular basis, they've decided to
pull this little like slight of 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. Uh, for
example, the house I just sold, I was
looking at it, it basically added about
50% on top of its prior value and uh,
while they may drop the, you know, 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. It's one of those, it's I guess
it's 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
Malash. I'm one of the co-founders of
Building Better Developers, also known
as Developer. 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
uh requirements document so you can
actually build what you need or go buy
what you need for your
business. Good thing, bad thing? Uh
well, good thing.
Um let's see. Uh
well, there's been a few things
recently. Uh I've actually completed
quite a few uh projects recently that
I've kind of been blocked on a little
bit. So, it's kind of a good bad. Uh and
with that, I 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, 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. Uh I 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 you know give a
little more definition and background
essentially what you do is you look at
what happened in the previous you know
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. That
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 post-mortem that is
done on it. Now, if you're doing it as a
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's where
we went right, here's where we went
wrong, here's what we're doing better,
things like
that. But we should be doing this in a
regular on a regular basis. almost I
don't know 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 you know if you're taking
months to go through it and this is even
if you are a soloreneur 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's a lot of
them then maybe you know every second or
third project but on a regular like you
know a 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 uh
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 you know 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 uh
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 you know some
sort milestones or something like that.
That is a documentation of your journey.
How long did How long did we think this
was going to take? How long did it take?
What was involved? What And looking
back, it may have to require you to like
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, you know, 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,
you know, 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 begun 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 road map 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. Uh 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 uh updates that you gave
your customer over time or whoever the
you know the the product owners or the
stakeholders are. It's going back
through that so you can remind yourself,
you know, 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 the fallout that
occurred from some of those things, some
of those uh decisions and actions. Now
you can say you can judge them a little
better. Was that good? Was that was that
something that was avoidable that we
really need to avoid in the future? Was
that something that's like, h, it wasn't
that big a deal. We panicked, but now
that we know how to do it, it's not
going to be a problem in the future. Um,
and there's there's so many ways you can
go with it. So, it really is
taking the path that you took, looking
at the the markers, whatever they happen
to be. It may be milestones, but it may
be points where there was a a really
good week or a really good day, 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? That is
a 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 some starting points because
everyone is of course unique in it 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
you're
already your retrospectives are probably
not going to be fairly clean or are
going to be maybe a little conflicted or
confusing. Um because if you're doing
agile and scrum and you're doing your
daily uh standups, you're doing your uh
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.
Um, and the
retrospectives, coming back at the end
of a project and doing a
retrospective, this is the time to
really put cut the 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 what possibly went wrong did go
wrong? You know, throw it out there.
Safe space, but give everybody a Nerf
bat
or a scrunchie ball or something.
But do it in a way make it fun. You
know, this is going to be a very
contentious thing that you do. Uh
because some people may have built up
frustrations or pent up, you know,
aggression towards some things they did
not like that happened during the
project. You see this with any software
company. I mean, there there's almost no
project I have worked on where you get
to the end and everyone it's all roses
and uh unicorns and rainbows. Um I I
never say that, right?
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 out
or you block
that, you are not going to grow as a
company. You are 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-exlodes 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 to I think
it was great and then everyone tells me
that crap, nope. Um, okay, I'm a bad
leader. or oh we missed so many
milestones or there's always an
ore. Let it come. Try to
be what's the right term? Try to be um
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 crossed 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 happened 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 road map,
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 misalign
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. Uh what
the hell is he doing here? You know yes
he can code but is he the best talent
for this project? Did he slow us down?
So, I know I kind of went everywhere
with that, Rob, but um what are your
what's your response to that? I do want
to bring up that it's one that you do
want to have um you want to elicit
feedback as much as possible. Just like
when we ask for, you know, an email
where like I don't care if it's good,
bad, indifferent. You want the feedback
because and 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. Uh, one of
the things I want to make sure that you
bring up is that uh, when you do this is
a lot of times we'll get into a project
and there'll be 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 and correct for
that? Now, it may be a situation where
this is a 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. Um
that's particularly from a project
level. Those are some of the kinds of
things that you can 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 3,
six, 12 monthth 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 post-mortem, is
have some action items going forward.
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
uh achievable goals that come out of
what your feedback during this you know
this postmortem during this
retrospective is where now that I know
this essentially now what am I going to
do? It's 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.
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 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 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 uh 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 uh
you know did we bring people in at the
right time did we start testing at the
right time you know did you have
environment 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 a is definitely going to
be part of it. I was looking at I say
like maybe we did it but we could have
done it better had we done it sooner or
later or you differently even. Uh so
there's a there's a maybe we didn't you
know we pushed too hard put too many
resources on this than we needed 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.
[email protected]. 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 podcast. You can
reach us on developer.com. We have a
contact us form. We're happy to hear
from you there. You can send us
something to develop onx. You can reach
out to us on our developer face page,
uh, Facebook page or face page, whatever
you want to call it. I'm old. I combine
those things. That's okay. Um, any of
those areas, we would love to hear from
you. Uh, 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 developing channel. If
for some reason you just want to listen
to us, we are 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, uh I got to
throw a challenge out to you, and that
is to look at wherever you're at in a in
a project. Um if you're whatever you did
last, take a look at that. You know, 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 there's 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 road
map, milestone, 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 this
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 next time. Bonus
material.
So the biggest thing with these
retrospectives
is you have to create that safe space.
You definitely have to make sure that
you have an environment where people are
open and able to communicate what went
well, what went wrong with the project.
Because if you don't, you're never going
to grow. you're just gonna always hear,
hey, you're always on track and you're
you could potentially run into that wall
because you're not changing course and
then your business collapses. So, make
sure you take the time to do these
retrospectives. You get the feedback you
need. And it's not just feedback from
your own people. Talk to your customers.
Get feedback from your customers. We
didn't really touch on that in the
episode, but you know, your customers
are the greatest source of feedback. How
did you do? You know, give them a safe
space. Hey, hey, be blunt. Be honest.
You know, what did you think of the
project? How did we do? You know, were
there things we could do to correct? And
listen. And then I if you get that
negative feedback, make sure you do take
the time to listen to it, digest it, and
hopefully change course and make things
better for the next time.
I'll throw a little different twist on
this for the bonus material is uh one of
the things that is worth looking at uh
actually particularly from a project
project level um that you're probably
not going to spend as much time on and
really analyze even if you're doing
sprints is what is still on your backlog
when you get to the end of your project.
What are the things that you thought at
some point you needed to do and then
somewhere along the way they weren't
needed? Um they got duplicated, they you
know got pushed because they weren't
that important. Whatever it is because
those things in themselves there is
definitely lessons to be learned there
is like where did we bite off more than
we can chew? Did we end up having to
scramble at the end? Did we estimate
things wrong? Were we a victim of time
frames and deadlines and things like
that? And particularly in those, are
there things that you really wish you if
you could have done it again that you
would get those things done? Because
that may help you prioritize the next
time around. Uh it may help you, you
know, say, you know what, we're not even
going to bother with the next time
because we know we're not going to get
there. It's really not that important.
Why are we wasting time thinking about
it at all? But it may be something which
is the more bigger concern is there is
something that we didn't get to we
really wish we had and so we're going to
find a way to work that in to adjust our
priorities or whatever we need to do to
make sure that that does get covered the
next time
around. Just like every single episode
there are certain things that we say we
do we ask for and occasionally we're
like we get to the end and we don't even
cover those. But this time, I think we
got them all in the podcast part of it.
So, we're not going to waste your time
anymore. We are going to run off into
the sunset of some sort. Uh, and
however, we will be back because there's
always another day where we will come
back. We will do another couple episodes
as we're wrapping this one up. Uh, let
us know any suggestions, recommendations
you have for future topics. U if if you
want to be interviewed, let us know
because we are going to be opening back
up to interviews as we move forward. uh
we threatened to do it this season and
then we just never really had anybody
step up and get into our very busy
schedules. Hopefully, we'll have more
bandwidth moving forward. As always, we
appreciate your time. We appreciate your
attention and all that you have done for
us. Love to hear from you, good, bad, or
indifferent. We'd love to, you know,
give you a little kudos and stuff like
that. A shout out if you'd like that as
well. As always, go out there and have
yourself a good one and we will talk to
you next time.
[Music]