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?