这是敏捷开发智慧敏捷的第四篇。（之一，之二，之三，之四，之五，之六）
缘起
甲：“我们每日立会会开不起来。”
乙：“嘿，我们每日立会开起来了，而且越开越长了，一开就是1个小时，净是些技术细节。”
甲：“别人等着他们讨论，那多耽误时间啊……”
乙：“我也觉得是，但是看他们交流得那么热烈，讨论的也是正事，到底应该打断还是不打断呢……”
为什么每日立会只开15分钟？
我们说绝点：每日立会只能开5分钟，而不是15分钟。
这5分钟说点什么呢？应该说必须开会才能说明白的东西。
先看两个团队，他们有什么是需要开会说明白的。
第一个团队，10个人，平时分工细致，各干各的，谁也不干扰谁。
这个团队，开会的时间肯定不短，因为所有交互问题都需要开会解决。
第二个团队，10个人，平时分成三个小组，小组内随时沟通，小组间有需要就沟通。
这个团队，开会的时间肯定短，因为三个小组长发言总结自己组的进展就可以了，会上只需要碰碰组间的沟通。
敏捷开发实际上在假设大家平时像第二个团队一样一直在互相沟通（即使不分成三个小组），但是却很少以整个团队的形式沟通整体进展，所以才创造了15分钟的周例会，当然也能顺便把忘了沟通的人链接一下。如果这个本来作为补充性质的周例会变成了组内唯一的沟通渠道，就出问题了。
所以，开会时间长，往往不是沟通充分的表现，而是沟通不充分，只能赶在会上沟通的表现。
团队应该怎样沟通？
团队应该随时就技术细节进行沟通，而不需要等待开会。而对于3～5个人的团队，组长如果除了开会居然不知道整个组的进展，那么沟通是极其不顺畅的，要解决的不是每日立会的问题，而是平时沟通的问题，比如采用师徒制度、松结对编程等（请参考其他系列博文）。
这种会议甚至在更大的规模上，也能淡化。
我们曾经试图在一个由销售、市场、支持三个部门15个人的组中间开周会，开了大约几次后就取消了，原因是我们仔细安排了位置，使得总监和三个经理一起坐在中间的大桌上，而其他队员则坐在四周。因此组间的沟通在大桌上随时就完成了（做了个4个人都能看到的大屏幕），而组内的沟通则一回脸就完成了。所以发现几乎所有的事情大家都知道差不多了，会上也只是重新说说而已，开或不开都可。
因此，应理解每日立会、计划会、评审会、反思会这些会议，都只是沟通过程的仪式化的补充，若沟通本身不畅，而只是指望这些会议完成沟通，肯定会陷入两难的境地。
“每日立会”的常见做法
1～4人团队
这个规模的团队，优先使用139团队结构和松结对编程方法，即由师傅（小组长）密切地与徒弟们沟通。这会涉及到沟通管理、时间管理、过度沟通、有效生产率等问题，在链接的系列博客中有所详述，都不是问题。
这个规模的团队应该不开立会，而是更密切的交流方式。它的运行方式更像XP，而非Scrum。
5～9人团队
这个规模的团队，优先划分为2～3个小组，每个团队仍按松结对编程方法运行。
由于人多了，组间难以沟通，所以开个立会是必要的，主要目的是组间进度沟通，因此不会发生技术沟通（这是组内的事情），所以也不可能超时。
小组长应把握好应该如何与对方组沟通、沟通什么的问题。
更大型的团队
更大型的团队，则推荐组长+小组长参与开超级立会，组员不参加。
这类会议也是进度沟通会，所以不会涉及技术沟通。
为何不让Scrum Master们开个会议？因为专职的Scrum Master不负责技术、进度、质量这些事情，真正对这些熟悉的，是团队组长和核心骨干。
后面两种会议，很像是“Scrum of XPs”，而不是“Scrum of Scrums”，前者的沟通性更强。