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.
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.
User Comments
From the perspective of a SCRUM Master, the purpose of the stand-up is to get a handle on impediments so they can be removed or worked around. While there may be truth to peer pressure of non-performance, public shaming is not the purpose. As a matter of fact, I think the whole focus on blame is contrary to the roots of Agile.
From the perspective of a SCRUM Master, the purpose of the stand-up is to get a handle on impediments so they can be removed or worked around. While there may be truth to peer pressure of non-performance, public shaming is not the purpose. As a matter of fact, I think the whole focus on blame is contrary to the roots of Agile.
Good topic, Adam.
Thanks Margaret for the thoughful comment,
I agree that the blame and shame is antithetical to any healthy working environment, agile or otherwise. I do think it's good to talk about impediments but putting that discussion into a tightly managed ritual (I've seen many scrum masters cut people off mid-sentence because there was risk of overrunning the "15 minute rule" sadly many scrum masters seem to percieve their role as enforcer of the legalistic framework. I think it's good to coordinate in the morning, but it's better to solve problems when they arise (rather than wait till standup) and to make work visible. As Jim Benson says "The problem with the 3 questions in standup is that it means we don't know the answers to them continually."
:-)
Again, thanks so much for the comment.
Great article, Adam. Have you read: "the Lean Startup", by Eric Ries? It talks about building learning into what you build. And so - if someone reported on what they learned yesterday, would actually be valued.
Thanks Mara,
Yes, I've read Eric's little blue book. I think it's good for helping people understand that product management should involve customers but would love for people to read it and use the information as a springboard to learn more about actual lean principles. Sadly too many people are dropping the word "startup" from Eric's meme and much confusion about what lean means ensues.
I know Liz KEogh uses "What did I learn yesterday, What do I hope to learn today... etc" instead but I feel like that approach risks making a meaningless semantic change to the ritual and risks the same rote ritualism. That said, I've seen standups be really effective, just love for people to think outside the framework and adapt approaches to their context.
Super important to understand the nature of knowledge work when applying approaches and frameworks to our efforts. Anything that causes dialog and critical thinking is fine by me. :)
Thanks again for the nice comment. :-)
Excellent article Adam. I'm a big fan of Reinertsen 's book on Product Flow. I use Rally, which has a couple of Cumulative Flow diagrams. I'd like to see a follow up article with details on measuring flow and interpreting a flow diagram.
We did away with the daily standups in favor of a twice weekly show and tell. The sole purpose of Agile is to be, well, more agile and reduce waste and overhead. Adding all this excessive process especially with Scrum is exactly the opposite. We switched more to a Kanban approach, but focus on what needs to get done rather than adhere to the process by the book.
What we still have to figure out is how to act upon the issues identified as roadblocks in the meetings. And the reasons for not being "productive" can be numerous and are at times out of our control. The biggest hurdle is often the business itself, unwilling to make decisions and instead claiming that "we hit it next iteration". Agile works well when the entire business is agile and does not abuse the backlog as a tool for indecision.
Collaboration at the base level is excellent and we all know that we make mistakes that throw the wrench into someone else's work at times. But we know that it is better if we fail than the customers.