> The standup should create conversation between team members. A team of even adequate--not great, just adequate--people working together will have these conve

> The standup should create conversation between team members. A team of even adequate--not great, just adequate--people working together will have these conversations independently. > 'Oh you said you are doing X while doing your tasj? That won't work for my Y, good thing you mentioned it, let's have a quick talk after standup' There are two different cases where this would apply: when someone attempts to do something and finds some blocking issue, and when someone attempts to do a task out-of-order from a dependency. The first case rarely occurs in a way that a daily standup will efficiently address. Most tasks take longer than a day to do--the standup is unlikely a time when this sort of issue is most efficiently resolved. Other than junior engineers or maybe quick bug fixes I rarely encounter an engineer who measures his work by the time between standups. The second case is best resolved by having a proper, complete design process--requirements analysis, technical design (changes in architecture, code, dependencies, etc.), and a team-wide review--and a work tracking tool that permits tasks to be ordered (e.g. JIRA's "blocked by" label). Work doesn't always fit into that neat of a design and execution process, obviously, and it's okay to have an occasional, regular meeting (e.g. once a week or every other week, maybe slightly more often depending on the scope of work the team typically has) to address those specific issues as-needed. But those meetings shouldn't be permanently scheduled on the calendar--just while a given project is in progress.