3 ms·

> It's hard to track progress and estimate if your tickets are huge multi-week affairs. So what you are saying is that the standup really _is_ for project trac

> It's hard to track progress and estimate if your tickets are huge multi-week affairs. So what you are saying is that the standup really _is_ for project tracking. I don't disagree. In my experience that has been the main point to the meeting, but it's not really how it's supposed to be done according to agile doctrine. The point of the meeting is often (A) let management/outsiders assess progress across devs with minimal time investment on the manager's part, and (B) put subtle pressure on the devs via the daily confession.

matthewmacleod 9y ago
So what you are saying is that the standup really _is_ for project tracking Only in the sense that the team needs to know itself how work is progressing, in order to understand what they can realistically achieve, or to estimate more accurately, or to identify pain points that need to be resolved. Not tracking in the 'report to an external agency how much is being done every day', which I agree is awful. The point of the meeting is often… I maintain that is this happens, you are in a bad environment.
- humanrebar 9y 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 9y ago
    When 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 9y ago
      Right. 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 9y ago
      You 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.
lairdpop 9y ago
No, standups should not be for project tracking, it's a quick synch up and opportunity to raise issues. (e.g. My task is blocked until X is done). Then you resolve the blockage outside of the standup, in a longer, deeper discussion with fewer people. Project tracking should be in a Kanban board (or digital equivalent, such as Jira or TFS). This should be used by the dev's so that they know what work is queued up, what work is in process and who's working on it, and what is completed, so that they can do their jobs. In an agile team most of the management is externalized onto a Kanban board - the team manages itself most of the time, using the Kanban board to have a shared understanding of what's going on. A secondary benefit is that outsiders can look at the Kanban board to assess progress, without consuming any dev time. The "subtle pressure" on the dev to deliver is a great point. In fact, when status is completely transparent, developers put a great deal of pressure on themselves to deliver, because they want to honor their commitments, and there's a social pressure not to be "that guy" that blows the sprint.
- watwut 9y ago
  While I don't mind daily meeting as such, if communication between ream members works at least half well, you should not need special occasion to raise the issues. You raise them wherever you see other team members are not focused on something. As for second paragraph, I prefer management style that accepts that things sometimes take longer then estimated. I don't want to stay longer because made up deadline.

matthewmacleod 9y ago

So what you are saying is that the standup really _is_ for project tracking Only in the sense that the team needs to know itself how work is progressing, in order to understand what they can realistically achieve, or to estimate more accurately, or to identify pain points that need to be resolved. Not tracking in the 'report to an external agency how much is being done every day', which I agree is awful. The point of the meeting is often… I maintain that is this happens, you are in a bad environment.

humanrebar 9y 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 9y ago
  When 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 9y ago
    Right. 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 9y ago
    You 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.

lairdpop 9y ago

No, standups should not be for project tracking, it's a quick synch up and opportunity to raise issues. (e.g. My task is blocked until X is done). Then you resolve the blockage outside of the standup, in a longer, deeper discussion with fewer people. Project tracking should be in a Kanban board (or digital equivalent, such as Jira or TFS). This should be used by the dev's so that they know what work is queued up, what work is in process and who's working on it, and what is completed, so that they can do their jobs. In an agile team most of the management is externalized onto a Kanban board - the team manages itself most of the time, using the Kanban board to have a shared understanding of what's going on. A secondary benefit is that outsiders can look at the Kanban board to assess progress, without consuming any dev time. The "subtle pressure" on the dev to deliver is a great point. In fact, when status is completely transparent, developers put a great deal of pressure on themselves to deliver, because they want to honor their commitments, and there's a social pressure not to be "that guy" that blows the sprint.

watwut 9y ago
While I don't mind daily meeting as such, if communication between ream members works at least half well, you should not need special occasion to raise the issues. You raise them wherever you see other team members are not focused on something. As for second paragraph, I prefer management style that accepts that things sometimes take longer then estimated. I don't want to stay longer because made up deadline.