Many people, myself included, say that sprints are the wrong metaphor for software development. When we think about the need to maintain a steady, sustainable pace, and the importance of avoiding burnout, the idea of the sprint can give us the wrong idea. But maybe it makes more sense if we think about how real sprints work, and about all of Scrum’s ceremonies, not just the cargo cult of the stand-up.
When Usain Bolt finishes a race, he doesn’t just start again straight away. He does his victory pose, smiles for the cameras, does some warming down, and has a few days rest. When it’s time for the next race, he spends time preparing himself, both mentally and physically, for the challenge ahead. He does everything he can to ensure that he’s in the best possible state before his next sprint starts, so that he’s able to function at maximum capacity to achieve a good result.
As software development teams, all too often we ignore the importance of these activities between sprints. In particular, the retrospective is frequently undervalued. It’s easy for managers to see the retrospective as a time-consuming navel-gazing session, where the team doesn’t deliver any business value or burn any story points. If the team is under pressure to deliver faster, it’s probably the first thing that gets cancelled.
In our software engineering team manifesto, we laid out some points for how a team should operate, including the idea that we “focus on the details, and on the bigger picture”. Maintaining a healthy balance between these two ways of seeing can be a challenge, and it’s one of the things that people often find difficult when moving from an individual contributor role to take on leadership responsibilities. As developers we’re used to getting deep down into the details of an issue, but as leaders, shaping the direction of a product, we need to take more of an overview. If you’re a technical lead it can be very difficult to switch between these two contexts, especially if you don’t take time to reflect. If the team is working flat-out, it’s easy to fall into the trap of focusing solely on the small details - things like burndown rates or technical implementation challenges - at the expense of considering the bigger picture of the project’s direction of travel. It’s important to schedule time for both modes of thinking, and retrospectives are an ideal opportunity for thinking about the bigger picture.
Another analogy sometimes used for software development is climbing a mountain. When you’re climbing uphill, you have to keep looking at your feet, watching out for uneven ground to make sure you don’t trip up. It’s only when you stop and look around that you get a chance to enjoy the view, and understand the whole point of the endeavour. If you keep plodding on without taking a break, it’s very easy to get disheartened.
That’s what retrospectives are for: a chance to take stock of where we are and how we got there. They offer a moment to pause, take a breath and think about where we’re going next, and whether we’re going the right way. They’re an important opportunity to celebrate what we’ve achieved, and recognise the hard work we’ve put in.
So let’s remember to take a break from time to time, appreciate our colleagues, understand our achievements and our challenges, and think about where we go from here.
