Democratizing Data through Interactive Self-Service Tools
Data can often go beyond just reporting by enabling others through interactive self-service tools. Additionally, these tools can improve the ...
October marks the 40th month that we have been practicing Scrum at HubSpot. Obviously we have learned a lot of lessons over that time. But one of the best things we have learned is how to do the basic things right. One example is the sprint retrospective meeting which at first was an awkward, confrontational, waste of time.
Here is the definition of the retrospective from Scrum Alliance:
The sprint retrospective meeting is held at the end of every sprint after the sprint review meeting. The team and ScrumMaster meet to discuss what went well and what to improve in the next sprint. The product owner does not attend this meeting.
The sprint retrospective should be time-boxed to three hours.
That description is nearly useless. And a time-box of three hours? Who has three hours for these meetings?
But sure enough, sprint after sprint, we found ourselves in a room asking everyone to reflect on the past sprint. It was an awkward meeting filled with questions like "How did you feel about the stories?" and "Why were your tasks not estimated accurately?" One team at HubSpot started to call this meeting the "Burrito of Tears" because it was not fun, and because they held it during lunch at the nearby Boca Grande.
Eventually the purpose of this meeting became clear: to shine some sunlight on the past sprint. We needed to get together and be totally open and honest. So we started to discuss why some things did not meet our expecations. Did we get slammed by bugs? Did we screw up in our initial tasking and miss an important part of the solution? What could we change so that we do not have this problem again?
The sprint retrospective can feel like a 5 Whys. When we identify something that is not perfect we dig down until we find a systematic issue. Usually it is something in the way that we practice Scrum, and we change it. Over time we got our practice finely tuned. There are still surprises but we learn from them.
The retrospective also helps us to identify the things that went well so we can try to repeat them in future sprints. Some positive things we have discovered:
- We were able to get more done by dividing into teams building/consuming an API.
- We had better testing by identifying the use cases upfront.
- We like having our standup right before lunchtime so we do not have to break our concentration twice.
Finding the things that went well is just as important to having succesful future sprints as preventing the things that did not go well. Not to mention, morale gets a nice boost when you end the retrospective discussing what went well for the team.
The retrospective is about the process more than the people. It does not have to be a confrontational blame-throwing meeting. It can be both enlightening and productive. And it does not take anywhere near three hours!
Have you found helpful ways to make Scrum work better for your team?
