Glenn Waters gave a great session at Agile Ottawa a few days ago, it was a combination of conversation, workshop and talk. As part of the session we identified many ways standups breakdown.
So what did we find going wrong:
- Not held daily
- Boring – no commitment or engagement
- No perceived value
- Too much talking and chit chat (socializing, wandering off topic)
- Not adhering to the 15 minute rule
- Being late and not showing up
- Directed, i.e. one person taking over and telling team members what to do.
- Reporting Directly to a manager vs. sharing with the team.
- Not reporting to the team
- Mumble, mumble disease, i.e. team member not saying anything that the rest of the team can understand.
- Trivia report – reporting in so much detail that no one understands or cares.
- Repetition – someone saying that they worked on one story several days running.
- Not raising impediments
- Not prepared
- Problem solving
So how do we make things better? Let’s start by checking in with the Scrum Guide (by Ken Schwaber and Jeff Sutherland):
Each Team meets daily for a 15-minute inspect and adapt meeting called the Daily Scrum. The Daily Scrum is at the same time and same place throughout the Sprints. During the meeting, each Team member explains:
1. What he or she has accomplished since the last meeting;
2. What he or she is going to do before the next meeting; and
3. What obstacles are in his or her way.
There are a lot of problems here and they have many different root causes. In one blog post I can’t possibly make suggestions on how to solve them all, instead here are just a few examples:
- When sharing I ask team members to walk up to the story board and touch the story they worked on to help make it clear what they’re talking about.
- If see repeated problems like chit-chat, mumble mumble, ill preparedness, etc. I work with the team member offline to be better prepared for the meeting.
- When someone is repeatedly late for the meeting, I ask them offline if there is a problem with the time etc, only if other attempts to solve the problem fail to I resort to a penalty (i.e. financial: a looney in the team beer fund; social: becoming the keeper of the late badge).
- If team members start problem solving I remind them to take it offline and meet again after the scrum
- Reporting to Manager – if individual coaching fails I will ask the manager to turn their back on the team for a few days, until team members remember the meeting is for their benefit and not just the managers.
What pathologies do you find? How do you solve them?
Update I forgot to mention other resources: Daily Standup Tips – a Roundup my own on InfoQ and Jason Yip’s famous: It’s Not Just Standing Up: Patterns of Daily Stand-up Meetings.
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
The one that bit me recently was this:
1. Perform standup meeting
2. Do work
3. Next day, perform standup. One or two developers are still working on the same task they said they were going to have done yesterday.
4. Repeat 2 & 3, fail iteration.
We would ask what the issues where and would get nebulous / hand-waving answers. The most likely reasons were screwing-the-pooch or technical incompetence. The reason it became an issue was they were either afraid to or unable to ask for help … it’s hard to ask for help when you don’t know where to start on a problem.
But, as a team of peers, there was no one who could call BS on the standup … the prj mgr was remote. Essentially the standup was a bust. We resolved it by pairing, which brought to light the technical gap. Sadly, that wasn’t something that was easily fixable in a timely fashion and we swapped team members.
Sandy – sounds painful, but the daily standup did the job. It gave you insight into the fact there was a problem. The real question in a case like this is how to deal with it. Like you I agree that pairing is good starting point.
Cheers
Mark
Good post. I wrote something similar here:
https://scrumcrazy.wordpress.com/2010/09/18/bad-smells-of-the-daily-scrum/
I’m working on a related one, “Bad Smells of the Sprint Backlog” too, but it maybe a while before that one is posted. Here is the outline so far:
https://scrumcrazy.wordpress.com/2010/10/07/bad-smells-of-the-sprint-backlog/
Man, you could write an entire book on patterns and anti-patterns of the Daily Scrum. It seems like it’s such a huge radiator of bad smells, which I’m sure is what the Scrum founders intended.