3 ms·

Standups are only good if they're used for a very specific, time-critical task that requires coordination among several people. Ex: a major feature is being lau

by pradn 7y ago

Standups are only good if they're used for a very specific, time-critical task that requires coordination among several people. Ex: a major feature is being launched that requires a lot of coordination, but is going to be done in 10 days. Standups should not be used as tack-on "agile" or as a way for management to keep up with what devs are doing or to pressure devs to do more. Ex: daily standup at 11 am. The original purpose of standups in "agile" was to help devs get unblocked. But the expectation should be that others should help devs get unblocked whenever they hit a block, instead of waiting til the next standup! What are they wasting time being blocked when they can simply send an email or IM to a colleague?

zoomablemind 7y ago
Indeed, to make a standup more straightforward we usually just fix 3 questions to everyone: 1. What are you working on? 2. Are you having any blockers? 3. What are you going to work on next? In reality it's just about blockers and seeing the next direction. No need to embellish or 'stuff' any of these responses. It was kind of natural when we used to have a real storyboard, the one with post-it stickies. So the standup would be a good time to move the stories to done or todo side. Well, the whole idea kind of sputters when there're significant status disbalances on the team. For one, the dev members get into status-report mode, while the managers get into i'm-busy-with-important-meetings mode. For the other, it's harder for mangement members of a team to align their ways of staying busy with 'ant-like' activity of devs. Also in such context a 'blocker' suddenly signals a kind of a failure, lack of efficiency that has to be owned, instead of a usual work issue. Who wants to own a failure?Ironically, the management can be instrumental in resolving intra-dept blockers. Any team is about mutual trust, so if the standup does not serve the needs of the whole team, I'd just reserve that time to those members that see a benefit from it. Find another way to interface with other members (mgmt?), maybe a questions queue or some briefs pipeline.

by pradn 7y ago

zoomablemind 7y ago

Indeed, to make a standup more straightforward we usually just fix 3 questions to everyone: 1. What are you working on? 2. Are you having any blockers? 3. What are you going to work on next? In reality it's just about blockers and seeing the next direction. No need to embellish or 'stuff' any of these responses. It was kind of natural when we used to have a real storyboard, the one with post-it stickies. So the standup would be a good time to move the stories to done or todo side. Well, the whole idea kind of sputters when there're significant status disbalances on the team. For one, the dev members get into status-report mode, while the managers get into i'm-busy-with-important-meetings mode. For the other, it's harder for mangement members of a team to align their ways of staying busy with 'ant-like' activity of devs. Also in such context a 'blocker' suddenly signals a kind of a failure, lack of efficiency that has to be owned, instead of a usual work issue. Who wants to own a failure?Ironically, the management can be instrumental in resolving intra-dept blockers. Any team is about mutual trust, so if the standup does not serve the needs of the whole team, I'd just reserve that time to those members that see a benefit from it. Find another way to interface with other members (mgmt?), maybe a questions queue or some briefs pipeline.