Put Agile Rituals to Work For You
A few years ago, I worked on a product with a small development team and we had the opportunity to take a more Agile approach than some of the other development teams. But we were all a bit new to some of the associated rituals, and so we didn’t know the benefits of them and how to effectively leverage them for our product. Things were not scheduled well enough in advance and it quickly turned chaotic.
Fast forward a couple years and I was working on a new product with a new team. This time Agile was more fully integrated into the company, and so we all had a better understanding of each ritual and the benefit it brought to the product development process. Rituals were scheduled well in advance for the duration of the effort, and it meant that each of us no longer had to think about the process. We could instead focus on collaborating together to build a great product.
5 important sprint rituals
The Agile approach does not specifically state that you must develop in sprints, with specific rituals. These are elements of Scrum that are commonly used to implement an Agile approach, as they support the principles of interaction, developing working software, and adapting to change. There are five rituals that can benefit your product development effort, without burdening you and your team with unnecessary processes.
1. The Daily Standup
This is a time for the entire team to come together, not for a status report, but to ensure the whole team is working together toward the goals of the sprint, and to start conversations that can lead to subsequent interactions between team members after the standup is over. Find a time that works for everyone, be respectful of each other and be on time, and keep your turn to about 1 minute.
Benefit: The team feels like a team, and makes interacting with each other natural.
2. Sprint Planning
At the start of each sprint the team reviews the backlog and, based upon the velocity in the prior sprint(s), determines how many stories can be completed in the sprint. If your sprints are 2 weeks long, then this meeting is set up every other week, typically in place of the standup for the first day of the sprint. Stories are selected based upon size and as they relate to the theme of the current sprint. Team members can then further refine the stories with sub-tasks, but this does not have to be done during the meeting.
Benefit: Much like a lesson plan in school, a sprint theme provides a coherent, shared goal for the team.
3. Backlog Grooming
In order to support the sprint planning, stories in the backlog need to be sized so that the correct amount can be added to the next sprint. This is probably the one meeting that will cause the most push-back, as it takes time away from the development. But to minimize the impact, schedule this meeting before the mid-way point of the sprint, and time box it to 1 hour. If needed, additional meetings can be scheduled on subsequent days.
Benefit: Grooming provides another point for the team to respond to change, and make adjustments to the stories based upon changing needs.
4. Sprint Reviews
Agile development values working software, and so at the end of each sprint (usually late in the day on the last day) the team comes together to review the software that was built during the sprint. This is not only an opportunity to gather feedback on the software, but a chance for some user acceptance testing by having a non-developer run through a (short) demo script for the functionality. And don’t get caught up with defending or discussing the feedback, or thinking that you’re committing to future work; just capture the feedback as-is.
Benefit: If you know you have to demo working software, user stories don’t become large and fewer defects are deferred to subsequent sprints.
After the sprint has completed, and while it’s still fresh in everyone’s mind, get the team together to review what went well in the sprint, what didn’t go well, and what can be changed and improved going forward. This meeting should not be anonymous, as this can degrade the quality of the comments. This is constructive criticism, and the team is here to support each other.
Benefit: Identifying specific action items take this from a warm-fuzzy exercise to concrete improvements for the team and the product.
Set them up and don’t worry about them again
As I said above, we used each one of these rituals on the new product that we developed, and the difference was immense. What had felt a little disjointed and chaotic was replaced with order, while at the same time not constraining us. The rituals we used, and the underlying process involved with them, meant that we could function more efficiently as a team.
One key is to set these meetings up at the start of a project, rather than adding them in over time. There might not be much to demo on the first sprint, and the first few standups may go quickly. But starting these from the beginning lets the team develop a cadence so that the project flows naturally from the start.