一个新Scrum团队对ScrumMaster的选择会影响到团队Scrum实施的成败。选错了人，团队就会一方面试图变得自组织、另一面却又受制于命令控制型的经理，从而进退两难。选对了人，他符合新ScrumMaster的技能、满足团队初期需求，则团队在实施Scrum上有了一个梦幻般的开端。
我本来打算用这篇短文提供一些指导来说明如何选择一位适合的ScrumMaster。然而，在准备这样做时，我意识到首先需要回答一个更基础的问题：谁将来挑选团队的ScrumMaster？是团队成员自己，部门经理，还是项目管理委员会？或者产品负责人会从他们认为能工作得最好的人中挑选一位做ScrumMaster？
我的答案是，团队成员应该挑选自己的ScrumMaster。不幸的是这不是总可行的。团队成员是否应该挑选自己的ScrumMaster主要依赖于团队的Scrum实施要进行多久。多数情形下，当团队开始实施Scrum时，会有很多他们不能确定的东西。还有很多他们想反对和试着忽略或削弱的东西。例如新团队常常忍不住以低于每天一次的频率进行每日站会。他们还不习惯于和别人紧密工作，也不敢在超出个人职责外过多的冒险。假设对这样一个水平的团队说，你们是自组织的所以你们可以自行选择ScrumMaster则常常导致灾难。
相反，这些很新的团队可以从指示风格的领导层那里受益。他们需要被告知要在每个sprint末尾产生出可工作的、完成了的软件，那意味着要天天开会，潜在的可交付的则指经过测试的等等。我不是在暗示他们要接受严厉的、命令控制型的说教；而是指团队需要这样一个领导者/ScrumMaster，能在Scrum实施的这个时候告诉他们，用这种方式去尝试基础的Scrum规则是不可接受的。这些团队大概还不曾准备好去选择自己的第一位ScrumMaster。
与之不同的是，假设有这么一个团队，每个人都很融洽的与别人工作，每个团队成员都有确定的角色、但却也可为了团队的利益而胜任超出该角色的部分，而且每个人都有强烈的愿望在一开始就坚守规则。那么这样的一个团队不应该被指派一位ScrumMaster。所以谁应该选择ScrumMaster？我的默认观点是由团队来做出决定。不过一个注意事项是首先要确定团队已经为实施Scrum的初期挑战做好了准备。如果他们不存在一个可以做出正确决策的框架，或者决策权会被一个视ScrumMaster为提升权威、获取更大权力和公司更高职位的富有野心的成员夺走，那么就不要把决定留给他们做出。
当团队并不处在可以挑选自己ScrumMaster的合适位置时，我的第二意见是由对项目成功负有至关重要责任的部门经理来做出决定。我倾向于避免让产品负责人来选择ScrumMaster，因为这可能腐蚀一种本可存在于一对不错的ScrumMaster/产品负责人间的有益的紧张状态。
在后面的专栏中，我会提供一些有助于选择最佳ScrumMaster的实用建议，不论是由团队成员自己还是团队之外的部门经理来做出决定。
原文作者： Mike Cohn
原文链接：http://www.mountaingoatsoftware.com/articles/33-scrummaster
关于译者：
陈争云
目前在PTC中国研发中心的一个敏捷团队担任Tech Lead，他有近10年软件行业从业经验，曾在EMC,HP,eBaotech等知名企业任职。他擅长JAVA企业应用开发，也对敏捷开发和Scrum有浓厚兴趣，目前正帮助团队推广和实践敏捷。
