Standups are Not Poisonous

Another wrong way is to take a long time. It's a quick meeting, where everybody syncs up for the day and major issues are raised. I think of it as like the way players will quickly huddle together on a sports field. It should be high energy, biased toward finishing, and tabling any significant discussions for later.

As far as I'm concerned, they only make sense in a team environment. Where people are jointly working on shared goals and extensively support one another. In the Extreme Programming approach, they go along with a team work queue and collective code ownership.

If people, say, have individual work queues parceled out by a boss and don't interact much, then as far as I'm concerned the stand-up meeting is the wrong tool.

I like doing the stand-up as early as possible, so that there's minimal slack time before hand. And I prefer to work in ways that are less dependent on the state in one's head, including test-driven development and pair programming.

The standup is always in the team room. Everybody on the same team works in the same room. Generally, you do it in front of the kanban that shows the state of the project.

Because it's right where everybody works, it's pretty easy to be on time. Regardless, it starts on time. No waiting for stragglers; it just encourages them.

You stand for 10 minutes or so.

The team is some reasonable size; I think of 12 as a maximum.

If the people turning up have nothing to do with you, then it's not actually a team. Teams are groups of people that win or lose together. Team members help one another out to achieve shared goals.

If what people say is boring, you should be able to tell them so. They are there to talk to the team; there's no point in them saying things that aren't useful to the team.

Coffee should be in or near the team room. Ditto water, snacks, and other things necessary for humans to do work.

The stand-up should be run in such a way that people leave ready to jump on things.

If I had to guess from your description, I'd say that Yahoo took a top-down culture, pasted on some Agile rituals, and kept right doing the same old bullshit. Which, honestly, is a giant waste of time. If you're going to do waterfall in a command-and-control context, just do that. No sense putting agile lipstick on your waterfall pig.

I learned one of the Agile methods before the term Agile was even invented. Adopting it made a giant difference in the quality and sanity of my work.

But so many people today have have pseudo-Agile methods inflicted on them in large corporate contexts. There, the point isn't to make things saner and more effective. It's to please some executive who has a bee in their bonnet. And often, they only adopt some labels and some rituals. It's all pain, no gain.

I wrote about how this happened here: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...

But it's at the point where I avoid using the term "Agile". Or any other buzzword. I look at the circumstances, and say, "Hey, you guys feel pain X. Can we try change Y and see if that helps?" Often, the tool is one from the Agile or Lean toolbox. But I won't talk about the particular process I'm borrowing from because a) most people don't care, and b) a lot of people have been burned with faux-Agile adoptions.