“Beep. Beep. Beep.” A reminder dialog raises its head in the bottom left corner of your screen. Daily Scrum in 5 minutes.
Your shoulders tense in weary anticipation. It all sounded so good when you all started on the journey to become more agile. But now, a couple of sprints in, the luster of being agile has waned. The promise of self-organization hasn’t materialized. The horizon doesn’t even show a glimmer of it.
The daily scrums have become a pain and a bore. They aren’t anything like the descriptions you’ve read online from people talking enthusiastically about successful agile teams. Instead of showing interest in each other reporting to each other, everybody is just reporting to the Scrum Master. It feels awkward, ineffective. Not at all what you envisioned working in an agile team would look like. You can’t help but wish they’d go away.
But that’s unlikely. Other people still seem smitten and very happy with the changes so far.
What can you do?
Old habits die hard
Well, realize that just like Rome, agility isn’t built in a day. It takes time. Becoming agile requires people to change their behavior. Changing your ways is the hardest thing you’ll do as a human. You’ll try and perhaps succeed. Then you’ll fail because… life happened. Your parking space was taken, you bumped your head on something. Whatever it is, you’ll be less alert and will fall back into your old behavior. Then you succeed again. Then you fail again. As long as you persevere, and as long as you either notice yourself or are called out by others when you fall back, then over time the new behavior and thinking will take hold and eventually become a habit that is ingrained as the one you were trying to change.
Then realize that all the people on your team, including the scrum master and product owner are facing the same challenge. They may well be falling back into old habits without realizing it.
All fine and dandy, and those realizations may even make you feel better, but it still doesn’t help you in getting the people on your team to stop reporting to the scrum master and become more of a team instead of just a group of people thrown into the same boat.
Rescue by the scrum guide
Then, check the scrum guide again. Nowhere does it say that the scrum master should be running the daily scrum. In fact, all it says is that the scrum master needs to ensure that the daily scrum happens. The scrum master doesn’t even have to be present!
“But what about any impediments?” you ask. In this day and age? Really? Send an email. Put a sticky note on his/her desk. Whatever.
“But isn’t the scrum master supposed to make sure that everyone gets to speak and nobody is left out?” you ask. Nope. The daily scrum is for the people in the team, by the people in the team. Again, the only responsibility of the scrum master is to make sure it happens.
The daily scrum is for the people in the team, by the people in the team.
Anyone can run the show.
Everyone can run the show. Though that may get a bit chaotic.
Shuffle ‘m around
Something I have done to get away from the “reporting to the scrum master” syndrome, is to have a different person run the meeting every single day. At the end of every scrum, we shuffle our names and blindly (randomly for us nerds) pick one. That person is in charge of the show at the next scrum.
We also shuffle the order in which people speak during the daily scrum. Not having a predictable order helps in keeping people from drifting off until it’s their turn.
To shuffle the names of the people on your team, you can:
- put everybody’s name on piece of paper and draw blindly from a hat
- use an online tool like wheeldecide
Tip: At first glance wheeldecide seems to be able only to pick one name out of all the names entered. If you spin the wheel again, it may well come up with the same name – especially as you get further into the meeting. Have a look under the advanced options. There is an option to drop the selected name from the wheel. So the next time you spin, the people that have already had their turn, won’t be selected again.
But… will they go for it?
Not sure how to get your team to adopt this? Pitch it as an experiment. Something you try for a week. Or more. Reassure the people that are uncertain about it that you can all drop it again if it doesn’t work out. My bet is it will work out fine. The wheel or whatever method you decide to use, is a bit of fun for a meeting that is otherwise pretty predictable and maybe even a bit boring – certainly when everything is moving along swimmingly.
What have you tried to stop the “reporting to the scrum master” syndrome? Please let me know in the comments. Love to hear what others have come up with.
If you liked this post and would like to get more content like it, please subscribe to the newsletter using the form in the bottom right corner. As a subscriber you will get more content – including the inside scoop, links to reads I think you’ll find interesting and cheat sheets and other stuff I create as I am learning.
If the form isn’t showing, for example if you previously convinced it to disappear, just shoot me an email at email
Leave a Reply