Status meetings are boring. More importantly, status meetings are unneeded. Meetings are for discussion, and updates on status rarely require that (until, of course, they do). Nothing – nothing is more painful than sitting through a meeting where people go around the table and say, “Today, I’m doing X”.
Hopefully nothing alarming so far.
A lot of teams have adopted Scrum for project management. One of the rituals of Scrum is the daily stand-up where traditionally, 3 questions are asked:
1) What did you do yesterday?
2) What are you doing today?
3) What is blocking you?
And a lot of times during the stand-up meeting, most people say something like, “Yesterday, I worked on the fizz filter. Today, I’m working on the fizz filter. Nothing is blocking me.”
And then the next day at stand-up, they say, “Yesterday, I worked on the fizz filter. Today, I’m working on the fizz filter. Nothing is blocking me.”
Eventually, since the answers to questions 1 and 3 never change, standup information is “optimized” to something like this:
“Today, I’m working on the fizz filter.”
…and this repeats until they’re (eventually) done with the fizz filter.
Something is wrong, right?
Somewhere in the rituals of scrum or agile, teams who operate like this lost the importance of communication and collaboration – they go through the motions of “agile”, but fail to get the immense value that’s easily within their grasp.
If you’re tied to the canonical three questions of scrum, then at the very least you owe it to your team to improve the way in which you communicate your status. Discuss details; include something you learned (maybe you were blocked, but figured it out); think about how other team members may be able to help you. You can also make a big dent in the scrum-as-status-reporting problem if you break your work items into things that can generally be done in a day or less.
“Yesterday, I worked on the database connection for the fizz filter. I had a challenge getting the ODBC connection set up, but Janet gave me some tips and I got the problem solved. Today, I’m going to write a test suite for the fizz filter database connection. I may need some help learning the new test runner, but other than that, I should be good to go”
If you want to go further, Brent Jensen taught me a question that I now use to drive any project management meeting I’m in. This came up while discussion managing a team using kanban (which I believe, when used correctly, far exceeds scrum as a project management framework), have task owners answer one question:
“What needs to be done to move this task to the next column?“
The question is automatically contextualized by the kanban column containing the task. Answering the question reveals questions, dependencies…and even status.
The question from Brent is wonderful, but the the main point here is that your status messages (barf) or status meetings (double-barf) aren’t helpful for you, your team, your software – and ultimately, your customers. The great news is that it’s easy to do better.
What needs to be done to move this task to the next column for your team?
You’ve described the Scrum Zombie. Henrik Kniberg has an amusing image of that here https://blog.crisp.se/2010/09/01/henrikkniberg/1283373060000
http://blog.crisp.se/henrikkniberg/images/ScrumZombie.png
Also “What needs to be done to move this task to the right?“ is a very Kanban way of looking at a project. Scrum uses the three question to enable accountability, visibility, and collaboration.. whic is good. Kanban likes these too, but focuses on the flow of the system. In Scrum we go person to person at standup. In Kanban we start on the right (output) side of the board and then work our way leftward
The whole point of scrum is to make sure that the team communicates when they need to. If you want the team to juggle while they sing their status backward then you’re behaving like manager and should realize that scrum is about the team and not about you. Your scenario might be a team that’s communicating what they need to with one another already and phoning it in at scrum for the PHB. Instead of “fixing” scrum, consider a sprint with no scrum and see how the team compares the two experiences in retro.
The only problem you’ve shown us with the team is that if every day the status is the same that means they should have smaller tasks. The misdiagnosis of “kanban’s the solution” might reach that goal.
Totally agree with what you’ve said, that we need to actually bring more value in our daily status. I have also observed that sometimes people might be annoyed by the daily standup meeting. Few months ago, we have tried on a project to not bringing the team together, but using a chat (Skype chat in our case) to give the daily standup. Have described this here https://blog.testing-land.com/how-not-having-a-daily-stand-up-meeting-can-work/.