We’re bored with the board!
Written by Brian Ganas
I’m about to anger some Scrum Masters.
Your morning Scrum is a sacred event — a gathering of the majority of the team to connect, discuss difficulties, and ask for help when needed. And yet every day the Scrum seems to have a cloud hanging over it.
Stop “walking the board.” Stop screen sharing. Stop going ticket by ticket. Stop it all.
The practice I have observed too often is teams using technology to lead their daily Scrum. We pull up the Kanban board and we review each ticket that has the audacity to remain in the “In Progress” column. The years since Covid protocols began have forced a lot of businesses to adopt remote solutions and this has only exacerbated this problem.
Now please believe me: I understand why we do it. Product Owners are rarely able to give us as much time as we require, so the Scrum becomes an easy opportunity to report progress to them. Tickets often require clarification or justification for why something might be taking longer than normal. Discussing each ticket one by one gives us a chance to resolve specific questions. But using the board as the Scrum’s agenda introduces significantly more problems than it solves.
Stop before you fall into the same traps every team has
Now it’s just a verbal status report
Reviewing each ticket generates the bad practice of allowing the daily Scrum to act as a status report. Instead of answering key questions about their upcoming work, team members feel compelled to deliver a health report on their tickets, one by one. “When will it be done?” “Why isn’t it done?” “What are you doing to fix it?” It’s natural to either ask these questions or preemptively answer them when we allow the morning Scrum to function as a status report. It’s hazardous to use the Scrum as a chance for the team to connect to their PO and/or SM, and not as a chance for them to connect with each other.
Disengagement and predictability
Moving through the Kanban board can only be done in so many ways. Patterns develop, and it quickly becomes obvious when your name is going to be called out. Naturally, people start zoning out or multitasking until their name is called. Attention begins to waver, getting worse every day, and eventually, opportunities are missed for team members to jump in and help others.
Cementing the false idea that Product Owners and ScrumMasters are managers
Status reports are typically delivered from subordinate to manager. Why would the Scrum be any different if we continue to allow it to function as a status report? Reporting on work ticket by ticket simply reinforces the (false) idea that Product Owners and ScrumMasters are managers, who are owed a thorough, deadline-focused report on the tickets they see on the board.
The reign of the mundane
Simply put, navigating the board ticket by ticket is boring. Instead of actively engaging in real conversation, we report status, get through our information as quickly as possible, and breathe a sigh of relief when we are dismissed and the focus moves to the next team member. It’s boring. It’s repetitive.
Try something else. I personally have tried the following with some success:
- Asking for a daily update along with some ridiculous question that forces absurd discussion (e.g. if you were a squirrel, what type of tree would you try to nest in?). I’ve had great success with this. Not only does it keep the content of each Scrum fresh, it also organically injects creativity into a frequently routine meeting. It generates conversation and, more often than not, a lot of fun and humor.
- Prompting people in a random order every day so there is no predictability. This feels like kind of a sneaky, shady technique when I use it, but it works. When people don’t know when you’re going to call on them, it naturally forces everyone to engage and pay more attention. No one wants to get called on when they aren’t paying attention. Use at your discretion.
- Refusing to screen share unless we have an actual visual element like a wireframe to look at. Visual screen shares act as a crutch in almost all meetings. Following an extremely detailed agenda or a PowerPoint often shows that the meeting could have been an email. I avoided this pattern by ignoring visual guides when we have the daily Scrum and instead focusing only on what truly matters: the team connecting with each other through their voices.
- Telling the product owner they may only speak if directly asked a question. It’s very easy for the product owner to fall into the role of “manager” (and often micromanager) during the daily Scrum, so actively removing their frequent interaction is very helpful. Your goal is not to shut down communication, but to help your product owner remember that the team is the focus of the meeting. Remind them, sometimes harshly, that they are there to provide guidance when necessary, but the team really should be leading the discussion themselves.
All I ask is that you try something different, something new and fresh. Try and remember what the point of the daily Scrum is supposed to be for, and don’t let it become something different. It serves a purpose when it is executed as designed. If not, it just becomes another meeting people have to attend.
Because I know you are dying to know: I would nest in an oak tree. This is primarily based on how delightful and rich-sounding the word “oak” is when spoken aloud.