Meaningless Improvements

Let’s suppose the Scrum master facilitates an interactive session with the whole team in attendance, and team members respond with some ideas for how they can get better. Here’s what they came up with:

• Have more fun
• Go to lunch once a week
• Write better code
• Estimate with more accuracy
• Collaborate

Are these actionable improvements? Will this team really get better if they choose to implement one or two of these items in the next sprint? The items are awfully vague and they don’t make for concrete improvements. It’s great that the entire Scrum team attended the sprint retrospective and that team members are generating ideas about how to improve—but now it’s time to delve into the team’s problems to find root causes and measurable goals and objectives for the next sprint.

The retrospective is about examining people, relationships, and technical practices that are inhibiting the team. Let’s review the items that the team came up with, and add some follow-up questions you might ask to dig a little deeper into the problems:

• Have more fun
  • Is someone killing all the fun?
  • What’s preventing this team from thinking work is fun?
  • When’s the last time the team was shown appreciation during a sprint retrospective?
• Go to lunch once a week
  • Is everybody getting along?
  • What are we going to solve by going to lunch?
  • Are we not communicating well enough?
• Write better code
  • What’s our definition of quality?
  • Are we writing bad code?
  • Is the architecture still appropriate given what we know now?
  • Should we revisit our definition of done?
• Estimate with more accuracy
  • Why are we estimating?
  • What did we estimate incorrectly?
  • Did our bad estimate set unrealistic expectations?
  • Are there impediments or bad practices that impact our ability to estimate?
• Collaborate
  • Are we helping each other?
  • What happened between the development team and product owner?
  • Are we missing opportunities to work together?
  • Are we appropriately refining the product backlog?

Empty improvements are the easy way to get out of a retrospective quickly, but they invoke no real improvements. The team has to dig deep into relationships and/or technical issues in order to reach its maximum potential. The retrospective should be as serious and professional a meeting as the sprint review. It’s the time to bring up issues and attempt to find resolutions.

As a Scrum master, you’ll need to flex your facilitation muscles and discover what questions lead to the right conversations to help reveal the deeper issues. Keep digging—your teams need you.