Episode 51: 

Hello, and welcome to the bottom up schemes pass. I might pass it because I'm the CEO at QualityNet and we have got to the end of our agile software development series, and there is nothing more fitting than talking about a great scrum practice. It's cold. The retrospective. It's just a different way of saying let's reflect on what on earth we do just did in this sprint.

And the whole idea of doing a sprint retrospective is to make sure that the next sprint is just that bit better. So what we're going to do today is we're going to discuss. How to kind of celebrate wins within the team, discuss the losses and how we can use the retrospective as a way to create more [00:01:00] momentum.

For the following sprint. All right. So the spring retrospective, let's be honest about this thing. It is the first thing that gets canceled when everyone's too busy. And I know, I know it's easy to do and it's easy to justify, but it's so wrong. I mean, You need in an agile scrum project. I mean, man, do you need some time just to pause and say, okay, what did we learn?

I think the important thing is how can we do it better next time? And, um, this is really important because. If you do this at the end of the sprint, if you do a really good retrospective, actually doing the planning session for the next sprint becomes infinitely easier because you've already had a good chat about what happened and how you can do a better it's.

It's it's really, really important. [00:02:00] And, um, it's actually, even though you're formerly still in the old spring, you're already starting to commit to what you guys are going to do better in the next sprint. So this, just talk about this feeding into our agile software development series. And let's just talk about, um, the first and most important thing, and frankly, in a retrospective, as you would have in any type of project, you got to celebrate some wins, right?

You've got to celebrate some good work. Let's say someone did some work at a high quality, um, celebrate that. Call it out. Let's say somebody was able to deliver the work despite having to climb some sort of mountain. Maybe they were ill. Maybe they had to travel. Maybe they had to go over and support another project, whatever it is, celebrate the wins, because here's the interesting thing.

Um, let's say there's someone in our [00:03:00] team and they do something really admirable, make a really good contribution. And that's, for me, that's a win. We're all thinking to ourselves. Oh geez. It was really great that Joe blogs did that thing. Um, but the capacity to verbalize it, to actually say it is such a gesture of Goodwill.

It's such a great thing to bring a team together, to celebrate those wins, to celebrate not only what they did, but the effort that they put into it and, you know, Agile projects are not for the lighthearted. Um, they're pretty fast moving, pretty stressful. You gotta be at your best to get this thing done.

So celebrate your wins. But having said all of that, there's probably something that can contribute even more in celebrating your wins. And that's talking about the losses talking about stuff that didn't go right. [00:04:00] And you've got to create a safe, nonjudgmental environment in which this can happen. And I would always start by volunteering if you're a scrum master and you're running the session or whoever your role is within the team, always start by, Hey, I'm going to put my hand up.

I think I stuffed this. Um, and there's something important about leading. With humility and saying, I missed a thing. And I think you want to set the environment where everyone's accountable. Um, and everyone is safe to raise their hand and say, Hey, I want to do this better. I didn't do a good job. Now. The best teams, the best teams wait for this can be Frank about other people's.

Improvement areas. And this is delicate because, you know, Hey, we're all, we've all got egos, but [00:05:00] getting people in a safe cultural environment where they can say, you know what, Joe, I don't think that was the best. How can I help you do it better next time? That would be my advice to getting the most out of this situation.

So be Frank about the losses. And when we talk about wins and losses, I really want to come back to this idea I've mentioned before on the show. Don't just talk about what you did, talk about how you did it because there's good code, but then there's also things like good support. Good listening. Good communication.

High levels of trust. Those are the, how we do the code. And so you've really got to celebrate not only what you did, but how you did it. Now. Sometimes I see teams in an effort to be highly accountable. They set sort of really unrealistic goals for the next [00:06:00] sprint, my honest opinion here. And it's. It's not always what you want to hear when you're in a project that's not going great.

Is that you've got to set incremental goals. Don't set audacious goal from sprint to sprint because. Sprint's going well, uh, largely the result of good teamwork and good teamwork takes time. So when we think about retrospectives and setting goals for the next friend, I want you to go and ask yourself, okay.

If we could maybe only address one thing, let's just fix this one thing. Um, Hey, maybe you want your goal to be at number 150 now, or just say guys, that list, just get it to 60 for the next sprint. Don't go for the a hundred because I rarely see teams capable of that faster turnaround. It takes time.

Teamwork is incremental. There's trust, there's [00:07:00] communication, safety, accountability. There's a whole lot of good stuff in there, but if you're celebrating the wins and being Frank about the losses, um, Set some incremental goals set, set, a healthy stretch. Don't be crazy because you actually, one of the best ways you can get a team working well is confidence.

And you can build that confidence by them saying, Hey, you know what? Last sprint we did 50, this sprint, we did 60. Excellent more than a 10% improvement rock and roll. Let's keep it going. And I think that's the important thing because every sprint retrospective is immediately followed by a grooming session of planning session where you are actually re-prioritizing and setting the course for the next spring.

So there you have it. This is the retrospective, the very last part of the sprint. Um, the various essential thing at the end of one sprint that builds the connective tissue, the bridge [00:08:00] to the subsequent sprint. And if you can really get the right conversations, Going, if you can get people celebrating and being Frank, you will be amazed that over time you can really start to perform, uh, at a high level.

And this is essential because you're using something like the scrum methodology on your agile software project, and you're moving fast. But if you do all of the things, not only in the retrospective, but everything we've talked about. Organizing yourself, right. Having a real focus on working code and making sure that the team has a high degree of autonomy so they can move fast and really take ownership for the product.

You're going to have a great product, a business, a service, whatever you're trying to build. If you adopt this agile principle set and you use a methodology like scrum, it's gonna be electric. And if you really want to dig into it, you [00:09:00] can go over to bottom up.io where you'll find a full masterclass, not only on agile, but design thinking, rapid prototyping innovation.

We've got some cool case studies where we dig into all sorts of, um, successes, um, a couple of our losses as well from other companies to ask ourselves, what did they do and how might we do ...