2001年11月在美国犹他州滑雪胜地——雪鸟，敏捷价值观通过一份敏捷软件开发宣言，向全世界宣告了敏捷软件开发运动的开始，至今已过去21年。在这21年中，敏捷方法在全球遍地开花，硕果累累，从最初的软件开发，逐步扩展到医疗、产品、金融、保险、银行、汽车、物流等行业。
在众多敏捷方法中，Scrum是迄今为止应用最广的敏捷方法之一，约占全球70%的市场份额。如果说Scrum是敏捷的核心，一点也不为过。Scrum之所以被大众喜爱并广受企业和个体的青睐，是因为它够简单、够灵活且容易理解、容易落地，能给组织和个人带来实实在在的改变。今天，我们来谈高效能敏捷团队组建的挑战，也是基于Scrum的框架来展开。虽然敏捷不是Scrum，但Scrum绝对是敏捷。因为Scrum包括了敏捷价值观和原则的所有方面，在引入敏捷的大部分组织中，敏捷的核心团队几乎都是Scrum团队。
一、敏捷方法与传统方法的差异及问题
在讨论构建高效能Scrum敏捷团队之前，先了解一下传统方法和敏捷方法的区别，这会让我们在构建高效能Scrum敏捷团队时有的放矢。无论是敏捷方法还是传统方法，都服务于产品管理和项目管理。产品管理和项目管理本是一家，项目管理服务于产品管理，产品管理离不开项目管理，两者相辅相成，只有这样项目才可能成功，产品才能获取应有的利润和价值。但在很多企业，将项目管理和产品管理严格划分开来，项目管理侧重产品开发，产品管理侧重市场和业务，并有各自的KPI考核指标，导致两者之间产生了不该有的鸿沟、隔阂、冲突甚至对立。比如：研发按照业务的要求保质保量完成了产品交付，但交付的产品销售不出去，给企业造成了不可弥补的损失，时有研发老大和业务老大相互拍桌子、对薄公堂的现象发生。又比如：业务为了拿单，在没有和研发沟通的情况下，给客户过度承诺，反过来又倒逼研发降成本，赶进度并按期交付，导致产品开发仓促，不能充分验证，质量问题频发，常常处于被动救火的状态。如此等等，不一一列举。这种缺乏信任、缺乏协作，相互埋怨，推诿责任的做法，给产品的成功带来了很多不确定性。
1.项目管理方法多种多样
在敏捷圈里，常有人吐槽项目管理方法，甚者认为PMI（美国项目管理协会）忽悠了很多人，害死了很多企业。究其原因，不外乎两点：
其一，对项目管理没有深刻的体会和了解，并不是每个人都有过项目经理的履历，特别是上亿资金投入的大型项目。
其二，全球比较有名的三大项目管理体系，分别是美国项目管理协会PMI、国际项目管理协会IPMA、英国OCG受控环境下的项目管理PRENCE2，三种方法体系各有侧重点。
在国内，由于PMI的大力推广，大家对PMP比较熟悉，拿PMP认证的人也比较多，大部分人对项目管理的认知也停留在这个层面。其它两种方法知道的人相对较少，这与方法本身无关，而关乎推广的意愿、力度以及背后的利益链。
在过往的项目管理生涯中，我有幸全面系统地学习过这三种项目管理方法。在这三种项目管理体系中，我个人比较推崇英国OCG受控环境下的项目管理PRENCE2方法：一是它容易落地；二是它是一种通用的方法，不受项目的规模、类型、组织、区域和文化的影响；三是它和敏捷的融合度较高，比如7大原则中持续的商业验证、吸取经验教训、例外管理、明确定义的角色和职责、关注产品等等。PRENCE2也是联合国首推的项目管理方法。
这几种方法，在过往的几十年中，对全人类做出了巨大贡献，影响深远。直到今天，仍然在与时俱进，占据着半壁江山，发挥着无可替代的作用。
传统项目管理方法和敏捷方法各有应用的场景，敏捷作为一种新的方法，弥补了传统项目管理的很多缺陷和不足。
我们抱着客观、公正的态度去看待一件事物，不因敏捷方法的诞生而去棒杀或诋毁传统项目管理方法。一方面敏捷方法尚不能全面取代传统项目管理方法，另一方面项目管理方法早已从过去的传统项目管理方法过渡到与时代相适应的现代项目管理方法，对项目管理成功的定义已不再是满足质量、成本和进度的铁三角，而是关注客户目标和业务需求，让所有相关方都满意。另外，一些新的方法也在应运而生，比如OKR工作法等。
因此，我们应抱着开放的心态，在实践中学习、探索和打磨，博采众长，取长补短，及时调整和适应，只有这样，我们才能走的更远。本文将项目管理统称为传统方法，以示与敏捷方法的区别。
2.敏捷方法的起源和核心
敏捷方法起源于软件开发，是从过去的软件开发实践和工作经验中总结和提炼出来的一套全新的思维方式和工作方法，它的核心是应对不确定性和复杂性。敏捷注重对人的关注，强调共创、开放、尊重，将以人为本，激发人的潜能放在了第一位；以价值和收益来衡量工作成果；以合作和双赢的思维来处理各方的关系；以扁平化的架构打造安全、透明、开放、具有活力的组织环境；以小团队迭代、增量的方式，快速交付，快速验证，快速学习，快速调整来应对商业和市场变化；透明，检视，调整，自组织（自管理）是团队的运作方式。
敏捷是一种从经验中学习的方法，经验主义不会带来确定性，但会让我们明白各种可能性。敏捷方法要求管理者要面对现实，拚弃不切实际的想法，放弃控制、强制和命令的方式，将自主权交给团队，将更多的精力放在赋能、帮助、指导团队，提升团队能力，激发团队潜能，移除组织障碍，优化组织机能上面，这点和传统方法完全不同。敏捷团队把失败当成机会，并从中学习，修正假设；敏捷关注和聚焦业务目标，通过及时反馈来验证方案；传统方法把失败当成意外，通过计划和跟踪来管控，传统方法关注项目指标，通过KPI考核来强化管理。
3.传统项目管理方法与敏捷项目管理方法
传统项目管理方法视计划为目标，管理者将计划视作团队的承诺并以此来考核团队，这种方式要求团队在项目一开始就做出一个全面、精细的计划，尽管此时的项目信息并不全面，需求并不完善，但这种做法在传统项目管理流程中几乎是强制性的、普遍性的。
产品开发是一种创新的过程，有着很多未知的不确定性和复杂性，因此变化是不可避免的。传统项目计划在被视作承诺的那一刻起，便失去了应对这种变化的可能性。这导致项目经理在面对变化时压力山大，面对管理者的问责时不得不移花接木，掩盖真相，报喜不报忧，投其所好，蒙混过关，然后在私下想办法应对。然而，这不仅对项目的交付埋下了诸多隐患，还让管理者看不到项目的真实状况，这是一种恶性循环，项目的失败也从这一刻开始。所以，从一开始详细计划和估算整个项目，就是一个陷阱。
敏捷方法视客户价值为目标，要求对所做的事情进行优先级排序，按优先级进行工作，先做最有价值的事情，以减少不增值的工作。同时，敏捷认为需求是渐进明细的，范围是不确定的，结果是不可知的，需要基于事实来逐步完善计划，在实践中学习，在实践中调整。
在敏捷方法中，项目一般按照2～4周一个迭代，划分成多个迭代，每一个迭代就是一个小计划，我们把这种方式叫做小步快跑。我们只对当前要做的迭代进行详细规划，这种方法很好地解决了项目过程中需求的不确定性带来的变更，这种与时俱进的调整机制，拉近了研发、业务和客户之间的距离，大大地提高了客户的满意度，增加了项目商业成功的可能性。除此以外，迭代还有诸多好处：一是要做的事情目标明确，容易规划；二是能快速获得客户的反馈，便于及时调整；三是即使出错，也是小错，不至于酿成大祸，即所谓小船好调头；四是强制排列优先级，投入产出比高；五是进度和结果可见，增强了项目的可预测性，同时有助于提升团队士气，让管理者安心。迭代中也设置了多个机制，如迭代计划、每日站会、迭代评审、迭代回顾等等，相当于一个个检查点，大大降低了项目的风险。每一次迭代，都在持续交付价值，持续暴露问题，持续改进，迭代中的每一个机制都是团队成长的一次契机。
4.传统项目管理团队与敏捷项目管理团队
PMI指南对项目的定义是项目是为了创造独特的产品、服务或成果而进行的临时性工作。PRENCE2方法对项目的定义是项目是按照一个被批准的商业论证，为了交付一个或多个商业产品而创建的临时性组织。
从全球两大项目管理体系对项目的定义可以看出，传统项目管理团队是一个临时性的组织，项目团队会随着项目的结束而解散，当有新的项目立项时再重新组建团队。对项目周期长达数年的大型项目或项目型组织来说，这可能不算太大问题，但对互联网和IT行业项目周期只有短短几个月或一年左右的项目，将存在很多隐患。首先，项目管理团队都是跨职能、跨部门组建起来的，大家来自不同的部门，有不同的技术背景，每个人的性格、阅历、习惯、爱好、价值观都各不相同，这就导致了团队在一开始不可能是高效的和步调一致的，需要经过长时间的了解、磨合，才能达成协作；图1就很好地说明了这一点。
图1： 团队发展的塔克曼模型
（图片来源参考《项目管理融会贯通》的团队建设和领导艺术）
在项目组建初期，大家带着期望，充满好奇地加入团队（也不排除可能是不情不愿被指派到这个团队的）。这个时候，大家初次合作，相互不了解，缺乏信任，存在不安全感，个人主义明显。随着项目真正开始，团队成员的差异化显现，每个人看待事物的观点、做事方法的不同，对同一件事情理解的差异等，导致各种矛盾、不满、冲突逐渐暴露无遗，团队出现了消极、困惑，甚至抵触的情绪，团队人心涣散，士气跌入了谷底。
随着项目的深入、交付压力的加大、团队领导者作用的发力，团队之间的冲突逐步得到缓解，在很多方面开始达成共识，大家开始相互包容，取长补短，建立行为规范、沟通机制、工作准则，走上相互协作的道路，团队的效率也随之提升。度过了规范期，团队开始变的成熟，知道如何协作和相互支持，大家配合默契，团队士气空前高涨，效率显著提升，变得更自信和从容，这是团队状态最佳的时期，也是产出最高的时期。随着项目临近收尾，团队凝聚力开始减弱，团队成员开始考虑自己的去向和前途问题。
高成熟度团队的工作效能要远大于低成熟度团队，而团队成熟度的提高是需要长时间打磨的，因此团队需要在一定时间内保持稳定。在传统方法中，好不容易磨合出的高效团队，随着项目接近尾声而开始解散。这种临时的项目团队，让团队成员没有归属感，缺乏主人翁意识，同时也不利于团队成长和长期发展。
在这种临时性的项目团队中，团队成员面临多个领导。一方面是来自项目经理的指令，另一方面是来自职能经理的指令，这导致团队成员无所适从，发生“妈妈说不，我就去问爸爸”的现象。就人性而言，人都是现实的，多半都是按照别人的权力高低来决定自己工作配合的优先级。由于职能经理掌握着行政权力、资源分配、团队成员的培养及奖金分配，大部分情况下，团队更愿意服从职能经理的指令。项目经理虽然承担着交付压力，但在团队成员管理的掌控上往往显得力不从心，这在矩阵型项目管理结构中显得尤为突出。
在传统项目管理中，实行的是项目经理责任制，即项目经理对项目的成败负责。这意味着从项目立项那刻起，项目经理就面临着来自各方面的压力。为了确保项目成功，项目经理必须到处“烧香、求神、拜佛”。在这种项目经理责任大权力小、资源严重冲突，项目优先级模糊不清且管理混乱的项目环境中，几乎所有与项目相关的人都是“大爷”，一个伺候不好都可能让项目阴沟里翻船。在这种铁打的部门、流水的项目的环境中，项目经理的压力是巨大的。
敏捷架构追求的是以价值驱动、自管理、端到端的小团队，这种小团队结构让团队沟通变得容易、信息变得透明。敏捷团队是具有凝聚力的专业团体，一次只专注于一个目标。团队在完成一个项目后才会承接下一个项目，以此循环，不存在团队解散的问题，解决了团队成员的后顾之忧。敏捷小团队的结构确保了团队的灵活性，提高了团队效率，使团队容易保持对目标的专注。
一个好的团队，需要时间形成统一的工作规则和团队文化。一个新的团队磨合期需要2～3个月时间，才能达到稳定期并真正产生效能，而要形成自组织、自管理的团队文化则需要更长的时间。
二、构建高效能Scrum敏捷团队的原则
敏捷本身追求的就是自组织、自管理、长期稳定的高效团队。想要打造一个高效能的Scrum敏捷团队，仅掌握敏捷方法和专业技能是远远不够的。它面临诸多方面的挑战。
从图2可以看出，敏捷团队组建的原则由以下六部分组成，分别是：团队人数限制、团队管理方式、团队特征、团队成员之间的关系，团队技能以及团队结构。
图2： 敏捷团队组建的原则（原创）
1.原则一：团队人数不超过10人
敏捷架构对团队人数的设限是一个很好的实践，因为个体的力量和团队的大小成反比。即团队人数越多，团队个体的贡献越小；相反，团队人数越少（不少于3个），团队个体的贡献就越大。
Scrum敏捷团队通常包括一位Scrum Master、一位产品负责人和若干开发人员，不超过10人。这种规模使团队更灵活，沟通更有效，能充分发挥每个人的潜能，实现效能最大化。
敏捷团队强调透明度，每个人的工作对团队可见，没有隐藏的事务。团队成员共享价值观，遵守共识的工作规则，共同为同一目标努力，共享荣誉和责任。
2.原则二：团队自管理
人类的天性充满好奇，热爱探索，寻求新方法，尝试从新事物中学习，自组织提供了这种环境。
敏捷架构提倡团队自组织与自管理，让团队成员自主决定谁做什么、何时做以及如何做。自管理要求团队每一个人不要再去考虑你是一个高级测试工程师还是初级开发工程师，你需要找到一个全新的方式来思考自己，认同自己是敏捷团队中的一员，这意味团队成员将不分彼此，为了共同的目标将密切合作，相互支持，相互帮助，完成自己工作的同时帮助其它同事承担额外的工作；与传统方法将人视为资源不同，敏捷尊重团队成员的情感和思想，激发他们的热情和责任感。
自组织意味着打破传统思维，去权威化和中心化。这要求高层管理者转变角色，
从控制者变为赋能者，建立规则而非指令。敏捷认为公开、透明的自组织团队才能最大限度发挥人的价值。
实际敏捷辅导中，我们发现很多管理者对自组织有误解，担心失去对团队的掌控。其实，自组织的前提是团队规则，并不是团队想干啥就干啥。你可以天马行空，但不是无组织无纪律，而是在高层管理者的授权和设定的边界内进行的自我管理，团队自己制定达成共识的团队工作规则，自觉认领任务，自觉承诺完成任务，自觉为团队的目标做出贡献，自觉追求工作效益最大化。
对高层管理者来说，放开手脚，默默地关注，让团队自主决策、快速成长，但在必要的时候需要进行指导和干预，以避免项目出现重大问题。
3.原则三：学习型团队
敏捷的一个显著特点就是持续学习、持续调整、持续提高。敏捷只有起点，没有终点，只有不断追求更好的过程。敏捷团队是学习型的团队，鼓励成员相互结对，相互学习，取长补短，通过持续学习和进步，提升个人价值，成为多才多能的复合型人才。
敏捷架构为学习提供了机会。如回顾会议，是集体思考、讨论和决策的过程。在此，团队成员集思广益，探讨问题，发现新视角、新机会、新挑战。回顾会议也是从失败中学习的机会，敏捷视失败为调整和进步的契机，通过复盘，从经验中学习，团队和个人离成功更近一步。
4.原则四：团队成员没有头衔
敏捷认为，保留原有的头衔会阻碍人们用新的方式进行思考，过去的光环是一种包袱，带着过去的光环，会阻碍人们前进，同时会影响人们之间的交流和关系。
在敏捷团队中，除Scrum Master和产品负责人，所有成员都被称为开发者，不管你是开发人员、测试人员、架构师还是UI工程师。这种统一的称呼有助于拉近团队成员的距离，更利于团队自组织。在这种关系中，团队成员没有等级之分，编写代码、测试、文档编写和向客户交付价值都是所有人的共同责任。
5.原则五：团队具备完成项目的所有技能
差异化代表团队成员各有所长，全栈式代表团队成员一专多能，多才多艺，敏捷提倡团队成员成为掌握多个技能的多面手全才，意味着团队每一个成员或某几个成员具备产品分析、设计、开发、测试的多项能力，这可以大大地缓解团队对人才需求的压力。所以全栈士是敏捷团队追求的一个目标。
6.原则六：跨职能的特性团队
敏捷团队是围绕客户价值而组建，不存在导致延迟的依赖关系，是一个端到端的特性团队。
特性团队是一个自组织的、跨职能的、跨组件的、在同一地点工作的、长期稳定的团队。团队具备交付产品开发所需的所有知识和必备技能，工作会贯穿整个架构的所有层次，能独立交付客户价值。特性团队能够更好地评估设计决策带来的影响，提前发现设计中的隐患，同时特性团队减少了工作交接带来的浪费。
传统团队围绕体系结构而建，是一个组件团队，关注技术和任务，团队相互之间存在交错的依赖关系。它的优势是在技术方面更专业，便于技术研究和发展。缺点是单个组件团队以完成任务为目标，不能交付产品特性，需要靠多个组件团队的共同努力才能交付产品，会造成产品在进度和质量方面的风险。
从敏捷团队组建的六个原则可以看出，无论是自管理、特性团队、全栈式开发人员，还是团队成员的无职称，要完全落实这些理念是有诸多挑战的。
首先，我们来看下自组织。中国80年代的土地承包责任制是一个成功的实践，打破了大锅饭，自给自足，多劳多得，启发了人们的斗志和激情，帮助农民快速脱贫，过上了好日子，这种成功的实践是一种破旧立新的变革。
企业实现自组织也一样，需要变革的勇气、完善的制度和高素质的团队。自组织需要明确的边界设定、授权、绩效考核机制、责权利分配，以及共同价值观、使命和愿景。招聘时应重视这些，同时，需要更高超的领导艺术，管理者更要转变观念和管理方式， 所以自组织是我们努力的一个方向。
特性团队即敏捷团队，专注于交付客户价值，要求具备全栈能力，独立完成产品开发。然而，能做到这点的企业寥寥无几。培养全栈人才需时间，且不是所有企业能为每个敏捷团队配备架构师、UI工程师、BA等角色。通常这些角色在团队间共享，甚至一些技术大牛、大神都被企业供养。所以，要实现真正的全栈敏捷特性团队，还有很长的路要走。
最后，再来看敏捷团队成员无职称问题。让所有人放弃原有的职称，这是一个大胆的实践。职称通常代表能力、成就和收入水平，职称越高个人优越感和话语权就越强。取消职称，虽然它还存在于薪酬体系中，但很多人会因为它的取消而感觉到不舒服。这种落差也会在后续的工作中表现出来，这对团队领导者来说，也是一个需要化解和面对的挑战。
三、Scrum敏捷团队成员的挑选
敏捷的文化是人才重于流程，创新高于效率，自由多于管控。Scrum团队传承敏捷文化，在组建时就寻找有意愿、能力、态度的人才，价值观和理念相符，乐观进取，充满激情，技能互补，坦诚无私，认可团队文化和工作方式。
高效能敏捷团队遵循精英原则，因为敏捷团队是一个集体承诺的团体，一个表现欠佳的人，会拉低整个团队的绩效。敏捷追求速度与灵活，组织给予团队更多的信任和自由，让团队充分发挥潜能，但这也同时意味着团队要承担更多的责任。
团队要珍视组织的信任，当信任用完的时候，也意味着自由被收回了。信任是相互的，管理层需信守承诺，帮助团队移除组织障碍。敏捷团队不设项目经理，其职责分别由开发人员、产品负责人和Scrum Master来分担。敏捷团队中的这三个角色与传统不同，思维方式和工作方法都是全新的。因此，挑选敏捷团队成员对组织和团队来说都是一个不小的挑战。
1.开发人员的挑选
开发团队的使命是交付产品增量，对产品交付和质量负责。团队成员应志趣相投，有共同愿景和使命，相互鼓励、信任、帮助，共同创造价值。所以，敏捷团队挑选的是愿意改变的人，愿意学习的人，希望成长的人，愿意探索，并愿意为之付出努力的人。
开发人员的选择，可以选择激情洋溢的菜鸟培养，也可以选择技术大牛直接发力，但有一个前提是要有合作和团队精神。有人会问，技术大牛一般都是很有个性的，为什么要加入你的团队？要让大牛心甘情愿加入你的团队，得用优秀的团队来吸引。优秀的团队包括：良好的团队氛围，有特色的团队文化，超前新颖的团队工作方式，团队中有一帮优秀的人等等。通过这些去吸引技术大牛，让他们觉得这是一个有梦想有激情有前途，创新务实的个性团队 。
也可以通过招聘方式去引入技术精英或大牛，但招聘技术精英和大牛不易，成本高。所以，企业应内部培养敏捷人才，改善文化、管理、薪酬和工作环境，吸引和留住人才。
2.产品负责人的挑选
产品负责人的使命是建立并阐述产品愿景（为什么做）、定义产品功能（做什么）、输出排列好优先级的产品待办事项列表、参与产品设计和规划、管理产品待办事项列表、驱动产品走向成功。产品负责人是产品的决策者，有权就任何和产品相关的需求、时间表、预算做出决策，同时负责最大化产品投资回报，对产品的成功和失败负有最终责任。
产品负责人应具备业务和领域知识，从经济视角权衡问题，定义和收集客户和市场反馈，促成与客户之间的谈判，决定产品的发布内容和日期，并澄清产品开发过程中的需求问题。此外，产品负责人还需拟定产品验收标准，并验收产品交付成果。在敏捷团队中，产品负责人承担了一部分项目经理的职责，负责管理项目，对产品全流程负责，包括需求、开发、推广等生命周期的各个过程，并向高层汇报项目进程。
产品负责人最核心的能力就是让正确的事情不断发生。作为产品的源头和方向者，产品负责人一旦方向错了，后面所做的一切都白费。比如：对开发人员来说，伤害最大的就是无比快速、完美地完成了一件不该做的事情。
产品负责人需要与所有人合作，包括客户、干系人、第三方合作方、开发人员、Scrum Master等等。面对团队时，产品负责人是客户和干系人的代言人；面对客户时，产品负责人是团队的代言人。产品负责人必须具备远见、责任感、担当、抗压性、凝聚力、决断力，以及良好的交际和沟通能力，能和团队一起工作，风雨同舟。
那么，哪些人适合做产品负责人呢？
（1）产品经理是首选的理想人选。产品经理在产品管理方面具有得天独厚的天然优势，所要做出的改变就是转变传统产品经理的观念、思维方式和工作习惯，学会用敏捷的方式来思考和做事，并需要具备管理项目相关的知识。
（2）项目经理也是一个不错的人选。项目经理综合能力较强，团队管理经验丰富，对产品开发流程轻车熟路。他们具备业务视角，在企业和客户中有一定的影响力，但需要提升产品管理能力和敏捷思维方式和工作方法。
（3）最后一个是职能经理和技术专家。大部分企业的职能经理都是从技术专家晋升而来，职能经理属于中层管理，过去也曾是一方的大佬，有丰富的管理经验、广泛的人脉关系和群众基础；也是某一方面的专家级人物，集影响力和号召力于一身，是产品负责人的又一个不二人选。但他们也面临着和项目经理同样的问题，需要提升产品管理能力，学习敏捷的先进理念、思维方式和工作方法。
当然，产品负责人的选择并不局限于以上这三种，招聘大神也是一个选项。敏捷对产品负责人的要求虽然很高，但对于敢想敢干，立志要成为杰出产品负责人，并勇于在实践中学习和刻意打磨的人来说，一切皆有可能。
在敏捷的教学和辅导中，经常有小伙伴提出疑问，如产品负责人兼职导致经常找不到人、决策慢、不懂业务等等。针对这些问题，我们要综合分析，是能力问题、态度问题还是机制问题。只有分析清楚问题的根源，才能对症下药。很多团队敏捷做得不好，与缺乏好的产品负责人有直接的关系。
3.Scrum Master的挑选
在敏捷团队中，相对开发人员和产品负责人而言，Scrum Master是一个全新的职位，也是Scrum独有的一道风景。首先，Scrum Master不是项目经理、协调员、团队经理、保姆、秘书、管理者、纪律制定者，他没有管理头衔，不代表团队做决定，也不对产品交付负责。他更像是一个促进者和教练员，服务于团队和组织，帮助企业和团队获得成功。
Scrum Master的职责包括以下几点：
（1）利用自己的专业知识和技能，带领和辅导组织采用Scrum，推动组织进行敏捷转型，催化变革，使其生根发芽，开花结果。所以，他要确保每个人都理解并遵循Scrum的价值观、原则和实践，并按照Scrum的方式来行事。
（2）和产品负责人组建Scrum团队，确保团队按照Scrum规则运行。按需推动和引导Scrum会议及流程，激励和辅助团队高效协作，将团队推离舒适区，不断挑战团队极限，使团队潜能最大化。同时，保护团队免受外部干扰，帮助团队移除障碍，致力于团队发展及团队技术卓越。
在带领团队时，Scrum Master更多是引导而非控制，轻推而非强迫，帮助而非指责。我们知道，一个人要融入一个新的团队本就不易，要带领一个新的团队就更难。如果没有权利还要带好一个新团队，那更是难上加难。其实，Scrum Master就是这样一个角色。
那他靠什么带领团队呢？江湖上有句话叫做：“没有三两三，岂敢上梁山。”那么，在敏捷的江湖中，Scrum Master需要具备什么样的能力呢？
（1）Scrum Master必须是Scrum大师或者敏捷大师，有着丰富的敏捷经验，见多识广，这样才可能担负起培训、辅导和指导团队的职责。
（2）Scrum Master必须具备业务能力和相关领域技术知识，最好是某一方面的专家或者权威。技术人员一般不崇尚权利但认可权威。这是Scrum Master融入团队的通行证和望远镜。只有深入团队，了解团队，步入深水区，才可能发现“新大陆”或者“死亡峡谷”。Scrum Master是一个高瞻远瞩、充满智慧的人，要让自己始终保持领先其他人一步，并超越日常现实去思考，想团队所不曾想的，急团队所不曾急的事情。所以，Scrum Master还应该是梦想家和探险家，带领团队探索更多的可能性。
（3）Scrum Master应该具有一定的影响力。《Scrum指南（2020版）》对Scrum Master的定义是一个真正的领导者。在大多数企业中，有太多的管理者而缺乏领导者，可悲的是很多人将两者混为一谈，更有管理者将自己标榜为领导者。管理者和领导者一个主要区别：前者更多是按规则做事，按流程做事，管控多于辅导；而后者更多是通过引导、教练、激励、帮助他人发自肺腑，心甘情愿，自动自发地做事。Scrum Master是一个服务型的领导者，帮助团队拓展视角，培养知觉，化解矛盾，建立信任，为团队指引方向。
大多数情况下，Scrum Master靠的是它的专业技能、教练技能和引导技能。所以，Scrum Master通常是观察者和聆听者，常常听多于说。他会给团队足够的空间，让团队成长，他常常会用强有力的提问启发团队，让团队自己思考，自己
寻找答案，非必要不进行干预。图3展示了Scrum Master要具备的软实力。
从以上我们列举出的对Scrum Master的定义、职责范围和需要具备的能力，我们可以看出，要想做好Scrum Master并不是一件容易的事。
图3： Scrum Master要具备的软实力
（图片内容参考Rachel Davies & Liz Sedley ·Agile Coaching）
在敏捷团队中，开发人员、产品负责人、Scrum Master三者之间是一个平等的关系，没有谁更重要，也没有谁高人一等，每个人都是团队的中坚力量，大家彼此独立但又相互协作。产品负责是团队的领航者，确保正确的事情在团队内持续发生；开发人员是产品的交付者，确保每个迭代都有正确的，质量可靠的产品增量交付；Scrum Master是团队的政委，确保团队遵行Scrum规则，充满斗志和激情，始终在正确的道路上前进。
那么，哪些人可以做Scrum Master呢？在敏捷转型过程中，从影响力、人际关系，团建能力方面来说，项目经理、职能经理、产品经理、质量经理、PMO成员等转型为Scrum Master是比较有优势的，但要经过系统的敏捷知识培训和实践，同时也要学习教练和引导技能。当然，其他任何人都可以成为Scrum Master，当一个人发自内心想要做出改变，并为之付出努力时，成功就在开始向他招手了。
在敏捷转型过程中，很多企业并未重视Scrum Master这一角色，对其定位也很模糊。大部分企业将Scrum Master当成了一个可有可无的协调员，甚至常常由无足轻重的成员担任Scrum Master，好像任何一个人拉出来都可以担任Scrum Master，兼职Scrum Master也是一个常态。这也是很多企业敏捷转型失败的一个关键因素。Scrum Master空降兵在一些企业中很有效，但在另一些企业中却难以让人满意。这有多方面的原因，与企业敏捷转型的阶段相关，也与企业文化相关。
四、创造团队工作环境
好的工作环境并不意味着有宽敞明亮的办公室、有青山绿水围绕、有高尔夫球场、有美味佳肴、各式各样的水果和香喷喷的咖啡，而是在于周围都是才华横溢的优秀人才。他们具有合作精神、开创精神，活力四射，让你能在学习、交流中不断进步。敏捷做得好的企业会建立敏捷社区，到处都是可以交流、讨论和学习的圈子：Scrum Master交流圈、产品负责人交流圈、开发者交流圈、需求分析师交流圈等等。
好的环境应便于团队随时随地交流和讨论，敏捷提倡团队成员坐在一起工作，而不是让每个人都封闭起来，坐在单独围起来的办公隔档里。在互联互通、信息涌集的大环境下，90后甚至00后已成为企业的主力军，他们有想法，喜欢探索，崇尚个性，更喜欢现场体验感，喜欢有个性有特色的团队标识，团队拼搏口号，团队蓝图，并以此为荣，以此为豪，他们喜欢在充满友谊，彼此尊重的环境下释放自我，发挥自己的才能，喜欢有挑战，能体现个人价值的工作，并以此为乐。但企业中的各种不成文的规则和流程，逼迫人们循规蹈矩，按部就班，这扼杀了他们的热情、好奇和探索的天性。敏捷使这一切发生了改变，管理者应放下传统胡萝卜加大棒号令天下的管理方式，放下身段，学习敏捷方法，转变思维和观念，和团队联结，打造能发挥团队创造力的工作环境，以此来激活团队，提升企业绩效。
好的环境意味着安全、轻松，公开、透明。管理者不要老是去盯梢，看谁加班了，谁没有加班，也不应关注员工的工作时长，考核员工也不应看他是否努力工作，因为工作是为了创造价值而不是取悦领导。员工只有在自管理，没有后顾之忧，没有思想包袱的时候效率最高。所以管理者要给团队发挥潜能的空间，让团队可以放开手脚，心无旁骛地去做事，并按照自己的状态安排工作节奏。
敏捷要求团队成员坐在一起工作，便于团队成员面对面交流，面对面交流是一种最快速，最有效的沟通方法，在面对面的交流中，可以通过对方的语言、语气、表情、手势，眼神来加深对所要沟通事情的快速理解。在项目管理中，沟通不畅永远是项目失败的主因。但在职场中，很多人都喜欢用邮件来沟通，目的就是为了使沟通留有证据。邮件是一种很低效的沟通方式，一是不能及时回复，二是往往需要反复好多次才能得到想要的结果。但在缺乏信任的企业环境中，这是一种通用的做法，为的是保护自己的同时给对方以压力，以促成需要解决的事情。因为邮件有抄送功能，可以抄送给任何想抄送的人，包括企业高层领导。
在传统管理中，常有一种现象：“一鸟入林，百雀无声。”大家正讨论得热火朝天，领导一进来，大家立刻安静了，没人说话了。为什么会这样呢？因为人们只有在感觉安全的时候才会进行关键对话，敞开心扉，畅所欲言。而领导的参与，关上了讲真话的大门。管理者要给团队创造透明的环境，透明的环境意味着所有的工作信息都是对团队开放的，目的是让真正做事的人，在第一时间，获得第一手资料，做出最正确的决策。
很多组织在敏捷转型过程中，团队已经在敏捷的路上干的热火朝天了，但绩效考核、相关的工作和业务流程沿用的还是之前那一套，无法和敏捷的工作方式接轨。成为了团队敏捷前进路上的绊脚石，这会导致敏捷转型无疾而终。敏捷转型带来的变化和现有流程机制存在一定冲突，需要不断改进现有机制和流程，逐步过渡到新的敏捷流程，逐步做到此消彼长，这是管理者的职责。一些企业在敏捷转型初期保持传统方法和敏捷方法并行的做法，虽然有点谨小慎微的感觉，但不失为一种过渡的办法，但终究不是长久之法。如果长期并行运行，有可能将好不容易扶持起来的敏捷团队打回原形。所以，敏捷团队是需要培育的，包括适合团队发展和成长的工作环境。
五、改变组织文化
随着敏捷逐渐成为主流，越来越多的企业开始尝试敏捷、拥抱敏捷，进行敏捷转型。很多企业安排骨干人员参加各种各样的培训和教练课程，请外部敏捷专家到企业给员工进行辅导，并帮助组建企业内的敏捷团队。在这个过程中，一些团队表示收获颇丰，但另一些团队却并不理想，他们得到的仅仅是“聊胜于无”的结果，甚至更糟。这些团队也因此将敏捷打入了“冷宫”，回到了之前的瀑布模式，并对敏捷失去信心。
为什么会出现这两种截然不同的结果呢？原因有很多，但最主要的是因为很多企业只有敏捷的形，没有敏捷的魂，而这与文化相关。
大多数企业的文化都是自然发生的，其中老板文化就是这样来的。当然，很多企业在成立之初都制定了企业的愿景、使命和理念，比如公开、信任、双赢。但随着企业的发展，很多企业丢失了初心，只剩下口号了。
记得我在企业任职项目经理的时候，一次全员大会上，CEO说有一个很重要的项目，只要那个团队能在四个月内交付，就给这个团队奖励100万。当时全场鸦雀无声，但研发人员和项目经理私下讨论：“你先把100万给到团队，看团队能不能做出来！”这说明员工对公司领导缺乏信任，认为这是领导在画大饼，听听可以，千万别当真。
其实员工是很聪明的，他们不会轻易相信上司说的话，他们更看重上司是如何做的。在传统管理中，领导们都是很健忘的，作为下属的你，只能忍气吞声。很多企业的文化是表面一套，员工心中一套。
假如你是一个项目经理，有一天，领导找到你，并拍着你的肩膀说：“兄弟，现在有一个很重要的项目，进度很紧急，我们希望你能来带领这个项目，我们相信你有这个能力，我们会全力支持你。”这时候，你千万要冷静，说不定这个项目就是大领导拍脑袋的一个决定，让二领导来执行，然后找到了你。如果你拍着胸脯保证，你很可能就掉到坑里去了，最后的结果可能是你把团队逼疯了，把自己给逼死了，还让领导拍着桌子大骂，最后不得已自己拍屁股走人了。这种事情在很多企业都上演过。在职场中，你会发现新招聘进来的人员都很勤奋、很积极、很容易合作，求知欲和很上进心很强。但随着时间的推移，他们被糟糕的领导和恶劣的环境击败了，耗尽了对创新的热情，耗尽了对优秀的追求，开始变得愤世嫉俗，最后同流合污——我把这叫环境的污染。
在很多组织中，透明就是一句空话。例如，平衡干系人之间的权益看似简单，实际上困难重重。在职场中，很多领导根本就不告诉你他究竟在想什么，甚至不愿意让你看出来他在想什么，而你只能察言观色，心领领会，凭空揣测。在一些公司，加班已成为了一种潜规则。尽管没有人让你加班，你也没必要加班，但你又不得不去加班，因为大家都在加班。你不加班就很可能被当成了没事干、不积极、没责任心的人。大部分时候，加班是做给别人看的、给领导看的，而不是真有紧急的工作要做。大家彼此相互消耗，心知肚明，但却没有人去点破——这就是文化的力量。
在企业的日常管理中，当有问题产生时，人们通常不是先去解决问题，而是急于寻找责任人；不是去分析问题背后的深层原因和组织问题，而是将错误归结为某个人并对其进行责罚。还有很多管理者喜欢粉饰和掩盖真相，甚至把下属的反馈视作给自己的一记耳光，并在后续的工作中处处刁难。在这样的组织文化中，一切的积极因素都被扼杀在了摇篮中。
在敏捷的世界里，我们允许团队犯错误，但不要犯低级错误，而要犯有益的错误。如果团队没有犯错误，则表明他没有承担足够的有益的风险，可能会消失在平庸的海洋之中。
很多企业在敏捷转型中，纠结是文化先行还是技术实践先行，这种纠结是没有真正理解敏捷的精髓。敏捷本身既不是方法论，也不是框架，而是一套由价值观和原则组成的一组实践，反映的是关于价值交付的一种思维方式和工作方法。
很多企业将敏捷作为一种方法引入，应用了其中的一些实践和工具，但忽略了它的价值观和原则以及需要转变的管理方式、思维方式和工作方法。还有一些企业认为Scrum很简单，他们没有调整自身企业文化以同步Scrum的价值观和原则，而是拆解和修改Scrum，以适应自身的企业情况。
敏捷对个人来说是一次突破，对团队来说是一次蜕变，对企业来说是一次重生的机会。但很多企业却忽略了敏捷最核心、最本质的部分，这部分恰恰能够给企业带来深远的影响。这是很多企业敏捷转型收获有限，效果不佳，甚至频频失败的原因。如图4，很直观地说明了敏捷转型的场景。
图4： 敏捷转型场景
（图片内容参考Anthony Murphy · All rights reserved）
很多企业的敏捷转型都集中在下半部分，即工具、流程、实践这一块。因为实现起来容易，参与的基本都是团队层面的人员，还触碰不到企业的敏感神经，所以阻碍很小。而且短时间内就可以看到效果，我们通常把这叫“成功区”，团队敏捷大都在这个层次，也是我们经常挂在嘴边的Doing Agile。在这个区域，团队的重点放在了在技术实践的应用和技术能力的提升上面，思维的转变还在初级阶段。所以转型影响面小，收获也有限。
上半部分涉及到思想观念、思维方式、工作方法、企业文化、组织结构等方面的调整和转变，会进入企业变革的深水区，其范围广、面积大。可能会碰触到一些人的核心利益，导致反对和抵触，使得变革困难重重，很难推进。但如果能在这个区域突破，对企业来说影响和提升都将是巨大的。很多企业的敏捷止步不前，就是阻碍在了上半部分的区域，我们把这叫“失败区”。
很多企业敏捷转型没有涉及到上半部分：一是可能还没有感觉到很痛，还不至于去刮骨疗伤；二是可能时机还不成熟，不足以大刀阔斧的变革。还有一些企业可能还没有真正的看懂敏捷，还处在懵懵懂懂、似是而非的状态，还在试水和观望阶段。也有很少一部分企业实现了全区域的敏捷转型，即Doing Agile + Being Agile，在业界独树一帜。
所以我们说，在敏捷转型的路上，你的圈子有多大，你的成就有多大。这就好比在下半区的你还在开小汽车奔跑，而步入到上半区的他已经在开着飞机叱咤风云。就目前而言，在敏捷转型的路上，开小汽车的仍然是大多数，而只有极少数开上了飞机。
前途是光明的，道路是曲折的。构建高效能的Scrum敏捷团队，需要有与之配套的企业文化，需要务实有魄力的领导者，需要有与之相适应的工作环境，需要卓越的产品负责人，需要优秀的Scrum Master，更需要充满活力、勇于进取、功底深厚的开发人员。这些都不是一蹴而就的事情。任何事情都有其发展规律，急于求成往往弄巧成拙，坦诚地对待变革中的困难，相信通过我们的努力，明天一定比今天更好，并把这看成一种生活方式，变成思想和行动的习惯，那我们就离成功不远了。
作者：杨明
