20年敏捷经验，为你揭秘如何成为优秀的Scrum Master

前言

你想成为一名出色的Scrum Master吗？

我希望答案是肯定的（除非你是产品负责人或者其他角色），我已经担任Scrum Master 20多年了，在这么长的时间里，我给出和收集到过相当多的建议，我把它们概括成为如下的“十佳建议”给到大家。

没有事先征询团队意见的情况下，不要揽活

作为Scrum Master，你无权代表团队接受变更请求（无论有多小）。即使你确信团队可以满足这个要求，也要说：“这个必须要征询一下团队意见再给你确切的答复”。

在没有事先与团队成员沟通的情况下，一定不要帮团队承诺截止日期，交付物或其他任何事情。你可能并不需要与团队所有人进行沟通，有些团队允许部分成员无需召开全体会议即可做出决定说：“没问题，这个我们可以做”，但这依然是团队的决定，而不是你个人的。

记住你的作用是帮助团队有好的表现

成为Scrum Master并不是要让你自己看起来很好。当团队看起来很好的时候，你自然看起来也不会差。而想要团队看起来很好，只有帮助团队出色地完成工作。

当团队以外的人开始考虑是否还需要你的时候，就说明你已经做得很棒了。当然，如果是你的老板在怀疑你的必要性，这听起来会很可怕。但是优秀的老板都会知道，只是因为你的专业知识和技能让你看上去不被需要，而实际上你是不可或缺的。

相信你的老板可以分得清楚看起来不需要和真的不需要。

不要用教条的规则来限制团队

Scrum和敏捷都没有附带规则手册（尽管有些人在试图创建这些玩意）。

如果你的产品有用户，请考虑编写用户故事，但是敏捷不等于必须使用用户故事；如果有人需要知道什么时候能够交付，那就做个估算，反之则不一定需要；如果你认为在Sprint结束的时候做评审就太晚了不能及时收到反馈，那就在每个功能构建完成的时候分别做一次评审。

所谓敏捷就是遵循那些原则和价值观，是它们创造了敏捷性。如果坚持这些原则和价值观，那么不管别人和你说什么，你都不会误入歧途。

没有什么是一成不变，请不断试验你的工作方法

试验工作方法是遵循敏捷原则的一部分。要鼓励你的团队去尝试新鲜事物。

他们是否喜欢两周的Sprint，并认为自己做得很完美？非常好，那你可以让他们去尝试下1周或3周的Sprint并观察结果。这样的试验可能并不总是受欢迎，但这才是确保你能持续发现更好更新的工作方法的最佳方式。

确保团队成员和干系人之间是互相平等的

对于一个产品开发计划，团队成员和业务侧的干系人都会有各自角度的关键考量。因此，每一方都需要被同等重视。

如果任何一方需要容忍另一方的话，整个组织都会遭受损失。开发团队需要理解干系人的独特视角。相应地，干系人也需要尊重开发团队，比如在开发人员说某个截止日期不可行的情况下能够去聆听他们的想法。

竭尽所能地去保护团队

Scrum Master需要保护团队不受过于苛刻的产品负责人或干系人的干扰，这可能是最常被提起的一个建议。这的确是个好建议，有时候产品负责人只是单纯地对团队要求得太多，太频繁，太激进，就使得团队不得不走些“捷径”，通常是牺牲掉质量，然后就会让这个项目更加困难。因此，出色的Scrum Master应当保护团队以避免这种情况的发生。

但是，你可能很少听到的是，一个出色的Scrum Master还应该“保护”团队以避免产生自满情绪。因为优秀的敏捷团队会不断地寻求改进。而普通的团队也许会在不知不觉中安定下来，认为自己已经足够好了，而且他们可能确实比了解敏捷之前要更快更好。然而，优秀的团队只会变得更卓越。

出色的Scrum Master可以避免团队产生诸如“我们已经没什么要学习和长进的了”这种自满情绪。

把“失败”从你的字典里删除

我时不时会拜访一些认为Sprint失败了的团队。这通常意味着该团队没有按计划交付所有东西。但我几乎不认为这是失败，尤其当团队已经完成了大部分计划的工作或者他们巧妙地处理了一些紧急情况的时候。

当篮球运动员将球投向篮筐并投进时，称之为得分。如果没有投进，会称之为一次得分尝试。不是失败，而是尝试。

出色的Scrum Master可以帮助团队调整思维方式，要让他们意识到，未能达到预期的Sprint和功能特性更多的是一种尝试而非失败。

真诚永远是必杀技

前几天，我告诉我十几岁的女儿，我为她感到骄傲。她一下子两眼放光。这一点儿也不奇怪，有谁不想被这样赞美呢？

但是她反应的方式使我意识到我对她的这种称赞太少了。我本以为这是显而易见的事情，就像我告诉她“你很高”一样。但现在我才了解到其实并非如此。

永远不要提供虚假的赞美，没有人愿意听到。但是，当你的团队成员做得不错时，请真诚地赞美他们。而且很有可能，他们听到赞美的频率还不够高。

鼓励团队承担你的工作

刚刚接触敏捷的团队将在很大程度上依赖他们的Scrum Master或敏捷教练。因为他们可能不知道如何在15分钟内完成每天的Scrum会议，又或者他们可能不了解交叉工作和成为跨职能团队的重要性。

一支没有经验的球队也是如此，刚开始学习踢足球的小孩子，需要教练给他们教所有的事情。在我的女儿6岁时，比赛从头到尾，她的教练都会在场外一边跑一边大声喊：“传球呀，跑起来！”如果他不这样做，这些小球员们会忘记。即便是他这样大喊大叫，偶尔也会有些孩子坐在草地上看着别人踢。

如果将世界杯球队的教练和小孩子的教练做比较，就会发现，在世界杯球队中，球员们已经自己学会了该如何去做。就算教练训练迟到了，球员们也自己知道如何开始一天的练习。世界杯教练不需要提醒球员起脚和跑动，但是世界杯球队也永远不会说，他们根本就不需要教练。

无论一个敏捷团队有多么出色，我仍然认为拥有Scrum Master或敏捷教练能够使他们受益。但是，优秀的敏捷团队会自己承担一些更明确的教练任务，这是他们掌握产品开发技能过程中的一部分。

少说多听

有时候你能做的最好的教练或指导就是保持沉默，并让团队自己找到答案。

这是很难的。特别是当你看到团队陷入挣扎不知道该怎么做的时候，自然而然地就想要加入进来并提供建议。但是，如果你这样轻易地解决掉问题，即使只是提出建议，团队就学会了只需要等着，你就会替他们解决掉所有的问题。

我不是说要你永远都不能提供建议。相信你是个聪明人，否则你也不会在现在的岗位上。但是，想要成为一名出色的Scrum Master，很重要的一点就是要帮助团队学会如何自行解决问题。如果你把团队成员面临的每一个问题都给解决了，他们自己就没有机会去学习成长。

关于MikeCohn

Mike Cohn专门帮助公司采用和改进他们对敏捷流程和技术的使用，以构建极高性能的团队。他是《用户故事应用于敏捷软件开发》、《敏捷估算与规划》以及《成功的敏捷方法》的作者，还制作了《更好的用户故事》视频课程。