People hate the daily stand-up.
I see posts all the time from frustrated developers asking that they just be left alone and not have to attend this time wasting meeting. Overall, the criticisms generally go like this:
- I collaborate with the team all the time so I always know what’s going on. They know what I’m doing. So, I shouldn’t have to go to the stand-up.
- Stand-ups aren’t held at a time that suits me. The whole team work different hours. It’s just not convenient.
- Stand-ups feel like reporting to my mother — “what were you doing”, “what are you going to do”, “I need help”. It’s degrading.
- My work doesn’t depend on other team members so stand-ups don’t serve any purpose for me.
When people feel this way they usually stop going to stand-ups and then they eventually find excuses not to go to the other Scrum events.
What is the Daily Scrum really for?
I’ve heard people suggest the event is to synchronise the team, support communication, report status to the Product Owner or Scrum Master, and to identify and escalate blockers to the Scrum Master. Yes the Daily Scrum supports collaboration, but the key thing people often miss is that its real purpose is to support empiricism – inspection and adaptation. Ultimately, it’s a planning event.
The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimises the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self organising team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.”
– Scrum Guide, 2017. Jeff Sutherland and Ken Schwaber.
Every event in Scrum, including the Daily Scrum, supports empiricism. If we miss out on the Daily Scrum, we miss a critical opportunity as a Development Team to:
- Inspect progress toward the Sprint Goal.
- Create a plan for the next 24 hours.
- Adapt the Sprint Backlog so that any update to the plan is transparent.
The Daily Scrum done virtually
- Screen share their virtual board.
- Talk briefly about the Sprint Goal.
- Examine the burndown and consider whether they’re on track.
- Set times for when they’ll pair up during the day to work together and collaborate via webcam.
Importantly, they always have their webcams on during the event. No one “dials it in”. As this is an opportunity to collaborate on the plan for the day, they know the Daily Scrum is an opportunity to engage face-to-face.
Mix up your questions at Daily Scrum
Many people use three questions during Daily Scrum:
- What did I work on yesterday?
- What am I doing today?
- Do I have any blockers?
It’s not a bad pattern, but it quickly turns the Daily Scrum into a status report. It also fails to encourage the essentials of the event – how are we tracking toward our Sprint Goal and what’s our plan as a team for the next 24 hours.
Rather than ask these three questions, try things like:
- Are we tracking as expected toward our Sprint Goal?
- How does our burndown chart say we’re going?
- Did anyone learn anything yesterday that means we have to change our plan of attack today?
- Has there been any feedback on work – form the Product Owner, stakeholders or users – that mean we need to adapt the plan for today?
- Does anyone need help with their work today?
- Is anyone waiting on something or someone?
- Is there anything we can show the Product Owner today?
- Have we found a problem that stops us from getting to the Sprint Goal? Can we solve the problem ourselves? Is something to escalate [to the Scrum Master]?
Are the right people attending Daily Scrum?
If you’re still finding it’s turning into a status report, don’t forget, the Daily Scrum is an event for the Development Team. The Product Owner doesn’t attend. The Scrum Master only ensures that the Daily Scrum occurs. Stakeholders don’t attend. Having transparency of the status of work is key, but don’t turn the Daily Scrum into a Q&A on the status of work.
If things aren’t working, it’s your job to fix things
When Scrum’s events don’t work for the Scrum Team – whether your a member of the Development Team, the Product Owner, or the Scrum Master – what do you do? Stop doing Scrum? Select the parts that you like? The trick is actually applying the inspect/adapt process of continuous improvement to the nature of the problem and ask “what can we do so that the stand-up works for everyone involved?”. One way Zen Ex Machina does this is by using ROTI.
ROTI — or “Return On Time Invested” — is a pattern that asks its participants to rate an activity from 1-5 once it’s been completed. The rating corresponds to the following:
| Rating | Description |
| 1 | Complete waste of time. I’d rather do something else like watch paint dry. |
| 2 | You should have left me at my desk to do my work. |
| 3 | The activity was OK. It was about as useful as if I was doing my day-to-day tasks. |
| 4 | This was more valuable than doing my usual work. I felt good about spending time on this. |
| 5 | Wow! Thank goodness I didn’t skip this activity. I learned a lot. I felt great about doing it. |
You can elicit the rating in a number of ways. Typically, when I’ve first introduced this tool to the group, I’ve asked everyone to write their score down on a post-it note. This assures the anonymity of the score and its comments. Usually, after the team has done this a few times, I’ve switched to a show of hands (the number of fingers showing corresponds to the rating). The focus, though, isn’t on the score of the activity, but what the individual feels would increase the rating by one point. This then becomes the focus of discussion at Retrospectives or for immediate action by the Scrum Master.
From here, I then use ROTI with my teams in the Retrospective itself. We collectively look at all the milestone activities in the Sprint just completed, from early Daily Scrums, early completion of User Stories, the mid-point of formal Backlog Refinement, and then late stand-ups, later User Story completions, and in Sprint Review.
We then write down our scores on post-its, use an arbitrary identifier (like a letter of the alphabet) to join all of the same post-its to a single identity, and draw a line between them. This visual shows the entire Scrum Team where they collectively feel that their time isn’t being well spent and then we collectively discuss what we can do as a team to improve things. I also get them to make the same suggestion for improvement on the post-it which I then review later — keeping the person’s anonymity safe from scrutiny is key. The Team need to feel safe that they can make any comments for improvement they like knowing I’ll then (as their Agile Coach) analyse the issue at hand and then go and have a private word with the Scrum Master and Product Owner.
Conclusions
Overall, I’ve found ROTI a key tool for helping the Scrum Team address Daily Scrum fatigue and stop people from abandoning their key events for empiricism. I’d definitely recommend the technique if you’re feeling like your Daily Scrum is a waste of time.
M
Enterprise Transparency through Agile for Executives
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
