Yesterday’s post (Scrum Does Not Take Control Away From Developers) made me consider another reason why some software developers simply don’t like Scrum. I think it comes down to too much reporting.
Doing Scrum properly requires daily stand-ups to share information. The team congregates for 15 minutes and quickly synchronizes — at least that’s what should happen. Too often the stand-up turns into a status meeting. You know the drill — Let’s go around the room and have everyone report on their tasks.
When that happens, everyone feels the pressure. There will always be someone who is good at spin. That person will ramble on about all the tasks he completed and all the issues he resolved. This pressures everyone else to offer the same kind of monologue to avoid looking bad in front of the group (and their manager who is often in attendance).
These stand-up sessions give Scrum a bad reputation. The stand-up is NOT a status meeting. If management wants a status meeting, management should schedule a status meeting. The Scrum Master and the Product Owner can report for the entire team.
The daily Scrum stand-up must be tightly focused.
- What have you “done” since the last stand-up? – Share with the team what you completed since yesterday’s stand-up. This is simply to let everyone know what artifacts are ready for others to use. If nothing you worked on met the team’s “done” criteria, fine, say so and move on.
- What will be “done” before the next stand-up? – Again, just let everyone know what’s coming. If you don’t expect anything to meet “done” criteria before the next stand-up, say so. (No one should care about all the detailed activities you spent time on. They expect you to work hard.)
- Did you encounter problems or issues not previously discussed? – Finally, simply let everyone know about problems and issues that they may encounter and should be aware of. (If you had to take your dog to the vet and lost some time, that’s your personal problem. The team doesn’t need to know. Deal with it.)
The last question may generate considerable discussion. Team members will often jump into problem solving mode as they try to help. The Scrum Master needs to squelch this. A quick suggestion or an offer to assist after the stand-up is fine. A detailed discussion of the issue is not.
A common occurrence is for a software developer to realize that a story will take much longer to implement than planned. The story may have been under-estimated or new information may have been uncovered. Either way, this is not a topic of discussion for the daily stand-up. Take it offline and either return the story to the backlog, divide it into multiple stories, or finish it at the expense of one or more other stories for this sprint.
Scrum stand-ups are designed to promote teamwork. If yours aren’t doing that, stop. Your team has a serious problem. Conduct an immediate retrospective focused on the daily stand-ups. This can’t wait. Do it now.