Sprint Retrospectives Eliminate the Toughest Bottlenecks
What is the purpose of a Sprint Retrospective?
One of the biggest problems with projects is that people always assume that when the product has been pushed out of the doors, the work is done. But with Scrum, an agile development method, there are still more steps to take in order to improve the fluidity of the next project.
Sprint retrospectives exist so that the employees can learn from the last Sprint. All of the important milestones and events during the last sprint are put onto a board, chronicling the Sprint. The most pressing bottleneck is then identified and resolved, making the next project that much better.
This sort of best practices process will keep your Scrum endeavors constantly meeting the required deadlines and parameters. For more information on Sprint Retrospectives, watch the video from OpenView Labs featuring Jeff Sutherland.
Jeff Sutherland: Now, the retrospective is an interesting meeting because people get together and they talk about, well, how did it go for the last sprint? The first thing they need to do is really recollect what happened. It’s hard for people to remember all the details of what’s happened in the last couple of weeks. So often they’ll have people maybe make a visual, maybe put things on sticky notes all the things that happened in the last few weeks, however long the sprint has. Then, given that picture, what did they like and what didn’t they like? The things they like, they want to keep, and the things they didn’t like, they want to figure out how to do differently.
Based on understanding that, the team will then come up with, okay, here’s
some process improvements we can make to make our sprint better. They’ll
talk about prioritizing those, because it turns out that tuning an
organization is very similar to tuning a computer. If your website is too
slow, you don’t want to try to fix everything at once. You want to identify
where in that software is there a bottleneck, where is the biggest
bottleneck, and you want to fix that first. When you fix it, the whole
system will change its dynamics. The next bottleneck is often where you
least expected it to be. So it turns out you only want to fix one thing at
a time. So the challenge for that retrospective is to figure out what is
the one thing that, if we fixed it, would have the biggest impact on making
this team go fast? Then commit to fix it.
So the whole point of the retrospective is identifying that one thing and
getting a commitment. If that thing is not identified and it’s not fixed
ideally before the next retrospective, then the retrospective has been a
complete waste of time. People will say, “Why are we doing this? Nothing is
So the retrospective is designed to fix the most important thing. When that
happens, the team will accelerate. They’ll start to go faster. The quality
of the product will go up. So the retrospective is critical to improving
performance of teams.
Improving processes, adding more documentation and holding a bunch of training sessions won’t scale a product-led engine—it’s org design that matters.