What Happens When Your Team Doesn’t Show Up?

“Success doesn’t motivate me as much as integrity does. Everyone loses. I enjoy the pressure of showing up every single day, being focused, putting forth my best effort, getting the best out of my teammates, and enjoying the journey.”

– Becky Sauerbrunn

A while ago I was doing some research on how to deal with absentee members of a Scrum team. At the time, I was helping a new Scrum team deal with absenteeism issues. Team members were missing at every Scrum event during every Sprint.

Sound familiar?

So, I looked for patterns that other Agile practitioners had used. My search led me to a couple of good articles:

More recently, I and a few other Agile practitioner colleagues had opportunities to again reflect on this challenge of Scrum Event Absenteeism along with its cousin, Scrum Event Cancellation.

The learnings I gleaned from the two articles as well as from The Scrum Guide itself continued to serve me well during these latest incursions on the sanctity of Scrum.
Here were my key takeaways.

Key Takeaways

Where’s the problem?
Does the problem lie with the absentee team member? Or with the team that wants to cancel a Scrum event? Perhaps the problem starts with the Scrum Master not effectively teaching the value of the Scrum events. Scrum events provide a rhythm for the team. In the words of Paddy Corry from the first article, “Without those (events), we lose the beating heart of most Scrum teams”. Scrum events are opportunities for empiricism to thrive. Empiricism embodied in Scrum by its three pillars of Transparency, Inspection and Adaptation. Here’s the question that Corry would ask Scrum Masters: “Do you think your team understands the value of the opportunities for empiricism provided by each of the Events?”

See Scrum Events as opportunities not meetings.
Opportunities for not only empiricism but also for team and personal growth. According to the Scrum Guide, “Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.” The events are for the primary benefit of the team. They do not exist to primarily benefit others. One team recently wanted to cancel their Sprint Review because they didn’t believe they had anything to demo to stakeholders. What they didn’t understand was that the purpose of the Sprint Review is much more than just the demo. It’s also an opportunity to share learnings from the Sprint. Not only for themselves but also to solicit support from their stakeholders if needed.

Scrum Events are not mandatory.
Corry describes the implications of making events mandatory by using the language of BDD:

Given a scrum master in a Scrum Team, when I insist that the Scrum Events have mandatory attendance, then I risk creating an environment of command-and-control, and the team will start to value attendance over participation, and presence over empiricism.”

Corry goes on to suggest that all Scrum events are invitations and “they can be declined.

Based on my personal experience, I would encourage teams new to Scrum to give all the events a chance before starting to experiment with attendance. Otherwise, they won’t know what they don’t know. Encouragement through teaching rather than insistence.

If the need to opt-out exists, Corry suggests the team develops “opt-out protocols” or team agreements on how to deal with absenteeism. An example to opt-out of the Daily Scrum event could include two opt-out protocols.

  1. Before the Daily Scrum” which would include agreements on what the team would do before missing the Daily Scrum such as letting someone know.
  2. After the Daily Scrum” which would include agreements on what the team member would do upon returning to the team such as checking in with another team member on what happened during the event.

I recently suggested the following opt-out protocol for a leadership Scrum team.

  • Start with Trust. Trust that the rest of the team is doing what’s best for the team and its stakeholders.
  • Meet face-to-face. Upon returning, meet in person with another team member regarding any work items you wish to find out more about.
  • Visit the board. To learn more about work items in general.

The Daily Scrum is for the Development Team.
It’s an opportunity for development team members to coordinate their Sprint backlog work towards achievement of the Sprint goal. The Scrum Master and Product Owner do not need to be present. In fact, I know of one Scrum Master who would always answer their team members question about whether or not the Daily Scrum was happening with a question: “I don’t know. Do you have any work to coordinate?

Deal with absenteeism issues respectfully and transparently.
You’ve done a good job of teaching the value of holding Scrum events. The team demonstrates their understanding by showing up on time and without reminders. They’ve agreed to abide by a set of opt-out protocols. They’ve even continued to hold Daily Scrums when you don’t show up. Yet, there may be times when some or all of the Scrum events suffer from absenteeism or cancellation. When that happens, here’s what Jesus Mendez suggests in the second article, for Scrum Masters.

  • “Validate your perceptions with the team and once confirmed by the team, use facts to confront the person individually in an exploratory one-to-one conversation, where you would share what you have observed in the field and how that’s impacting the team’s progress.”
  • “If one-to-one doesn’t work, then be courageous and bring the point up for discussion at the next iteration retrospective, and invite the team to share how the lack of participation is impacting team’s progression.”

Here’s to keeping the Scrum beat alive…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s