4 ms·

Standups hurt more than help. As someone who managed fully remote teams in the past, what worked very well for us is a set of rules around in-house built task m

Standups hurt more than help. As someone who managed fully remote teams in the past, what worked very well for us is a set of rules around in-house built task management system (something like Jira could work too). 1) Aim to take 2-3 tasks, do not take more, take 1 if the task is large, but usually, it's a sign of an overblown story. 2) Every day at the end of the day, write a "current status" comment. These comments are visible in the master panel, and I could take action the next day to help developers resolve roadblocks, if the resolution is taking longer, they can work on other tasks they claimed. This effectively eliminated the need for standups, the whole team could sync using task "current status" updates, and chime in with help or advice. I was able to see the progress and issues without forcing people into a mess of a video call, and everybody could still stick to their preferred schedules and have personal lives.

mywittyname 7y ago
This is my preferred method as well when leading a team. Standups as intended are too brief to discuss the important details. This is why they end up ballooning to 30+ minutes at most companies, because anything shorter is of little value. They also end up as a catch-all meeting for any topics that require the team's input; I dislike this because people are expected to provide input on the spot without really making any thoughtful considerations. If we want to have a discussion on a UI component, that should be done in a dedicated, prepared meeting, not at 8:30 in the morning when people are unprepared and said developer can take advantage of unpreparedness to obtain the consensus they want. When I provide up-stream status reports, I like to have the developer's notes in front of me for a quick refresher. Plus, they serve as a good reminder on topics that need followup.

mywittyname 7y ago

This is my preferred method as well when leading a team. Standups as intended are too brief to discuss the important details. This is why they end up ballooning to 30+ minutes at most companies, because anything shorter is of little value. They also end up as a catch-all meeting for any topics that require the team's input; I dislike this because people are expected to provide input on the spot without really making any thoughtful considerations. If we want to have a discussion on a UI component, that should be done in a dedicated, prepared meeting, not at 8:30 in the morning when people are unprepared and said developer can take advantage of unpreparedness to obtain the consensus they want. When I provide up-stream status reports, I like to have the developer's notes in front of me for a quick refresher. Plus, they serve as a good reminder on topics that need followup.