Hacker News Reader

Comment by kozhevnikov | Hacker News Reader

Daily stand-ups have two formats, one is Round Robin that has origins in Scrum, other is Walk the Board that is more Kanban. I highly recommend you switching from "did yesterday/do today" to "walking the board" as it is less about checking what each employee delivered in a day but rather what the team can do to move tickets through the board. It is also more inclusive allowing quiet/introverted/non-native English speaking members of the team to participate in the meeting rather than rehearse their updates in their heads ignoring others.

View on HN

I agree with this, I found that if you go for the Round Robin format, often, people are just thinking about what are they going to say next, and how to make it sound like actual valuable work rather than listen to the colleagues. It gets akward when some people get a lot done (apparently) and others not, also not everyone knows how to "sell" their work, and IMO it can create weird dynamics.

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.

I also noticed this.

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.

This sounds horrendous. It doesn't really feal like it would achieve much either except making standups even harder.

This is a terrible approach for the fact that instead of addressing the problem of people not listening because of stuff not relevant to them said from others, it ensures you must listen to that irrelevant stuff.

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.

Why is this voted down? Stand-ups are supposed to be about increased team cohesiveness and this helped their team achieve that.

wow this would suck in a 20 person standup

Literally everything would suck in a 20 person standup.

can confirm

Why would you have 20 person standups?

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

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...

Of course the next question in line is "why is a manager involved in the standup?"

> 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?

organically this is what happens to actually get things done. but mind you, these small work groups are successful despite the large standups. life finds a way...

Well, yes, a 20 person standup is a little more than twice the maximum size conventional wisdom holds is appropriate, so it is going to suck to start with and much advice for normal 5-9 person stand-ups will be counterproductive and make it worse.

I know we tend to have little control over this as ICs, but I think the party line here is that 20 is too many people to effectively make use of most agile/scrum ceremonies. Do you actually need to know all 19 other persons’ updates?

Individuals don't, but the managers, who may be well meaning, feel the need to.

I agree with this. By far the least useful of the standard standup questions is "what did you do yesterday".

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.

We have been trying to show what we did code-wise (or explain if it was something that didn't end up with code). The goal however, is to show some coding practices or new functions created that other team members might find useful, as well as working as a brief "review" of the code itself.

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.

It should be noted that the "round robin" format has an important aspect which is to enable each team member to air his/her personal grievances regarding anything related to the project.

I would rather have this kind of discussions in the retrospective. It is a dedicated time for the team to discuss pain points, and to take actions to heal them.

I think the sooner the team is aware about issues the better.

I'm going to assume the GP meant blockers rather than grievances. Grievances are more like injustices and shouldn't really be aired at standups in a healthy team.

I think putting this in terms of "grievances" isn't helpful. Blockers, problems, observations, are all useful to report.

"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.

Grievances should relate to a ticket on the board, if not then make a ticket for it, if not that then is the grievance important?

> Grievances should relate to a ticket on the board, if not then make a ticket for it, if not that then is the grievance important?

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.

This stuff goes in a retrospective. Airing of non specific grievances, therapy, etc. A scrum should be as short as possible.

There is a simple solution to this. After the board is done someone can just ask "Has anyone got anything else to add?"

>>There is a simple solution to this. After the board is done someone can just ask "Has anyone got anything else to add?"

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.

If team members need to be directly asked if they see problems otherwise they won't do it themselves, then there is a much bigger trust or "safety" issue at play.

> rather than rehearse their updates in their heads ignoring others.

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.

I like to alternate these. One day we do a round robin, the other we walk the board. It helps to have different perspectives on the work you're doing.

Also like this method. Walking to board every day isn't always necessary, there shouldn't be that many changes from one day to the next. But by only using round robin every other day, people actually have something to say.

Walking the board is effective to have all team members in the same page of what's going on. But if the amount of tickets on kanban boards is huge, it could be time consuming. I'd rather have weekly "walking the board" meeting than a daily.

Genuine question - how big is this team and how many work in progress tickets are there? For a 7 person team I'd question how many in progress tickets you genuinely could be working on, unless you are breaking down to a very very low level of task.

The last few teams I've worked on moved the daily Round Robin into slack. You would have to fill it out an hour after signing in and before you left for the day. Accountability was key and having it in the dev-chat saved a lot of time.

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.

Gotta try to "walk the board" in place of a daily someday soon. Sounds nice.

Reply on news.ycombinator.com