4 ms·
> Only in the sense that the team needs to know itself how work is progressing That's what retrospectives, demos, and stories are for. If there is concern abo
by humanrebar 10y ago
> Only in the sense that the team needs to know itself how work is progressing
That's what retrospectives, demos, and stories are for.
If there is concern about individual performance, managers could create dashboard of their teams' git commits, allowing them to jump around and see peoples' work passively without disrupting the entire team.
- lairdpop 10y agoWhen developers pull tasks, their name goes on it. If one dev keeps pulling tasks that don't get done, or take far too long, that becomes obvious to the whole team quite rapidly. That doesn't "disrupt" the team at all.
- humanrebar 10y agoRight. The point is you don't really need them to stand up every day to say "still working on tasks A, B, and C". You'd just look at the board and say, "Hey, you have four things assigned to you. Are they blocked? Otherwise, please do one thing at a time."
- watwut 10y agoYou don't need whole team to see that. You need to go to that one developer and ask him why tasks are not finished. I case he has solvable problem, you get the chance to fix that solvable problem. In case he does not, you need to watch him more and maybe eventually fire him. The team knowing about whole thing won't make your job for you. It will just make them lash at each other unpredictably.