3 New Years Resolution Ideas for Scrum Teams

I know what you’re thinking. It’s almost the new year and that means it’s almost the beginning of a new 365 day sprint in your life. We often think of New Years Resolutions for our personal lives, but what about at work? Along with setting those goals for yourself for the new year, why not also resolve to help take your Scrum team to the next level?

Scrum New Years Resolution #1 – Ditch the 3 Questions

If you haven’t checked the 2020 edition of the Scrum Guide, let me clue you in on something that was omitted from it. No longer does the Scrum Guide call for the “Three Questions” (What did you do yesterday? What did you do today? What, if anything, is blocking your work?) – at the Daily Scrum.

Scientists say that it only takes a few of these Daily Scrums where the “Three Questions” are used to die of abject boredom. Don’t fact check me on that – I’m right. Instead, for a New Years Resolution, try treating your Daily Scrum as a true daily planning session. Formulate a plan as a team. Figure out how the team is going to work together today. For Jeff Sutherland’s sake, don’t make it a status report meeting. Save the Monday Morning Quarterbacking for Retro. Focus on how you’re going to make progress toward the Sprint Goal as a team, and how you’re going to solve the problems that stand in your way today. This is an easy win for a Scrum New Years Resolution.

Scrum New Years Resolution #2 – Swarm, Swarm, Swarm

When developers work together on a backlog item, this is typically called Swarming or peer programming. Many Scrum teams which are in the forming stage tend to like to pull backlog items as individuals and work them apart from the team. This is a dangerous move and Scrum Teams should be careful about when they do this.

A high functioning team is one that works together to solve problems. Sure, in theory, each developer could work on a user story by themself and the team could get a lot of work done in a short amount of time. The reward there is seemingly obvious: the amount of work a team puts out could be higher than that of a team that peer programs. But when you weigh this against the risks of doing it that way, you see why doing this is such a bad idea. First, you create towers of knowledge (sometimes called silos). Developers keep taking the same type of stories because they’re good at them or they’re most comfortable doing them, or because no one else wants to do them. Then, invariably they leave the company or get swallowed whole by a once extinct megalodon while surfing in Bali and the next thing you know, all of that knowledge is lost.

Even if that extreme scenario doesn’t happen, you’re still easily going to run into WIP limit issues when a developer runs into a roadblock and is afraid to ask for help or when the other developers are too busy working on their own stories to context switch and assist. Context switching is expensive. Stay on task. Consider making swarming as a team your Scrum New Years Resolution.

Scrum New Years Resolution #3 – Liven up your Sprint Review

Has your Scrum team’s Sprint Review boiled down to a quick, lifeless “demo” of the team’s work? Don’t worry – you’re not alone. Let’s take a quick look at what the Scrum Guide says the Sprint Review should be:

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

Engage your audience. The Sprint Review is a wonderful opportunity for the team and the Product Owner to not only explain the progress made during the sprint, but also begin the conversation with the stakeholders with what’s on deck next. If the Product Owner is keeping a good eye on the Product Backlog and roadmaps, then they can easily speak to the next steps that the team currently has lined up. The stakeholders can then add their input at that time, and the conversation can help shape what the team will work on next. Having just a demo of the work is a quick way for the stakeholders to just stop showing up.

Make it a Year of Improvement

Whatever you decide to do, keep one thing in mind. Scrum is not about making grand gestures and loudly proclaiming to the world that you’re going to solve all the problems at once. Scrum is about incremental improvements – working together to find new ways to become a highly functioning team. Figure out where your Scrum isn’t working and fix it. Breath new life into your ceremonies by making them less cookie-cutter status meetings or demos, and make them a genuine conversation between all involved parties as to how you are collectively going to solve the problems that you face right now. Make it your New Years Resolution to unrelentingly improve yourself and your team.

Good things come to those who challenge themselves to be better.