Walking the board is much more helpful for the team and retrospectives and one to ones can be used to talk about productivity differences, individualities and other issues.

We came up with a variant to fix this. You have to say what the next person in the circle said they'd do yesterday before your talk.

This forced everyone to pay more attention as you don't know who would be standing next to you tomorrow. It wasn't easy to do but I think it did make people more aware of what was going on.

So instead of wasting some people time, you are now wasting 2x that time.

Make the meeting relevant to everyone, make it tight (time-wise). Hiding the problem under a tarp ensures it doesn't get any improvements.

Here's the reason: managers are so spread thin that they don't want to be in 5-10 standups all morning, so they combine around organizational structures rather than product(s)/deliverable(s). Another case of the software delivery matching org structure...

> because government project? although I imagine this happens in non-gov settings too, this is just my experience.

Why not split into smaller work groups? What's the advantage of 20 person teams?

Focussing on the work to be done puts the emphasis on teamwork and skips the pressure on people to justify themselves or play politics by showing off.

That's assuming everyone is doing the work and they're being trusted to do the work. If that's not the case, then you have bigger problems than the format of your daily standup, and standup is not the best time to address them.

The goal is not to explain what you did. Happy with the approach because knowledge is actually spreading across the team currently. Meeting do get much longer though (1 hour usually), but time is recovered mostly on code reviews which become shorter. Usually lot of discussions sprouts out of this, leading to better code overall.

"Worked on adding discounts to the shopping cart page. Went over to talk to Chris in billing about that, and he mentioned in passing that they are planning to move on to SAP next year."

That could be incredibly important information for the team! It doesn't come up as naturally when working through stories as in a round robin.

That mindset is precisely the reason why these meetings are important, because these grievances might not necessarily reflect or deserve a ticket. They might be nothing or they might be something. What's important is that these meetings create a space where they can safely be addressed without creating any burden on the team and on the individual reporting them.

I've read somewhere that these meetings work as therapy for the team. Perhaps by putting it this way you might better understand the issues these meetings solve.

That doesn't cut it. Being expected to talk about stuff doesn't put you on the spot, and purposely requesting the team to address a concern makes you stand out as the one creating problems where none existed.

Personally, I always try to take quick notes ahead of time in order to be able to listen to others during the meeting. I'd highly recommend this to everyone to help focus on what others are saying.

Our 'walk the board' process was saved for tuesdays and thursdays and involved product and project managers. We set a 45-minute max so noone would rabbit hole on any one ticket.

This has been my favourite process so far because this was the highest level of team accountability I've experienced and you would only spend 1.5 hours a week in meetings.