4 ms·

This task needs to be broken up into manageable pieces badly. This would also be my immediate thought as well. "Yesterday I setup integration with the analytic

This task needs to be broken up into manageable pieces badly. This would also be my immediate thought as well. "Yesterday I setup integration with the analytics service. Today, I'm going to audit the places where we currently send analytics and see if it would be possible to centralise it – I'll share the results later". It's hard to track progress and estimate if your tickets are huge multi-week affairs.

bshimmin 10y ago
Thanks one and all for the responses to my comment, which was written in some haste but seems to have generated useful discussion nonetheless. Just responding to this one, I would say that it really depends. If your task is implementing analytics and no one else on the team has anything much to do with it, then maybe it's best not to trouble them with the specifics. Your summary is much better, and only a few extra words, but if no one really cares about the analytics except to know that it's cheerfully in progress, maybe it's not all that necessary to go into more detail. This is definitely something you need to be wary of in a multi-disciplinary team. Also, I didn't mean "Anyone can come over and ask me about analytics if they like!" to sound defensive - it was actually more tongue-in-cheek! Here's another attempt: "I can't imagine why you would want to bore yourself with my analytics implementation, but please come over and ask me about it if you're having trouble sleeping at night." (I will freely admit that I am a confident person and would have no trouble saying something like that in front of a dozen people.)
sheepmullet 10y ago
Is it really important to track progress on a day to day basis? IMO, only for a small minority of tasks. The vast majority of projects I've seen and worked on are measured in dev years of effort. My current project is well over a thousand dev years. In comparison a few days is meaningless. Most often it's a trust issue.
- matthewmacleod 10y ago
  Is it really important to track progress on a day to day basis? It depends on the team. We find it useful specifically because we want to make sure we are estimating relatively accurately. Since we work in essentially 10-working-day periods, it's great to know when a piece of work we thought we could easily achieve is actually a blocker, or much more complex than we thought.
- jakubp 10y ago
  A thousand man-years of effort? Sounds like a very large project. Just for contrast: I've been working for a medium size software house for the past 4 years. Typical project size is somewhere around 500 to 1000 man days. On that scale, individual days matter. Still, I also have the impression that they matter because Clients demand certainty and precision in reporting rather than focusing on actual value delivered, but the management doesn't always see it that way.
  - sheepmullet 10y ago
    > A thousand man-years of effort? Sounds like a very large project. Kind of. It's upper-medium. It's nothing compared to Microsoft Office, a web browser, etc. Microsoft for example has maybe 50k developers and so creates 50,000 man years of work every single year. > Typical project size is somewhere around 500 to 1000 man days. That's roughly 2 devs for a year. That's hardly even a prototype where I work. It is fascinating to see the difference in scale in our industry.
- lairdpop 10y ago
  Daily standups aren't for tracking progress, they're for keeping the team in sync, and in particular are a forum for raising blockers/dependencies so that they an be addressed. Tracking progress goes on a Kanban board (or digital equivalent).
  - sheepmullet 10y ago
    > The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. www.scrumguides.org/scrum-guide.html#events-daily
ljw1001 10y ago
> 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 10y 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 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 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 10y 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."
pjbster 10y ago
I think some organisations have deeper problems [than developer communication] which SCRUM and Agile are simply not equipped to cope with. Here’s one example: * Moving functionality from a legacy^2 to legacy (mainframe to client-server) * Target system groaning under 15 years of neglect, developer outsourcing, technical debt and band-aids. Source system simply untouched for nearly 20 years. * Source and target systems inherently un- unit testable * Mediocre developers with no intrinsic sense of craftsmanship nor any desire to acquire some * Developers with no experience of legacy codebase so completely unqualified to estimate cost of stories * Culture of fear reinforced by performance reviews, stack ranking and PIPs * Locked down QA systems and silo’d resources Any one of these would be a project killer but my last employer suffered from all of them in the same project and showed no inclination to address any of them because they were deemed to be out of scope. But it was totally fine to tie up 10 people for 15 minutes every day to enable the PM to derive a magical velocity curve to feed back to the stakeholders so that the company could demonstrate how effective this SCRUM process was going to be.

bshimmin 10y ago

Thanks one and all for the responses to my comment, which was written in some haste but seems to have generated useful discussion nonetheless. Just responding to this one, I would say that it really depends. If your task is implementing analytics and no one else on the team has anything much to do with it, then maybe it's best not to trouble them with the specifics. Your summary is much better, and only a few extra words, but if no one really cares about the analytics except to know that it's cheerfully in progress, maybe it's not all that necessary to go into more detail. This is definitely something you need to be wary of in a multi-disciplinary team. Also, I didn't mean "Anyone can come over and ask me about analytics if they like!" to sound defensive - it was actually more tongue-in-cheek! Here's another attempt: "I can't imagine why you would want to bore yourself with my analytics implementation, but please come over and ask me about it if you're having trouble sleeping at night." (I will freely admit that I am a confident person and would have no trouble saying something like that in front of a dozen people.)

sheepmullet 10y ago

Is it really important to track progress on a day to day basis? IMO, only for a small minority of tasks. The vast majority of projects I've seen and worked on are measured in dev years of effort. My current project is well over a thousand dev years. In comparison a few days is meaningless. Most often it's a trust issue.

matthewmacleod 10y ago
Is it really important to track progress on a day to day basis? It depends on the team. We find it useful specifically because we want to make sure we are estimating relatively accurately. Since we work in essentially 10-working-day periods, it's great to know when a piece of work we thought we could easily achieve is actually a blocker, or much more complex than we thought.
jakubp 10y ago
A thousand man-years of effort? Sounds like a very large project. Just for contrast: I've been working for a medium size software house for the past 4 years. Typical project size is somewhere around 500 to 1000 man days. On that scale, individual days matter. Still, I also have the impression that they matter because Clients demand certainty and precision in reporting rather than focusing on actual value delivered, but the management doesn't always see it that way.
- sheepmullet 10y ago
  > A thousand man-years of effort? Sounds like a very large project. Kind of. It's upper-medium. It's nothing compared to Microsoft Office, a web browser, etc. Microsoft for example has maybe 50k developers and so creates 50,000 man years of work every single year. > Typical project size is somewhere around 500 to 1000 man days. That's roughly 2 devs for a year. That's hardly even a prototype where I work. It is fascinating to see the difference in scale in our industry.
lairdpop 10y ago
Daily standups aren't for tracking progress, they're for keeping the team in sync, and in particular are a forum for raising blockers/dependencies so that they an be addressed. Tracking progress goes on a Kanban board (or digital equivalent).
- sheepmullet 10y ago
  > The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. www.scrumguides.org/scrum-guide.html#events-daily

ljw1001 10y ago

> 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 10y 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 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 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 10y 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."

pjbster 10y ago

I think some organisations have deeper problems [than developer communication] which SCRUM and Agile are simply not equipped to cope with. Here’s one example: * Moving functionality from a legacy^2 to legacy (mainframe to client-server) * Target system groaning under 15 years of neglect, developer outsourcing, technical debt and band-aids. Source system simply untouched for nearly 20 years. * Source and target systems inherently un- unit testable * Mediocre developers with no intrinsic sense of craftsmanship nor any desire to acquire some * Developers with no experience of legacy codebase so completely unqualified to estimate cost of stories * Culture of fear reinforced by performance reviews, stack ranking and PIPs * Locked down QA systems and silo’d resources Any one of these would be a project killer but my last employer suffered from all of them in the same project and showed no inclination to address any of them because they were deemed to be out of scope. But it was totally fine to tie up 10 people for 15 minutes every day to enable the PM to derive a magical velocity curve to feed back to the stakeholders so that the company could demonstrate how effective this SCRUM process was going to be.