![]() 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”. If the team is under pressure to deliver faster, it’s probably the first thing that gets cancelled. 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. In particular, the retrospective is frequently undervalued. 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.Īs software development teams, all too often we ignore the importance of these activities between sprints. When it’s time for the next race, he spends time preparing himself, both mentally and physically, for the challenge ahead. He does his victory pose, smiles for the cameras, does some warming down, and has a few days rest. When Usain Bolt finishes a race, he doesn’t just start again straight away. 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 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. Many people, myself included, say that sprints are the wrong metaphor for software development. This article was originally posted on the Capgemini Engineering blog ![]() The bigger picture and the smaller details
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |