但凡谈起敏捷团队，我们总是会想到“自组织”这个概念。实施敏捷的团队，产品交付质量与效率都有大幅提升，但这样的团队就一定是“自组织”化的团队吗？
敏捷试点团队初见成效
先分享一个案例：某公司决定启动新项目，并尝试采用Scrum的流程来进行开发。
其中的Scrum Master职位由比较资深，且对敏捷开发有不错认知的原项目经理担任。
在推行了一段敏捷开发，经过几个Sprint之后，试点团队取得了初步的成功。产品交付效率和质量都有了大幅提升，团队成员对敏捷也有了比较高的认可，该项目最终的交付产品达成了预期目标。
公司管理层及团队成员都非常欣喜，有鉴于此，想要进一步扩大试点团队的规模及覆盖面，但是在该项目临近尾声的时候，却也冒出了一些不太好的苗头：
1. 每日站会，计划会议，验收会议，回顾会议等各种会议，如果Scrum Master不召集就不会召开。
一些团队成员由于前一天加班较晚，结果第二天发生了晚到的情况，当天的站会因为人员不齐就不了了之了。
这其中最明显的就是回顾会议，它已经变得越来越索然寡味，了无生趣，大家觉得各方面已经不错，没什么亟需迭代完善的。
随着项目的持续推进和深入，回顾会议的价值却在不断被弱化，没人觉得有何大碍，更没人站出来指出隐患。
加之担任Scrum Master的是项目经理，一旦他临时参与一些其他重要会议，与此发生时间冲突的敏捷各项会议，因团队内部无人张罗组织，自然也就不能按时召开。
2. 团队经常受到紧急需求困扰，导致迭代计划与交付难以展开。
很多时候，高管强行安排新需求，打断团队之前的开发节奏，经常能听到领导说这样的话：
这个新需求，已经答应客户了，所以需要紧急处理，要求一周后交付，其他的先暂停一下。
团队成员也从刚开始的抱怨，变成了习以为常，迭代计划和交付拖期时有时无的在发生，大家也都觉得很正常，没什么大惊小怪的，毕竟人家是高管，自己说再多也是白搭。
3. 团队中开发与测试位于不同的楼层，平时沟通都是用社交聊天软件，缺乏应有交流。
受制于社交聊天软件，开发与测试的同事线下面对面沟通的机会较为缺乏，充其量就是在每日各项敏捷会议时有些互动，但毕竟时间有限，项目同步性或多或少已经受到一些影响。
以上这些不太好的苗头，在很多敏捷团队都屡有发生，但是因为对最终的产品交付尚未造成比较大的影响，也就没人觉得要上纲上线，指责Scrum Master,或是团队其他成员的不是了。
可是究竟是出了什么问题，才会导致出现这些隐患呢？
我们的团队怎么了
乍一看，该公司的试点团队在敏捷推行方面已经初具成效，可是为什么仍然会冒出那些看起来不好的苗头？其症结就在于：团队的“自组织”出了问题，才造成虽然试点团队取得了初步成功，却离团队“自组织”越来越远。
为什么这么说呢？我们来看一篇堪称敏捷思想鼻祖的文章《The New New Product Development Game 》中是如何定义“自组织”的呢？
一个群体具备三个条件时拥有自组织能力：自治、自我超越、正向交互。在我们对多个新产品开发团队的研究中，都发现他们具备这三个条件。
而在案例中，领导直接命令，注重审核，是根据命令让团队执行的他组织下形成的习惯，这其实已经犯了团队“自治”的大忌。
在《The New New Product Development Game》中写到：
团队自治要求总部的参与仅限于在开端提供指导、金钱和道德支持。在日常的基准上，高层管理者很少介入，团队可以自由地设定自己的方向。
在某种程度上，高层管理者充当风险资本家。或者正如一位高管所说：“我们打开钱包，但保持闭上嘴巴。”
案例中，团队成员从起初的抱怨到习以为常，也是因为此前一直处于他组织的状态下，接受指令，按部就班的执行，从而形成了固有的行为和思维习惯。
敏捷中的各种会议（仪式）都是团队被动执行，为了向Scrum Master交代而执行的，团队并没有使用这些工具来不断提升自己，也就是团队成员”自我超越”出了问题。
在《The New New Product Development Game》中提及：
自我超越要求项目团队表现出对“极限”永无止境探索的专注。从最高管理层提出的指导方针开始，他们开始建立自己的目标，并在整个开发过程中不断提升它们。通过追求起初看起来相互矛盾的目标，他们设计出了颠覆现状和重大发现的方案。
自组织，要求团队成员每个人都要为负责，而不是“无为而治”全凭大家即时的想法。在执行“人人负责”的过程中，建立自己的目标，不断提升自我，实现自我超越。所以当发现Scrum Master不在时，团队成员每个人都应该去想如何去组织会议，而不是没人组织那自己也无所谓。
这就像夫妻两口子过日子，目标都是让日子过得更好，双方都要为此而建立自己的目标，也都要为此而负责，而不是遇到事情的时候，一看你不管，那我也不管，这日子肯定过不长远。
敏捷团队中的沟通出现问题，团队没有坐在一起形成不了团队立场，团队成员没有彼此交谈所以出现不了主动性，这其实是团队“正向交互”出了问题。
在《The New New Product Development Game》中有载：
正向交互，要求一个项目团队的成员包含不同的功能的专家、思考过程和行为模式执行新产品开发。
虽然选择一个多样化的团队是至关重要的，但是直到成员开始交互，正向交互才真正发生。这个步骤遵循以下的基本原理：“当所有团队成员都位于一个大房间时，甚至不需要努力某个人的信息就变成你的。然后，你开始思考什么是对团队最好的或第二好，而不仅仅是站在你的立场。如果每个人都理解对方的立场，那么我们每个人都更愿意让步，或者至少愿意尝试彼此交谈，也才能生发主动性。”
自治，自我超越，正向交互，作为自组织团队必备的三大条件，并非孤立存在，而是两两之间存有微妙且有机的联系。
建议
1. 让高管保持“我们打开钱包，但保持闭上嘴巴”。
管理层的工作是给予团队合适的任务，并帮他们移除障碍。也就是说对团队限制和控制越少，结果就越好。
如果领导层过分约束团队解决问题的方法，就不会有自组织团队。团队将停止思考，因为已经告诉他们太多的解决问题的细节。告诉他们如何做，接下来的部分他们也会等别人来告诉他们。
2. 给团队一个好的目标，并激发他们。
最高管理层通过发出一个广泛的目标或一个总体的战略方向来启动开发过程。它很少提出一个明确的新产品概念或具体的工作计划。但它为项目团队提供了广泛的自由度，同时也建立了极具挑战性的目标。
管理层与领导者通过激励员工，并给他们挑战，来提供支持自组织和演化的能量。这些挑战创造了产品的当前状态和预想状态间的差距，或是创造了团队当前绩效和期望绩效间的差距。当团队受到激励并接受挑战时，他们会为了克服挑战而自组织起来。
3. 确保团队的沟通
尽最大的努力让团队坐到一起“当所有团队成员都位于一个大房间时，甚至不需要努力某个人的信息就变成你的”。
如果团队不在同一个办公地点，那么你必须花费更多的金钱来创造团队面对面沟通的机会（Mike Cohn曾在其著作《Scrum敏捷软件开发》中提到联络访问和旅行大使就是针对此问题提出的解决方案）
4. 给他们时间，他组织力突然消失之后，自组织力并不能很快成长起来。
这个过程需要时间。这种自组织力一开始是很孱弱的，但它是“时间的朋友”。这个循环运行的时间越久，自组织力越强。
但从反面来看，自组织力的形成有个时间的滞延。它不像他组织力那样召之即来挥之即去，它要从无到能发挥作用得给足时间。
Mike Cohn博客：《Self-Organizing Teams Are Not Put Together Randomly》
原文地址：https://www.mountaingoatsoftware.com/blog/self-organizing-teams-are-not-put-together-randomly
