5 ms·

A daily sync is way too often on teams that know what they're doing. It feels like busy work and is a waste in throughput and stress. Once a week, with committe

A daily sync is way too often on teams that know what they're doing. It feels like busy work and is a waste in throughput and stress. Once a week, with committed items with a true definition of done is all that is needed. Anything in-between should be facilitated by the team members to unblock each other. Anything else is just stakeholder over management and or inexperienced teams. edit: at the most, I think async are passable via slack or something similar. Otherwise all data on this can be easily done via a Kanban board.

opportune 7y ago
I like daily syncs if they are done quickly (<15m), and if people are working on different-enough things that they don't really know what their teammates are working on. Because that way you can unblock each other and actually use agile the way it was meant to be done in the face of underestimated tasks or changing requirements
- jacques_chester 7y ago
  In my experience anything more than 10 minutes is a smell. It typically means you've got stories that are too big, have unaired problems, that you dive into implementation instead of just syncing briefly, or the team has too many people.
  - opportune 7y ago
    I personally think brief dives into implementation / explanations of issues is fine. If something takes only 5 minutes to discuss between everyone, I'd rather do it while I'm already in a meeting, and having the whole team there helps opinions get heard. But this is just personal preference
  - jpdaigle 7y ago
    My preferred way to handle this is to explicitly acknowledge that the meeting isn't just sync-up, it's really two meetings: - sync up / status is 15 mins. Any implementation discussion gets put in the parking lot - once we've gone around the table, the rest of the meeting is handling the Q&A / parking lot we parked during the status discussion. Anyone not directly concerned by it is encouraged to leave, get out and be productive! This gets you the double benefits of interrupt coalescing (a single regular interruption instead of 2 smaller ones where one is an irregular surprise), and preserving the quickness and relevance of the stand-up, as it's really just the first 10-15 minutes of the calendar slot, after which you're good to leave.
- dfischer 7y ago
  With a visual system like Kanban, it's quite easy to see what other people are working on. The problem I have with daily syncs is that it's redundant to information already available, and you're forcing people to "meet" without any value. A lot of conversations in that "sync" are just noise to a majority of participants. It's kind of like a bunch of people talking to a wall unless you happen to be associated directly with the update – which is more rare. In my experience, the need is to provide a clear method of communication and ability to unblock one another. A Kanban board is perfect for this, as well as committing to a definition of done. Anything else... is very wasteful in my experience.
  - opportune 7y ago
    For me, what is in a Kanban board is not enough info to be able to determine when I can help unblock other people on my team. I think this probably depends on how you use project-management software and what your team works on; for me, a teammate's item might list "Create pipeline to process dataset Y on hourly basis". If they are running into issues, I don't know if it's something I've seen before with that dataset, or that pipeline tech, or the processing script, or end-to-end latency, or XYZ. A standup helps clarify things somewhat Also if a teammate is actively working on something that is a downstream dependency of something I am working on, then I can passively learn about requirements and expectations for my own work, become aware of issues ahead of time, etc.
    - dfischer 7y ago
      Initial reaction: 1. For transparency any member of the team can identify blockers in Kanban by putting them in the blocked column. 2. If you're blocked, and running into issues, you'd reach out to anyone that can help you. Why would you wait for a standup or "talk to the wall" for that? Just be proactive. Dependencies should be known before committing to a scope of work (iteration) with the team. Planning stage (minimal time investment for scope of work definition) vs committed work stage (in progress iteration).
ajmurmann 7y ago
> Anything else is just stakeholder over management and or inexperienced teams. At Pivotal we see the PM as part of the balanced team. The PM, just like designers and engineers, will have the daily standup, weekly retros and planning meeting together. The goal of the standup is to share what of interest happened yesterday, if help or opinions are needed and discuss pairs for the day. Sometimes discussions start about topics mentioned in the article where it's crucial to have the PM there. Standup should usually be around five minutes. That's the reason it's not a sit-down meeting.
- dfischer 7y ago
  My reaction to this would be the work committed to was unclear. A task should have all the items clarified before being committed to. If there are questions throughout the iteration then the work was poorly planned. It should be a rarity that a task was ill defined. My view is that a PM is available as a resource to clarify as needed. Meetings between the "doers" of a team and the PM should not be forced, especially daily. This leads to micromanagement and changing requirements too often. But alas, everyone has a different philosophy. :)
  - jacques_chester 7y ago
    Changing requirements is fine, though, so long as there's a discussion. Engineering explains what it might involve and the PM gets to decide if they think the change is worth it. Generally once a week is fine. Changes at sub-weekly cadence suggest deeper problems that need to be sorted out. My personal preference is for very fine-grained stories rather than giant chunks of acceptance criteria. The latter tend to turn into week-long wanderings and get edited over and over. Whenever I've been able to I've coached PMs towards smallest possible units of value.
    - dfischer 7y ago
      To clarify my definition: Changing requirements should only happen outside the scope of committed work; otherwise you're building churn, poor features, and poor code. This lever of "committed work" can be adjusted per team (1 week, 2 weeks, 4 weeks, and so on). It seems you agree with my view of a minimum of 1 week before it can change. I agree also with fine grained tasks/stories. As small as possible and as consistent as possible. They should all have clear DOD's though. Definitely agree with smallest possible units of value (that also varies per a person).
rramadass 7y ago
>Once a week, with committed items with a true definition of done is all that is needed. Anything in-between should be facilitated by the team members to unblock each other. Anything else is just stakeholder over management and or inexperienced teams. Finally! A sane voice appears!

opportune 7y ago

I like daily syncs if they are done quickly (<15m), and if people are working on different-enough things that they don't really know what their teammates are working on. Because that way you can unblock each other and actually use agile the way it was meant to be done in the face of underestimated tasks or changing requirements

jacques_chester 7y ago
In my experience anything more than 10 minutes is a smell. It typically means you've got stories that are too big, have unaired problems, that you dive into implementation instead of just syncing briefly, or the team has too many people.
- opportune 7y ago
  I personally think brief dives into implementation / explanations of issues is fine. If something takes only 5 minutes to discuss between everyone, I'd rather do it while I'm already in a meeting, and having the whole team there helps opinions get heard. But this is just personal preference
- jpdaigle 7y ago
  My preferred way to handle this is to explicitly acknowledge that the meeting isn't just sync-up, it's really two meetings: - sync up / status is 15 mins. Any implementation discussion gets put in the parking lot - once we've gone around the table, the rest of the meeting is handling the Q&A / parking lot we parked during the status discussion. Anyone not directly concerned by it is encouraged to leave, get out and be productive! This gets you the double benefits of interrupt coalescing (a single regular interruption instead of 2 smaller ones where one is an irregular surprise), and preserving the quickness and relevance of the stand-up, as it's really just the first 10-15 minutes of the calendar slot, after which you're good to leave.
dfischer 7y ago
With a visual system like Kanban, it's quite easy to see what other people are working on. The problem I have with daily syncs is that it's redundant to information already available, and you're forcing people to "meet" without any value. A lot of conversations in that "sync" are just noise to a majority of participants. It's kind of like a bunch of people talking to a wall unless you happen to be associated directly with the update – which is more rare. In my experience, the need is to provide a clear method of communication and ability to unblock one another. A Kanban board is perfect for this, as well as committing to a definition of done. Anything else... is very wasteful in my experience.
- opportune 7y ago
  For me, what is in a Kanban board is not enough info to be able to determine when I can help unblock other people on my team. I think this probably depends on how you use project-management software and what your team works on; for me, a teammate's item might list "Create pipeline to process dataset Y on hourly basis". If they are running into issues, I don't know if it's something I've seen before with that dataset, or that pipeline tech, or the processing script, or end-to-end latency, or XYZ. A standup helps clarify things somewhat Also if a teammate is actively working on something that is a downstream dependency of something I am working on, then I can passively learn about requirements and expectations for my own work, become aware of issues ahead of time, etc.
  - dfischer 7y ago
    Initial reaction: 1. For transparency any member of the team can identify blockers in Kanban by putting them in the blocked column. 2. If you're blocked, and running into issues, you'd reach out to anyone that can help you. Why would you wait for a standup or "talk to the wall" for that? Just be proactive. Dependencies should be known before committing to a scope of work (iteration) with the team. Planning stage (minimal time investment for scope of work definition) vs committed work stage (in progress iteration).

ajmurmann 7y ago

> Anything else is just stakeholder over management and or inexperienced teams. At Pivotal we see the PM as part of the balanced team. The PM, just like designers and engineers, will have the daily standup, weekly retros and planning meeting together. The goal of the standup is to share what of interest happened yesterday, if help or opinions are needed and discuss pairs for the day. Sometimes discussions start about topics mentioned in the article where it's crucial to have the PM there. Standup should usually be around five minutes. That's the reason it's not a sit-down meeting.

dfischer 7y ago
My reaction to this would be the work committed to was unclear. A task should have all the items clarified before being committed to. If there are questions throughout the iteration then the work was poorly planned. It should be a rarity that a task was ill defined. My view is that a PM is available as a resource to clarify as needed. Meetings between the "doers" of a team and the PM should not be forced, especially daily. This leads to micromanagement and changing requirements too often. But alas, everyone has a different philosophy. :)
- jacques_chester 7y ago
  Changing requirements is fine, though, so long as there's a discussion. Engineering explains what it might involve and the PM gets to decide if they think the change is worth it. Generally once a week is fine. Changes at sub-weekly cadence suggest deeper problems that need to be sorted out. My personal preference is for very fine-grained stories rather than giant chunks of acceptance criteria. The latter tend to turn into week-long wanderings and get edited over and over. Whenever I've been able to I've coached PMs towards smallest possible units of value.
  - dfischer 7y ago
    To clarify my definition: Changing requirements should only happen outside the scope of committed work; otherwise you're building churn, poor features, and poor code. This lever of "committed work" can be adjusted per team (1 week, 2 weeks, 4 weeks, and so on). It seems you agree with my view of a minimum of 1 week before it can change. I agree also with fine grained tasks/stories. As small as possible and as consistent as possible. They should all have clear DOD's though. Definitely agree with smallest possible units of value (that also varies per a person).

rramadass 7y ago

>Once a week, with committed items with a true definition of done is all that is needed. Anything in-between should be facilitated by the team members to unblock each other. Anything else is just stakeholder over management and or inexperienced teams. Finally! A sane voice appears!