One of the most prevalent misconceptions about Scrum stand-up meetings is the purpose. People think they are intended to convey status.

They aren’t.

According to the most recent edition of the Scrum Guide, the daily scrum’s purpose is “. . . for the Development Team to synchronize activities and create a plan for the next 24 hours.”

The Scrum Guide contains many prescriptions, such as who may and may not attend the scrum. The ScrumMaster is responsible for policing that the rules contained in the guide are obeyed.

Once More, from the Beginning
A classic Scrum standup has each person in the group take a turn answering these three questions: What did I do yesterday? What will I do today? Are there any impediments preventing my progress?

If I were to show this to somebody who never heard of agile before and asked him what he guessed the purpose of a meeting like this was, I’d expect him to say “status.” So we’ve replaced weekly status meetings (which were bad, right?) by reporting on a daily basis what we’re doing. That seems ludicrous to me. 

When I converted from status meetings to stand-ups, it was at the same low-trust organization where I worked for nearly eight years. I had started using “number of layoffs survived” as a measure for individual success. My number was seven, so I must’ve been very valuable indeed! I tell this story to set the stage for the general level of trust.

Without any explanation, teams of fifteen to twenty people were now required to go into a conference room every day and answer the three questions. They were told this meeting should be short, so it would only be booked for the prescribed fifteen minutes. 

Absent of safety, I suspect many people going to the meeting reinterpreted the questions, so in their heads, the questions sounded like this: Were you productive yesterday? Will you be productive today? If you are not productive, do you have any excuses?

Naturally, nobody felt comfortable being brief; people were terrified and tried to justify their existence when interrogated by the engineering director who ran the meeting. I was no better; I was trying desperately to survive my coming eighth layoff.

Do you have any excuses for not having been productive? was the least appealing question of the three.

The likelihood anybody was going to admit to not being productive and offer up an excuse was extremely remote—especially when everyone was trying to survive the next layoff so their families didn’t starve in the post-dot-com bust wasteland we were assured awaited us on the outside.

After thirty minutes, the next team of fifteen to twenty was standing outside, noses pressed against the glass, wondering why our meeting was still going. 

Fast Forward to 2013
I recently suggested that I was not a fan of the three questions to another consultant, who had clearly never heard anybody speak ill of a trusted agile tradition.

“I love the three questions!” he insisted.

So I explained to him my concern that they do not encourage agency and gave examples. He then surprised me by saying, “Right, but there’s value in the social shame of making people who aren’t pulling their weight expose themselves on a daily basis.”

This statement, while profoundly upsetting, was one I’d heard before and since on numerous occasions. The notion that people behaving badly is an issue that we must design systems around seems destructive. I suggested that I’d rather design transparent systems that made visible the likely systemic impediments than try to shame people.

Shaming people does not encourage them to collaborate or take risks. After all, if I’m learning something it might impede my output, and I don’t want to admit that my inexperience led to my learning on company time instead of producing something to check my box at stand-up the following day. I’m definitely not going to help someone else check his box if it means I have to report, “Yesterday I didn’t produce anything because I was teaching someone things that help him be more effective.”

That consultant went on to ask, “But if I don’t hear it at stand-up, how will I know we’re on track?” I suggested that we create visible systems that let anybody see progress at a glance. He countered with, “But if I’m expecting something to be finished in ten days, I need to know if it’s not going to be delivered before the ninth day.”

I see this as a batch size problem. If your delivery increments are ten days each, you face that risk whether or not someone personally reports status to you on a daily basis. If you have ten increments of one day each, or twenty increments of half a day, you can easily see the trending data in a cumulative flow diagram. You also ideally reduce variability in each of those increments, prioritizing the highest risk increments to reduce chances of late discovery during that delivery cycle.

Using metrics such as cumulative flow to monitor throughput and quantitative thinking may not seem very humanistic, but by depersonalizing the work being done, we can focus our energies on solving actual problems instead of conducting a daily witch-hunt and shaming people into high performance.