[swanson]

Of the Three Pillars of Standup (what you did yesterday[1], what you are doing today[2], what are you stuck on[3]) I really only find [3] to be of much value.

Git log/Kanban board can tell you [1]/[2] if you actually need to know these things (hint: you probably don't unless you are manager/team lead/product owner).

Kanban blocker stickies can do [3] but I think a designated "safe haven" to get help is useful, at least for teams of varying skill level and comfort with one another.

My favorite standups have been the ones that "devolved" (in the formal capital-A Agile sense) to "Anyone blocked?" crickets "Okay. Good standup."

[DanielBMarkham]

You know, you have an excellent point. If you wanted to tweak standups, how about just doing #3? Everybody say where you're blocked and how we can help. Boom. Standup over.

It'd be fun to try.

[swanson]

Yep - a team near my desk routinely has sub-30 second standups following that format. I am probably a bit sour on standups in general since my last project had 10+ person, 15+ minute meetings (sometimes with the client present...) that added very little value for their cost ($1XX x 0.25 x 12).

[DanielBMarkham]

Team size kills so many things. I had a client once that couldn't start a project without at least 15 people. Those projects were doomed from the start.

Maybe I'm getting old and cranky, but lately 7 is becoming my limit for people on a team, with team size as low as 3 looking pretty damned good.

[mhurron]

If you're blocked, why don't you just contact the scrum master directly when you are. Why do you have to get everyone together to mention it.

[beat]

Because you have a widely experienced team and you don't know who might have the answer.

[mhurron]

Even with that, a email would suffice.

The scheduled, mandatory standups interrupt everyone the same as any other meeting.

[beat]

Email interrupts too, and probably worse because it happens ALL THE DAMNED TIME. Slicker systems like Campfire can be better, but you're still dealing with asynchronous versus synchronous communication. Synchronous is almost always more efficient.

The whole problem with the OP's premise is that his root cause analysis is flawed. He sees that most meetings are inefficient, and therefore assumes inefficiency is caused by meetings. But meetings also provide other efficiencies. As long as the added efficiency outweighs the cost, meetings are a net win.

[dragonwriter]

> Synchronous is almost always more efficient.

Synchronous is almost always more efficient when there is very close to zero processing time necessary between receipt of communication and response to it.

As you get away from zero processing time, the efficiency of synchronous communication drops very, very quickly.

Also, that's assuming 1-on-1 communication. Even when a synchronous exchange is between two parties is efficient, every unnecessary party whose work is blocked because they are a party to the meeting drops the overall efficiency considerably.

Which is why meetings tend, in practice, to be very inefficient if they aren't well planned: while synchronous communication can be efficient for certain communications and a properly chosen set of participants, meetings often involve lots of people unnecessarily bound up waiting for other people to complete synchronous exchanges, and often involve subject matter where asynchronous exchanges would have been more efficient even for 1-on-1 communication.

[thematt]

Interesting, how is synchronous communication ever more efficient than asynchronous communication? It might be more efficient for the person asking, but rarely for the people being asked.

[wpietri]

> hint: you probably don't unless you are manager/team lead/product owner

Depends on how you're working. I prefer a collective responsibility model. I know some people prefer to have their units of work spoon-fed to them, and are willing to trust some manager that everything will fit together in the end. But especially at startups, I think things go better when everybody feels responsible for the results.

I do agree that minimizing 1 and 2 is good, but I think you can get a lot of that just by holding the meeting around a physical Kanban board and letting people point at things.

[swanson]

Sure - definitely agree with you on seeing all the pieces fit together. I get a way better picture of that with other methods (Kanban, story map) than from someone listing which classes they wrote yesterday.

Once you learn to "read the board" as a team, 1/2 can largely go away. And the best part is that the board is asynchronous - I can go look at it whenever I want without bothering anybody.

[wpietri]

If people are actually listing classes in the stand-up, I agree that's a problem. For me the stand-up "did yesterday" content is more, "We worked on X and have it almost finished. In the course of that, we made a neat utility for X, and cleaned up some ugly code in Y. If anybody wants to talk about refactoring Y further, let's talk."

[dalore]

2) can be useful for when you say you're about to do something and someone else in the team has added a helper or done something similar in that area.