我们需要规定性的敏捷教练方法吗？

指导团队时，敏捷教练通常使用一种“不干涉的”描述性方法。那么，团队在应用敏捷时，这种教练方法是不是始终都是最佳的解决方案呢？那种规定性的“亲自动手的”教练方法能否更加高效呢？你应该怎么做呢？

Robert Galen 写了一篇名为《世界需要更为规定性的敏捷教练》的博客，在这篇博客中他向称为“温和的、鼓励性的、影响型的”教练方法发起了挑战，虽然很多时候敏捷教练们都在采用这种方法：

我要开诚布公地讲，在敏捷中自我管理型团队非常的重要。我希望团队凭自己的力量对事情进行分类。但是我也在想，我们作为教练应该偶尔提供一些指导意见，而不要总是说“视情况而定”——特别是在我们面对完全崭新的一个团队时，他们实际上并没有什么经验。

他用 Shu-Ha-Ri 的比喻解释说，不同的团队需要不同类型的教练方法：

对于 RI（专家级）级团队，我希望教练给予相对宽泛和简单地指导。然而，当同一个教练遇到一个刚刚建立的 SHU（初学者级）级团队时，我希望他们给团队一些规定性的指导意见。并且，向团队明确地阐明组织约束，比如，帮助团队建立他们的完成标准。

Bob 提出五个主要因素，你可以用它来看看你的敏捷教练风格是不是过于温和了：

1. 不愿意“告诉”团队要做什么
2. 不愿意插手“叫停”
3. 不了解平衡的时机
4. 缺乏对视情况而定和规定性的比较
5. 害怕投身其中

在一篇名为《什么是 scrum？…… …真的吗》的博客中，Niklas Björnerstedt 分享了他对 Scrum 定义的想法。按照他的说法，Scrum 原本就是有一定的规定的，而这正是它得以流行的原因。但是，在某些情况下实施规定性的 Scrum 却会成为错误的方式。

有很多真正杰出的 Scrum 大师，但也有大量教条的、不明就理的传道士。如果你的环境不适合 Scrum，他们总是回答说：改变你的环境使其适合 Scrum。如果你们自己能够掌控这些变化，那么这个建议就很不错。但是，如果你试图的改变涉及到核心的竞争力，那么这个建议就太可怕了。

在一篇名为《 Scrum 已死》的博客中，Andrew Kallman 和 Ted Kallman 说明了教练何时应该采用“亲自动手”的教练风格，而何时应该改为“不干涉”的方式：

从个人的层面来讲，每个人在“敏捷”之旅中都将经历一个类似的过程。在他们惊叹地发出“啊哈”之前，将额外需要深入实际的教练、指导和支持。但从他们“明白了”（真正的明白了）的那一刻起，他们就可以成为高效的团队成员，教练或指导者就可以更多地采用“不干涉”的方式去指导团队成员了。

而同样的道理也适用于团队。团队与之前讲过的个人是类似的，正在实施敏捷的团队有 58% 处于“啊哈”之前的位置。以某些合理的、商业的价值标准来看，他们算不上是高效的。他们或者只是走了走形式或者彻底地失败了。这些团队在通往“啊哈”的旅途中需要更具规定性的敏捷方法（比如亲自动手的教练或指导）。42% 的团队处于“啊哈”之后的位置，可以采用尽量“不干涉”的方法去引导、教练和指导（比如允许其自组织、自管理等等）。

Mike Carey 在描述性与规范性上发表了一篇博客，他在文中探讨了如何以非规定性的方式去部署敏捷框架。他解释了为什么团队在采用敏捷时可能希望得到教练的直接指导：

纯粹的敏捷开发人员一直都在推行尽量“不干涉”的方法。我最感兴趣的是，密切结合的一些敏捷开发人员如何形成了一种特定的方法。与这些人的交流通常可归结为“无论他们想干什么你都应该让他们干，但是如果你是个好教练，他们真的获得了这样的原则，那么他们会更喜欢继续使用我推荐的方式。……。问题是，他们得接受过一定的指导。你不能把团队丢给他们自己；你必须给予他们某种方式的支持。我不是说所有敏捷团队都需要一个专职的敏捷教练，但是他们需要有人来确保他们按照敏捷原则和环境的调整的方向，他们失败（不是如果）时会得到支持。

针对以非规定的方式进行指导的敏捷教练，他的建议是“改变你努力去表达你的意思的说话方式”：

当他们极力想要改进结果时，以及努力尝试一些别的东西时，弄清楚你为什么推荐某个实践。你要提议这个推荐的做法，但最好采用描述性的方法去解释它，而不是规定性的方法。

查看英文原文： Do We Need Prescriptive Agile Coaching?