敏捷宣言遵循的原则，其中有一条是：
“最好的架构、需求和设计出自自组织团队。”
这个世界唯一不变的就是变化本身。从1980年以来，我们经历了巨大的变迁，比如：政治变迁、社会变迁、环境变迁等等。所有这些变迁都给我们带来了新的挑战。一个组织已经无法自主选择是否要应对这些挑战，必须要做出改变。保持现状的想法就好像试图留住秋天的落叶。换句话说，一个组织必须得跟上当前市场的要求，甚至要领先一步。这很困难，因为市场变幻无常。今天的宠儿，明天可能一败涂地。昨天赖以成功的因素，一夜之间可能成为负担。
“业务敏捷性”被证明是一个组织在二十一世纪获得成功的诀窍。这也意味着对团队的挑战日益增多，对于传统的控制型领导团队的方法已经不适应现代产品开发的需求。
根据当代的一些研究，比如德勤领先创新中心的变化指数，五个雇员中只有一个会全身心投入工作，75%的雇员缺乏动力和激情，只有15%的团队才能完全展现他们的潜力。此外，越来越多的人患上“变革疲劳症，因为很多变革动议最终都无法达到预想的目的。通常这种动议得到的回应是，“千万别再搞了”，而不是成员的积极投入。虽然没有广泛的数据支持这一点，但是各种采样调研显示，60%到80%比例的项目都终结于此。
内外部各种因素都表明我们必须要改变一个组织的运营方式。为了变得更敏捷，我们必须把权力和权威交给贴近客户的人。
唯一的办法就是授权给我们的团队。我们必须让他们竭尽所有的专业能力，不仅仅是完成工作任务，还要自我监督和控制，自己做决定，甚至设计自己的流程。这是一种自然而然的尊重。正如德鲁克在三十年前所指出的那样，知识型工作者，比如IT专家，必须要有自主权。
什么是自组织团队？
团队成员自组织决定实现冲刺目标的最佳方式。没有人告诉团队怎样开展工作，包括Scrum Master。自组织是系统自下而上、自发的属性——没有外部的统治力量采用传统的自上而下、命令与控制的管理方式。
一群大雁正在池塘边休憩，大雁在突然离开地面飞起来的时候，都会以V字形图案成群飞行。那么，它们是怎么知道要这么做的呢？你认为是否有一只叫“经理”的鸟儿在池塘边开会、指导其他鸟儿如何成群飞呢？
“大家听好了，一会儿飞的时候，我带头。你在我左后方一米的位置，你在我右后方一米的位置。其余的在后面呈扇形散开。”
可以想象，根本没有这样的会议！
成群飞行不是自上而下规划的结果！
在这个群体中，不同的个体采用不同的方法彼此交互，遵循一个简单的、局部的、在不断反馈环境下作用的规则。
成群飞行：简单规则和频繁反馈！
同样的，开发团队没有自上而下、命令与控制的权威告诉他们如何工作。相反，跨职能多样化的团队成员自组织，以最适合的方式完成工作。结果，涌现出来的是团队自己的“V型图案”，也就是团队自己的“Style”！
如何打造自组织团队？
首先，团队达到自组织的路径是不一样的：
每个团队都会选择不同的方式达到自组织。
要利用团队的集体智慧才会更容易找到适合团队的工作方式。
允许团队自组织的好处是鼓励团队自己承担工作。
另外，我们真的可以期待团队的自组织吗？
对自组织团队的一个常见的批评是：
“我们并不能随机把8个人放在一起，告诉他们要自组织，然后期待任何好的结果。”
我们不知道是否可以把8个人随机地放在一起并期待某些事情，但是团队不应该是一群人的随机集合。事实上，公司里负责引入Scrum项目的那些人，组建团队的时候在人员的选择方面应该是花了相当大的精力的。
在最初描述Scrum的文章中，Takeuchi和Nonaka将“精妙控制”作为六项原则之一，他们将人员配置列为关键的管理职责，如为项目团队选择合适的人员，监控团队动态变化，在必要的时候增减人数等。
本田的一位高管表示：“如果团队倾向激进，我们就会增加一名更加年长、保守的成员。项目成员都是经过深思熟虑的，我们会分析不同人的性格，看是否能相处融洽。”
由此可见，对自组织团队的精妙控制非常关键！
那么，到底如何打造自组织团队呢？有一些可参考的关键点：
建立团队规则
作为一个跨职能团队，重要的是：从想法到实现功能需要的所有技能，都能在团队中得到体现。这可能意味着，在最开始的时候，团队规模比预期的要大。
但是，随着时间的推移，团队中的成员，每个人都会学到其他同事所具备的一些技能，这在团队中是很自然而然的结果。当一些人开发出更广泛的技能时，另外一些人就可以转移到其他团队去了。
平衡团队的技术能力水平
根据团队的规模，应该努力平衡团队中的技能水平。如果一个团队有3个高级程序员而没有经验较少的，那么这些高级程序员就需要编写一些低临界点特性，他们可能会觉得无聊。一个初级程序员可以愉快的发现这样的功能, 也将通过与资深程序员的交流而获益。
灵活的开发团队是由T型技能的成员组成的。团队成员拥有合适的技能，覆盖各个专业领域，并且总体上技能有一些重叠。
我们应该专注于把现有人员组成最好的T型团队。然而，想一开始就能刚好找到想要的团队技能组合，是不太可能的，理想的技能组合需要假以时日在产品开发过程中日益成熟。因此，重要的是要有一个促进学习和增加技能组合的环境，不论是领域知识、专业知识、思考技能或者其他能力。
平衡团队的知识领域
我们应该试图在那些对我们所工作的领域或对我们要解决的问题有深入了解的人之间寻求平衡。
这并不是说有机会组建一个全领域专家团队而不去做，更多的是我们应该考虑我们的组织的长期目标，其中一个目标可能是在整个组织中建立领域知识。如果将所有领域专家放在一个团队中，您将很难实现这一点。
探索团队的多样性
多样性意味着很多不同的东西——性别、种族和文化等。同样重要的是个人如何思考问题、如何做决定、做决定之前需要考虑什么等等。
研究表明：同质团队比其他多样性团队能更快地达成一致，但这是因为他们没能考虑所有选择。
多样化的团队能带来更多视角，得到更好的成果。
组建团队的时候要考虑持久性
团队成员学习如何更好地一起工作是要花时间的。因此，努力让过去能一起合作的成员继续在一起，就显得非常重要。在组建新的团队分配任务时，要考虑到他们能在一起工作多久。
自组织团队常见的阻碍
1、专制的人会做所有的决定
喜欢支配的人（如技术主管）会认为自组织就意味着由他/她来做所有决定，或者在团队讨论问题前，就将自己的意志强加给团队。
如果你注意到开始发生这样的事情，就要找他沟通，让他了解：
1）即使他可能知道“正确”的情况，也应该在别人有机会发表看法之前保持克制。
2）如果将自己的想法当做一个观点而不是无可辩驳的决定，团队还能否做出正确的决定。
他的工作不应该只是做出正确的决定，还要帮助团队成员成长，使得他们能在下一个他可能不在的项目上做出正确决策。
2、团队太过被动，无法进行自组织，并且希望Scrum Master或者教练来领导他们并为他们做一些重要的决定。
如果发生这样的情况，要确保团队成员知道Scrum Master的职责是支持，而不是帮他们做决定。如果你既是Scrum Master又是团队成员，你不需要压抑自己的意见，也不必一直保持沉默。你应该想办法让其他人参与进来而不是做决定。比如：在说出意见前，先试着问问其他人的意见。
3、团队太初级，无法进行自组织
如果团队成员有足够的经验构建一个软件产品，他们就可能有足够的经验来弄清楚如何管理自己。如果没有，那就为他们提供培训和指导吧！
另外，通常情况下，这个想法隐含了 “我不相信团队能按照我的想法进行自组织”。正确的做法应该是，巧妙的控制组建的团队成员和既定目标，而不是控制他们如何组织日常工作。
