Hacker News Reader

Comment by hbrn | Hacker News Reader

It's a slippery slope. If there's one guy that gives a 3 minute update, he'll look more productive than the guy that gives 30 second update. So the next day 30s guy will fill his update with unnecessary details to look as productive.

The cure is constantly being aware of that bias. And remembering that main audience for standups is not your manager, it's your peers. Talk about things you want them to know.

There's a lot of subtle tricks that people don't even use/remember at this point. Like doing standups while actually physically standing. This creates a negative feedback loop instead of positive: if someone talks too much, the whole team will pushback.

View on HN

we combatted the bias factor by having managerless standups, and a designated (rotating) person just takes notes and forwards them to the manager.

Its actually fine. Management has repeatedly admitted they get little out of standups when there isn't a managerial level blocker (IE, we need them to interface with a team) and the concise written note updates allow them to see patterns of issues and address them more holistically.

For engineers, it got rid of the implicit bias talked about here.

Our standups are like 5 minutes or less now, and blockers / collaboration on blockers is way more common.

This also made the stakeholder check in every two weeks way more productive, people I think shifted their look what I did and how I did it energies to that meeting, where its 100% more appropriate.

I really like that.

Having management present can subconsciously push people to turn standups into a productivity contest.

in the notes, is there information about who did what or not?

I hesitate to broadly interpret this, but notes are not meant or used to "keep score", and if things can be explained without naming people they are, for sure, but

"person A is going to help person B to unblock them because of x y z" is about as detailed as one needs to be, usually.

Can you clarify what exactly you mean here?

You actually answered my question, thanks. I was/am just curious about which person has the decision power about who works on which part. But I guess it goes something like: person A tries to solve X. If he can't solve it, he asks the team and someone in the team will try helping. If the problem cannot be solved within a reasonable timeframe, then someday management will ask what's going on.

No manager in the meeting. No one to impress. Everybody stands. Light banter at the beginning because we're a team. One person leads the standup, round robin each time. Standup leader takes notes to paste in chat after, hurries people the f up if they're going on and on. Lastly, if you are late to standup even by 1 minute, you have to sing a song of Standup Leader's choice.

Yeah. "Let's take that offline/out of the meeting" when someone talks longer than 1 minute (longer than 30 seconds if it's a larger team).

By the way, I was at a place that did XP, and one of the rules was that if there was a meeting, there had to be food. What that did is, if someone was talking too much, someone would ask them "Are you going to eat that?" That, um, gently if not subtly told them to stop talking so much. Also, it meant that we got to snack.

we used to call ‘parking lot’ as in ‘Let’s take this outside’. Then when the standup ended, those that wanted to get in on the topics on the parking lot would stick around.

And for every minute you ran late, you had to do a push up.

It's not supposed to be a slippery slope. This is where a functioning "Scrum Master" is supposed to tell that person to stop talking and move on to the next person. That never actually happens though, so the next best scenario is light shaming of the guy who talks too long. If you have bad managers or too many people with management anxiety then it can be good to kick them out of the meeting.

I understand that this is how it is supposed to work in theory. But realistically most startups don't (and dare I say shouldn't) have the luxury of a dedicated Scrum Master.

Another thing I don't like is that it relies on humans to do a good job. How do you hire a good Scrum Master if you've never been one yourself? Hires like that are usually hit or miss. What if you need to hire ten of those?

Reply on news.ycombinator.com