团队环境

正常情况下，SM不应该去解决某个特定问题，而应该是提高团队自身解决问题的能力。但在不同的团队环境下，SM应该可以在专家和协助者这两种身份之间灵活切换。这里所说的团队环境，主要指团队对敏捷的接纳程度，以及认知程度两个方面。（未完待续）

=== （一）和（二）的分割线 ===

接纳程度低，认知程度一定不高；反之则不然。基于这个假设，实际我们面临的只有以下三种环境：

1，接纳程度高，认知程度低；

2，接纳程度低，认知程度低；

3，接纳程度高，认知程度高；

接纳程度高，认知程度低

这种情况，大多是团队（尤其是团队中的PM）听过一些讲座和介绍，或者看到其他团队导入敏捷后发生的变化，迫切希望通过敏捷来解决当前产品开发中存在的问题。由于团队改变的意愿强，心态开放，SM被信任的程度高，所以在初期，SM可以以专家的身份快速切入，直接对Scrum框架的搭建和实践进行指导。当团队通过切身体会，逐渐了解和掌握Scrum以后，SM便应退居其后，最终以协助者的身份提供帮助。

接纳程度高，认知程度高

在团队的敏捷成熟度和士气都高的状态下，当遇到问题时，SM有上、中、下三个策略可用。

下策是SM直接将问题解决掉。除非是特别紧急，或者解决方案明显超出团队的能力范围，一般不建议采用。

中策是让团队自行解决问题。当团队集体制定出初步的解决方案时，SM可以通过开放性的问题来启发团队进一步完善；若SM确实在此方面擅长，下一步也可以询问团队是否愿意听听SM的建议。

上策就是协助团队预防问题的发生。SM帮助团队学会从各种指标或者迹象中发现异常，提前预警。

接纳程度低，认知程度低

团队因为外力（上级或者客户的要求）而不得不导入敏捷时，出于对变化的恐惧，往往会对新事物产生本能的抗拒或抵制。按照卢因的三步变革理论，变革中的团队要经过解冻、变化和再冻结三个阶段。

其中，解冻期是导入敏捷最关键的一个阶段：只有当团队自我察觉到差距，产生变革的焦虑和迫切感，并且对未来有足够的安全感时，才能顺利进入第二阶段——“变化”。在解冻期，SM应当谨慎使用指导或建议等方法，切忌以挑毛病或者专家的姿态出现在团队面前。因为此时：

1，你的建议不一定正确。没有深入的了解，也许发现的只是浮于表面的症状，真正的问题其实隐藏在一些非正式的规则当中。

2，即使你的建议正确，如果团队自己没有察觉到问题，只会得到团队的辩解，引起冲突。

3，即使你的建议正确，也得到了团队的认可，但如果团队没有意愿进行改变，那也无济于事。

所以，SM最好从”实在”的业务入手，通过协助团队解决相关问题，逐渐赢得团队的信任和影响力。换句话说，只有当SM在足够安全的情况下，才能以专家的身份进行指导。

为了获取信任，SM还要明确告知团队自己的定位。通常，当SM是被上级或者其他外力强行安排进入团队时，都会带着自上而下的目标和使命，比如说迫切期望改变团队的现状。但需要谨记的是，SM一旦进入团队，也要始终以帮助团队为基本理念，从团队和组织两个层面全盘考虑（也就是，不能仅仅考虑外力）。否则，SM会被误认为“钦差”而遭到团队的防备，SM本人也会在利益发生冲突时感到迷茫。

个人能力

除了组织和团队等外部环境等因素，SM还需要根据自己的能力大小采取不同的策略。

对于经验丰富的SM，当仁不让需做好前面吕老师提到的两个要务。即使团队已经运转成熟，SM仍需至少投入20-30%的精力进行观察和纠偏：当发现异常时，需及时对团队进行提醒和引导。LeSS认为，从精力来讲，一个SM最多可支持3个团队；也有人认为，一个SM最好只专注于一个团队，全心全意促使其臻于至善，这个取决于组织可接受的边际收益值。

而对于经验没有那么丰富，尤其是之前没有任何项目或者团队管理经验的小白而言，首先最好将其安置在成熟的团队之中。这样，不仅给团队运转带来的风险小，SM本身的成长曲线也不至于太陡峭。同时，由于SM初学者即无法以专家身份对团队进行指导，也缺乏协助团队自行解决问题的技巧，不妨先放下身段成为团队或者PM的“助理”，做好团队的后勤工作，主动帮助协调解决一些问题，赢得团队信任和喜爱的同时，还能增加实践经验。

责任人

对于（一）里提到的“自管理”，有很多小伙伴提到了一个共同的困惑：“自管理”和相应的“集体承诺”，是不是意味着“吃大锅饭”，不再需要确定某些具体事项的责任人呢？比如说，《指南》中讲质量是由Developers来负责注入的，会不会等于没人负责了？虽然，敏捷先驱沃德·坎宁安为了解释“集体承诺”而发明了Wiki，但对应到现实的团队中，仿佛仍然难以落地。于是，自然而然的，大家认为应该由SM来负责比较合理。这一节，我们就来好好探讨下这个话题。（未完待续）