迭代启动后，每天会进行站会（Daily scrum），站会大概是敏捷的标志性实践，目的在于反馈进展，协调工作，识别风险，移除障碍。形式很简单，所有人围在看板前按次序说3句话：
- 昨天我做了什么（更新对应任务卡上的小时数）
- 今天我打算做什么（如果开新的任务卡，将任务卡翻转为开发泳道）
- 有什么困难（障碍）
所有人更新完小时数后，根据任务卡更新后的时间来更新burndown，如果burndown识别出交付存在风险，则进行相应的调整，可能是解决技术障碍，减少低优先级的故事，甚至是短期的加班；如果站会期间有问题需要再发起讨论的，站会结束后再转移到工作白班区进行下一步的讨论。
站会的形式简单，一般来说团队很容易掌握，但在实践中还是看到有各种各样的问题。
站会和看板
如果团队有物理看板（强烈建议使用物理看板而不是电子看板），要确保看板布置在团队工作区，每个人都能方便的走过去，而不是在另外很远的地方，或者在SM座位背后的角落。如果看板的位置离团队很远，或者走到看板旁很费劲，这一丝丝的不方便很可能会让灵感稍纵即逝，甚至忘记要去及时移除障碍。
有些公司的后勤部门不太跟得上敏捷转型的节奏，要求工作区要保持“整齐划一”，这种情况下千万不能妥协，一定要争取所有的机会要求团队和看板保持在一个位置，否则敏捷很难成功。
站会和汇报
站会很容易不知不觉就演变成汇报会议，只要你坚持做到以下的任何一点：
- SM 站的位置让所有人都面向他
- SM 总是第一个发言
- 轮流发言时，SM 总忍不住要插话
- 当阻碍出现时，没有人或者只有 SM 在想办法解决
- 阻碍的解决手段没有及时实施，比如说我承诺和你一起结对，结果因为其他紧急任务而耽搁
- 每个开发人员总是认领不同的故事，互相之间没有交集
- burndown 出现风险时没有 action
很多敏捷管理的书籍中都有关于分级授权的概念，就是说根据当前团队或者开发人员的不同程度进行不同级别的授权。道理很简单，但做到真的很难，个人对这些书的作者自己是否真的能做到持怀疑态度。
比如站会这个看起来很普通的会议，如果 SM 完全不干涉，会议就很容易形式化，每个人自顾自说3句话然后结束，但只要 SM 稍一干涉，会议又很容易演变成向 SM 的工作汇报，需要时不时的观察下站会的氛围，然后小心翼翼的决定是否要干涉。理想中站会的状态就像是立在桌面上的鸡蛋，看起来是平衡态但却极不稳定。
