Simon Baker's latest blog entry reminded me of something I've been thinking during some of my consulting gigs with organizations that are adopting Scrum but are relatively new to it.
To get directly to the point, I've got beef with the part of Simon's posting where he describes the three questions answered by every team member on the Scrum meeting:
Each team member answers 3 questions
In turn, each team member answers the following 3 questions:
- What have you done since yesterday's meeting?
- What are you going to get done today?
- What obstacles do you need to be removed?
It's not that there would be errors as such or that I would add a question. Nothing like that. Simon does a great job describing the Scrum meeting as it is described everywhere on the net and in the literature.
My beef is with the wording used everywhere on the net and in the literature.
You see, what I've found is that people are used to reporting progress to the project manager. (Can you believe that! We do something for a few decades and suddenly it's difficult to get out of the habit?) All sarcasm aside, I think the way we talk about "answering three questions" contributes to the difficulty of getting people away from reporting progress to the Scrum Master (who almost unanimously is the same guy who used to be the project manager before adopting Scrum).
"Three questions" is probably the easiest way to communicate what you're supposed to do. After all, you're asking yourself--and answering--three questions. The downside is that it doesn't seem to be the most effective way of communicating what you're supposed to do. Apparently words like "answer" and "question" tend to be associated with ideas closer to being interrogated rather than communicating information.
I can't help but think that some of the teams I've met on my journeys would've had an easier time if the whole three questions thing would've been represented using slightly different words. We all know what happened with Royce's waterfall paper. People scanned through the article, saw the waterfall picture, and failed to read the rest of the paper where Mr. Royce explained that the model described by the pretty picture would only work for the most trivial of problems. I'm afraid the same has happened in many places with Scrum's three questions--people take the bullet list and fail to pick up the why and to whom.
After all this whining, I guess it is only fair for me to make at least some kind of an attempt at improving upon the status quo. Behold, my suggestion for a replacement description of Scrum's three questions:
Each team member updates his peers:
In turn, each team member provides his peers with 3 pieces of information:
- Things I have done since yesterday's meeting
- Things I am going to get done today
- Obstacles that I need someone to remove
What do you think? Am I making a nothing into a something? Should I tell Ken to correct this horrible mistake with a new edition of the Scrum bible? Could you care less?