Re:Ask HN: How to manage developers who aren't very good?
by BerislavLopac on Friday February 06, 2015 @05:49PM
(#9012103)
My favourite take on the standup meetings is not to structure them as reports on what each team member did yesterday and planned to do today. They can include that if necessary, but I prefer using them as an opportunity to exchange knowledge. The team members should be encouraged to discuss any issues they ran into and share the ways they resolved them, and the lead should listen and make note of any recurring issues -- both related to technology and to the personal -- and see if they need resolving on a more individual level.
[ Parent
| on HN ]
Re:Ask HN: How to manage developers who aren't very good?
by dragonwriter on Friday February 06, 2015 @06:09PM
(#9012199)
Its essential to regularly update what tasks are done and what tasks are being worked on by whom, but if you use some other system to handle those updates and keep people aware of the updates (e.g., visual artifacts updated as items are completed and pulled for work, as in kanban), then you don't need to do that in the standup meeting.
Identifying issues encountered (both to share knowledge of how issues were resolved and to gather information on addressing barriers that haven't been resolved) is a pretty standard element of standup meetings even when they include progress updates, and certainly a good thing to keep them for if you've moved the status updates to another channel.