Episode 49: Agile Practices: Sprint

Hello, and welcome to the bottom up skills podcast. I might pass since I'm the CEO of quality wins. And we add in a talk about sprinting, and we're going to be talking about the agile software development card, but it might actually feel like you're on a race track running around. And you're a little out of breath.

Uh, so the sprinter, this is, you know, usually it's a two to four week, uh, development dash in an agile project. I think you're most likely to see, you know, at least 10 to 12 sprints in a full project. Um, maybe more if the product is fairly significant in terms of scope and, uh, one of the things that.

Really kind of sets up scrum so well for anyone in business is that, [00:01:00] um, the scrum methodology within agile really time boxes, the sprint, it can be in other forms that there is not this time boxing, you know, Kanban is the one that comes to mind there, but really. The sprint and time boxing is essential.

If there's a huge focus on delivering a project at a particular deadline. And so. Usually, as I said, two to four weeks, uh, I quite like the two week version, uh, insight generally. And I get to the backend of projects. We will, uh, encourage our teams to actually push a release every week just to keep up the intensity of the sprint.

So I'm a big fan of the two week. I wouldn't, I wouldn't go for four, just there's too much time. Uh, for momentum loss. Uh, so I've got three, three ideas that I'm going to share with you about how to get the most out of doing a sprint. And, uh, I'm really looking forward to getting into this cause this [00:02:00] simple technique creates a ton of value.

It's sort of a hidden accelerator teams. So let's get into the world of the agile sprint. So we talked about in the previous episode, the idea of the backlog, if this is a tool that measures something, what it is applied to is traditionally a two week sprint. Now this fixed length really matters because it just means.

There's nothing like a good deadline to get us moving. And two weeks I've universally found for years is such a good basis for a sprint. And then in a sprint, you effectively agree as a team like, Hey, what are we going to deliver for the next two weeks? And then you go do it. And that's really at the heart of the sprint.

And this is where you start to see the use of the backlog that we discussed. In the previous [00:03:00] episode, they come together, the backlog and the sprint. They're very fundamental concepts in agile. We got two weeks, let's look at the backlog and work out what we should do. So you got this two week period. How do you get the most out of it and how should it be organized?

Well, I want you to imagine that if you looked at the two weeks and let's just say, we're starting on a Monday, that Monday should be about coming together and planning and the very final second Friday, the last Friday of the sprint should all be about. Reviewing what just happened and in between all of those other days, your sprinting, like crazy.

So let's talk about each of days and I'll want to give you a sense of just what I see time and time again, having worked on so many projects, there's the patterns are super, super clear. And you know, the funny thing, when we're going to start with planning, [00:04:00] The planning and the reviewing is the bit that so quickly gets abandoned, um, in teams that are not high performing, they're perceived as almost time-wasters, but they're so, so damn important.

So let's talk about planning. You want to plan your sprint? I would say. We talked about that the backlog brings you priorities. I think a key part of the sprint is to introduce a conversation about dependencies as well. If you're working on a software project, Invariably, you can have a couple of things going on.

Maybe you're working on an Android or an iOS version of the same application. Maybe you you've got some micro services, a web services or API APIs running. Through your architecture. And if that's the case, there's a really a high degree of attention that needs to be placed on this idea of dependencies, [00:05:00] because you need certain web services in order to create certain functionalities inside of the application.

And what happens where teams get lost is working on a priority. Without thinking about the dependencies. And so it's really important that when you do start planning your sprint, you need to work out the dependence you have on perhaps third party systems, or perhaps you need to build past a, before you can generate part B or part C of your product.

I see this quite often as well. And so the art to your planning is not only saying, Hey, what are we going to do this spring? But understanding the dependencies. Cause they tend to have the following effect. Oh, Joe blogs is in. Can I have part B ready until Friday, but we want to start on part C. But [00:06:00] we can't.

So what do we do now? And this is the famous West stuck because we're waiting for Joe blogs. So make sure if you do that good. Say planning exercise at the start of your sprint. It will just go so much better because you've taken the time to think about what's going to be happening down the track now.

We'll get to reviews in a second, but sprinting sprinting is just so damn important. Um, and I'm going to give you a build on best practice. You should be having a daily, standup, or a scrum, uh, where you ha having a short brief, and then quite literally. It is often best practice to, to in fact, be standing up if you're in a room together because it'll go a lot quicker.

Um, you do not in a standup or a scrum, want to list an inventory of everything that's on your mind. You want to limit your conversation to, am I on track? What am I planning to do? [00:07:00] And if you have a blocker, you should bring it up. And if you don't have a blocker, that's okay. It's good. If you don't have a blocker, but.

This should be the cornerstone of every single day of the sprint, the daily stand up. Now, if you're working on something that's tricky or one of your constraints, time, resources, or scope are under a lot of pressure. I strongly recommend that you guys get together at the end of the day, two, a three or four.

O'clock this double touch, uh, point, uh, can sand a little bit, uh, Heavy duty, like another meeting, but sometimes that alignment is needed and I have actually used that project. So it's essential. Don't skip your standups or your scrums. Sometimes you may need to incorporate end of the day checkings and really allows much time for deep work or collaboration [00:08:00] throughout the sprint.

And I think that the there's a point here that it's not just about working in silos and, uh, working on your stuff. The other thing here is you need to be working, uh, In work sessions in collaborative sessions, there's nothing better when a designer and a developer get together to work on a thing, there'll be much more aligned.

It'll create efficiencies down the track. All right. So we've done planning, we've done sprinting reviewing now. W we're going to talk a little bit about, um, you know, some of the, um, The things that we see in more detail at the back of the, uh, a sprint. Um, we're going to talk about retrospectives in a following episode.

So I don't want to get into too much detail here, but here's what I do want to say. When you view your work at the end of [00:09:00] a sprint as a team, It should be open and collaborative and not judgmental, but there's an important tip here. It should be discussing not only what you did. But you also need to discuss how you did it.

Interesting thing I learned on a current project is we had a whole re...