在前面《Scrum Master—团队的引导者》中详细描述了引导的定义，引导的意义和示例，看起来引导是这么有意义，而且又是SM的强有力武器，是不是SM掌握了引导技能就遇事就引导？答案当然是NO。Again，不能手里拿个锤子，看什么都是钉子！我们来看看有哪些场合SM是不适合作为团队的引导者的。

非常新的团队。新组建的团队或者团队里的成员大都是新入职场的员工，有些技能是需要教的，不是引导出来的，比如团队成员对于敏捷或Scrum没有那么熟悉，根据Scrum指南，SM有责任帮助Scrum team中的每个人理解Scrum理论，这个帮助可以通过teaching的方式，而不是引导。这种理论的教育可以分布在所有的日常仪式中。另外还有一些实践也是需要教给team，比如可视化，如果在此之前团队并没有可视化他们的工作，那么SM可以教给他们，帮助他们建立起这样的工作方式，之后的优化可以通过引导让团队自己来做。

遇到障碍的时候。比如遇到一些团队自己很难解决的障碍。有些障碍应该引导团队自己想办法去移除，比如技术债，比如技能不够，甚至跨团队协作都可以引导团队自己去解决问题。但是有些问题是团队成员不好解决的。比如有人离职或者有人突然休长期病假，这种障碍就是团队不好自己解决的问题，SM作为障碍的移除者，需要站出来协调此类问题，比如协调PO跟团队一起调整承诺，或者协调新的成员进来等；比如团队里成员间有了矛盾，这个也不容易引导自行解决，有个实际的例子，在一次工作中因为技术方案的分歧两位同事吵了起来，最后不欢而散。这个时候作为SM做了两个工作，一个是私下跟同事做了沟通，了解事情的起因经过等，跟同事交流对这个问题的想法，然后跟团队一起开了个会，澄清了这件事儿的性质就是技术分歧，跟大家讨论如果后续还会有这样的分歧该如何处理，最后我们自己在这个领域（当时我们的业务是按照domain来分，我们团队是负责其中一个domain）制定了一个小小的“技术仲裁委员会”，里面包含了SE, PO，专家，团队成员代表等人，如果一个技术方案谁也说服不了谁，那么将该问题提交到这个仲裁委员会来讨论，结果不管是什么大家都接受。最终事件平息而且有个改善。这种情况就不是单单引导可以解决的，起码不是引导容易解决的。

被团队求助的时候。在网上看到一个很有意思的说法，在敏捷导入和成熟的发展过程中，我们可以将其分为守破离的三个阶段，而与之相对应的Scrum Master应该扮演的角色分别是teacher，coach和mentor，也就是在守的阶段，应该以传授知识为主，让团队指导什么是正确的，尽量去遵循最佳实践；在破的阶段，团队开始理解Scrum仪式背后的原则，开始真正按照价值观工作而不是按照框架工作，这个时候可能某些规则被打破，SM以coach为主；等到了离的阶段，团队成员有了足够的知识，但是缺少走向卓越的经验，这个时候SM应该承担的角色当是mentor，通过跟团队成员一起讨论，分析，演示，协作等方式帮助团队。

维持纪律。一谈起来敏捷，往往说的就是自组织、自驱动。但是请不要忘记自组织一定是在纪律之下的自组织，否则将会变成无组织。团队自组织的纪律、边界需要有人帮助管理。这里不用一提管理二字就觉得跟敏捷相违背，过往的Scrum指南使用的是仆人式的领导者这样的词汇，仆人和领导在这里也共存，在新的Scrum指南中SM成为了true leader， 我们能看出在过往实践中SM到底要为什么负责，人们一直在探讨更多的可能性。所以，无论是成为一面镜子反映出团队的现状，还是作为一个为此负责的管理者，SM都应该通过管理仪式，管理时间盒，管理流程来帮助团队实现纪律之下的自组织。在这种场景下，引导可能不是首选的技巧，起码不是唯一的技巧。

以身作则。在我看来这是最重要的一件事儿。以身作则，不是针对那些敏捷仪式而言，而是以身作则去践行Scrum的价值观。这个时候SM所能扮演的所有角色都将消失，当然更不可能去用引导的方式，他将回到SM这个角色本身。身体力行的去践行承诺、勇气、开放、专注、尊重这些价值观，这样才能真正的带领团队走向敏捷，否则目前很多组织中敏捷就是压榨员工的工具、敏捷就是一个口号的印象必然成为现实，这也是为什么很多时候我们看到敏捷宣讲如火如荼，实际落地一塌糊涂的问题，因为3355里价值观这个5没有落地生根。这不是SM一个人的责任，但这必然是SM很重要的一份责任，他不能只是引导别人，首先他得相信并去践行这些价值观。

最后，或许我们工作中遇到的问题都可以通过引导的方式得以解决，但是这对于引导者的能力和被引导者的素质都有较高的要求和期待。别忘了我们讨论的角色是Scrum master，而不是职业引导师，我们的工具箱里应该有多种工具，自然，遇到不同的问题不同的场景我们应该使用合适的技能来解决问题。

https://www.scrum.org/resources/blog/scrum-master-mentor