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.
If your stand-ups involve long diatribes or last longer that 15 minutes, you need a new 4crum .aster.
Best definition of “how to do a stand-up” that I’ve seen! Run this way, the team will feel more pressure to have something “done” every day – which will also translate into better task breakdowns. Together, that will pull testing forward, as there will be a better flow of discrete bits of work that can be verified.
Also – instead of the 3rd question mostly getting a pass, with nothing done and perhaps nothing anticipated to be done today, either, this is where you can hear more real sharing, i.e. doing X is taking longer than I anticipated, since the way Y is structure is not what I anticipated. Whether that is followed by a request for input (after the mtg) or not, whoever on the team structured Y will be more likely prodded into saying something like, “I can go over that with you after the stand-up”
Comments are closed.