How’s Your Daily Standup Working for You?

a daily scrum
needing the walls to stand!

I posted a response to a blog post entitled “Why I hate SCRUM daily standup meetings,” but it’s still awaiting moderation after a couple days. I’m impatient, so here’s my comment:

====== From: @jlangr ======

“On top of this, they need to setup a meeting to learn what my collegues are working on feels so wrong to me.”

Agreed. If you are a good team that already finds ways to get together and talk about what’s important, a formal meeting is a waste of time. Sitting in a common area where this can happen throughout the day can make it even less useful.

Having said that, it’s great starter discipline, and can be useful in environments where it’s not easy to get people together (I’ve been in places where I wasted way too much time trying to track people down or when my attempts to discuss things were rebuffed by people who were “too busy”). I’d start a new team on daily standups, but would push the team to find ways to eliminate the need for them once they got better at working together.

Also, most shops that run daily scrums and don’t get much out of them aren’t collaborating enough. It becomes one person reporting status, while the others worry about what they’re going to say when it’s their turn (because “that stuff” has little to do with what they’re doing). If that’s the case, you may as well revert to people sending an email with their status to the project manager, who gathers and emails a summary of what’s important to the team.

But…that’s not what works best in agile (or lean). See Stories and the Tedium of Daily Standups: What works best is real collaboration, which in turn makes the stand-ups far more useful and engaging. There’s also an Agile in a Flash card for that!

I’d love to hear more positive stories about stand-ups, given that most of the time I hear from people who’ve learned to detest them. Good or bad, how’s your stand-up meeting working for you?

Pigs, Chickens, and Asses

In Scrum, those “not accountable for deliverables” (emphasis added; see Jeff Sutherland’s article) do not get to talk during certain meetings. Pigs (product owners, ScrumMasters, and “the team”) are accountable for the success of the project. Everyone else is a chicken, because they’re not accountable for the project. Their opinions are distracting and thus damaging to the project.

Thus customers–people who ask for and pay for the product–are not part of the team, nor are the people who manage humans on the team. In Scrum, these people are absolutely not part of what we’re trying to accomplish, and they are to be silenced during parts of the development process.

Of course I understand why the rule exists. There’s always a loquacious manager or sponsor who wants to hear their own voice, or worse, insist that the team work “their” way. Understandably, we should want to minimize such distractions.

Unfortunately, the remedy goes too far, substituting command and control for the core agile value of communication. The rule is borne out of excessive personal bias: In the above-linked blog post, Sutherland says, “Whatever we call them it should have a negative connotation because they tend to sap productivity. They are really suckers or parasites that live off the work of others.”

Gee, how do you really feel?

Some distaste between management and development is normal, but this stance isn’t at all helpful. Knowing that deeply caustic bile is part of the foundation of pigs and chickens only affirms my belief that it’s a damaging practice.

XP embraces the wonderful value of courage. The simple XP solution would seem to be: Ask the disruptive people to stop. Talk about it. If you can’t figure out how to do that, you have more serious problems that a contrived rule is not going to solve.

People are not chickens. Calling them such is demeaning, even if you have a cute, cloying story to back up your attempts to control. A simple statement or two can make things clear: “This meeting is intended to help ensure continual progress on our commitments to delivery. Discussions around that are welcome, no matter who you are. Attempts to be a back-seat driver should be taken offline to our Scrum Master ™. We’ll let you know if you’re detracting from our goals.”

Ultimately, it should be obvious that any rule that silences a whole class of people is not in the spirit of agile. We should welcome contributions from those even remotely involved in our efforts. If they come at the wrong time, we can gently ask them to talk about it later. Sometimes the best ideas come from those who are not accountable.

This posting won’t keep people from insisting on the rule of pigs & chickens. That’s ok. The next time someone calls you a chicken, let them know that there is a new animal in agile. It’s the ass. The ass is the person who dictates how things must be. They are stubborn, controlling animals. Perhaps the best thing to do with an ass is to give it a good swift kick.


Jeff, I agree with you and applaud this article; however, I think we do need a Novice Rule to follow while we tend to the larger issue of “why does Tony insist on hijacking our Daily Scrum three times a week?” I think “Only these people may talk, and those other people must wait until the meeting is over to raise their concerns” constitutes a valuable Novice Rule for groups in disarray to try to follow when they start trying to put Daily Scrum to practice.

The “chickens” and “pigs” thing is just too often hurtful to be widely useful. The irony is that to get away with calling each other “chickens” and “pigs” generally requires a level of trust that groups use the Novice Rule to try to attain: trust that everyone will have a chance to speak, trust that everyone will honestly discuss how their work is going, that kind of thing. Calling each other “chickens” and “pigs” early on sours the development of that trust relationship.

I’m glad “chickens” and “pigs” works for some, but after I told that story twice and saw the looks on people’s faces, I stopped.

Thanks JB. Sounds good to me–learn and do rules for a while until you figure out when you can break them (and the implications of breaking them).

Jeff —

Just got referred to this post Kevin Schlabach, he left the note on the extremely similar themed message I blogged yesterday.

In summary, my post says (not literally of course) “I agree with you!”

The “ass” is a great, and appropriately lighthearted addition to the story. Love it.

Of course, I’m glad to have the opportunity to also see J.B.’s [as usual] insightful counter-point on the topic. And to think, the irony, I basically first learned XP from JB! 😉

While it is fair to say it might help in some ways, as a Novice Rule, the real punch-line of my entry is sorta the counter-counter-point that it injects too much of a largely irreversible negative “us vs them” undertone into the culture to be worth the possible benefits.

Anyway, just wanted to say great article!

ps// in case you’re interested, my posting.

Stories and the Tedium of Daily Standups

In “Tools, Iterations, and Stories,” I talked about how you should “focus on implementing and completing stories, not iterations. If your iteration is 10 days, and you have 10 stories of 1 point each, you should have delivered one story by the end of the first day, and two stories by the end of the second day, and so on.”

Today I helped deliver training on agile estimation and planning. One topic that arose was the daily stand up. We quickly surmised, no surprise, that this group’s experiences with daily standups were negative. We discussed some of the reasons why these meetings might be so poorly received. As typical, their standup meetings went on much longer than 5-10 minutes. Reasons? Also typical: people didn’t literally stand up, the meetings lacked focus, and people tried to use them to solve problems instead of just identify them. Most people, rightly so, viewed these meetings as very costly.

In response, we talked about why daily standups might be useful. We discussed the importance of getting the entire team to communicate more frequently. Daily should be a bare minimum!

The other part of our discussion was around what should be said during a standup. One of the complaints was that the standups were boring and tedious. The teams were using the typically recommended elements: what did I accomplish, what am I working on, what might I need help with? You know the drill.

Then it struck me: a focus on completing iterations, not stories, was part of the problem, contributing to the tedium.

The classic mistake in an initial stab at doing agile is to treat each iteration as a mini-waterfall. Spend a day discussing requirements, spend a day or two on design, code it, then test it, then integrate it. A team will open most of its stories on day one, and on the last day of the iteration, most of these same stories will still be open. The team will struggle to close them out prior to iteration end. The article I wrote (see link above) talks about a better approach: initiate work on one or two stories, and move on only after these stories are completed. That allows for incremental delivery of business value throughout the iteration, and usually minimizes the amount of work at risk for the iteration.

A team following the first approach, where an iteration is a mini-waterfall, will have very little useful information to say during a daily standup:

  • “What did you work on yesterday?”
  • “The flim flam widget.”
  • “Is it going ok?”
  • “Sure, I guess so.”
  • “What are you doing today?”
  • “Same thing as yesterday. Probably tomorrow, too.”

Zzzz. The daily standup is drudgery, because not much is changing, and none of the information is reliable anyway. When asked where they’re at, a developer uses the old 80/20 rule. Week one in a two-week iteration, they’re probably 20% done, and week two, they’re 80% done. And during week one, most developers have the confidence that they’ll be done in time, even if they’re stumbling. We won’t find out that there are real problems with their commitment until (too) late in week two.

In contrast, here’s how a standup might go in a team that looks to complete stories, not iterations:

  • “What did you work on yesterday?”
  • Joe: “I started on the frizzbang story.”
  • “That’s supposed to be done sometime today, right? Are you on target?”
  • “Well, maybe not, I’m stuck on a strange exception. I could use help from someone who’s worked in this area.”
  • Jane: “OK, well, I helped complete the flim flam widget by finishing the GUI component, so I’m available.”
  • “So the flim flam is ready for testing?”
  • “Yup. Today I’ll go work with Joe, before I start on the festivus tool.”

The more I do agile, the more I find that a primary focus on (really) completing stories is the best path to success.



I found out, that most of the time it happens this way, as people – who drive the stand-ups – create an impression what’s important and those who participate pick it up quickly and react according to the expectation. I have met few project managers, who are focused on delivering a real value, but instead are focused on detailed control.

But today I’ve heard one of the most stupid idea for daily stand-up. It was to divide the story into tasks and each day mark amount of percentage completed, so people could then present between each other their progress on daily stand-ups. This “thing” meant to focus people on completing their work.
Guess what ? The idea came out from the tool that draws the chart based on the amount of percentage completed.


When I was talking about this with a group of people yesterday, one woman asked, “Isn’t this going to make all that task level tracking we do difficult?” Apparently they are putting all the tasks (which to them were “analysis,” “design,” “coding,” … all to be handed off from one person to the next) into their tracking tool.

I suggested that perhaps they wouldn’t feel compelled to track at that level if they could all just work together on a story or two and get them delivered every couple of days or so.

I repeated myself. I’m not positive it sank in even the second time. We’ll see. I could smell some fear in the room.

The more I hear such stories the more I’m convinced there’s little trust in people and the focus is on a tasks/iterations not stories.