你怼我们团队不行，那为什么换个ScrumMaster就搞定了？

Posted 2021-04-25 敏捷行动派

全世界只有不到 1% 的人会朝着自己的梦想行动

你真是个特别的人

敏捷 背后是勇敢实践的心

他们在五湖四海，也在你身边，他们正在实践敏捷。

几年前，我曾经和一个团队一起工作：我是这个团队空降下来的Scrum Master。在和团队一起工作后，我发现团队有部分工作完成质量不太好，且有时候的对话还挺消极。

作为一个已有多年经验的ScrumMaster，我首先想的是，根据敏捷原则，让团队承担交付的责任。

所以我选择了让团队负责交付的工作，但是第一个迭代就出问题了：因为太过注重让团队负责交付，导致一些问题没有被识别出来，生产出现大量的缺陷，并且客户认为很多提到的需求没有被满足。

这时，之前的项目经理给出一个结论：他认为这样的团队不适合使用敏捷。

这个问题困扰了我很久，我一直试图找出答案来证明一些什么，却总是没有方向，直到Mike Cohn的这篇文章，我茅塞顿开。

希望这篇文章能够给目前的你带来新的启迪，接下来让我们一起看看Mike Cohn是怎么说的。

编辑 Ⅰ小π姐姐

来源 ⅠMike Cohn

如何领导一个敏捷团队？

几年前，我和朋友一起打高尔夫时，经常会把球打到湖水中去，和我一起打高尔夫的朋友就会给我一些建议，虽然朋友也不是一个比我更厉害的高尔夫选手，但这不阻碍他给我提建议，他会说：“你看，你的问题就是需要把球打得更远。”

他这样告诉我，是因为我已经把球打进了湖中，我当然知道我需要达到更远的距离，但是怎样做到呢？

 

如同企业的敏捷实施，我们或许已经接受敏捷转型的思想，无论是ScrumMaster，教练，还是敏捷项目的主要负责人，我们都被告知了：应该“带领团队，而不是管理团队”，然而，这样一句话并不带任何的实操信息指导，这就等同于告诉一个高尔夫选手需要把球打得更远一点，这个指导是有效的，然而，并不具备实操性。

回到敏捷，如何让ScrumMaster做到真正的领导团队，并最终达成真正的敏捷，才是我们的关注点。

 

怎么做呢？

了解你的团队，看看这个团队到底需要的是什么样的带领模式。

 

图为Paul Hersey的情境领导模型，该模型描述了团队的四个准备阶段，处于每个阶段中团队的意愿和团队能力都有所差异。

 

根据Hersey的说法，领导者需要调整自己的行为以适应团队的准备程度。

换句话说，ScrumMaster如果正在带领一个能力很强的团队和一个能力强而且乐于改变的团队，则应该采用两种不同的方式带领这两个团队。

如果遇到一个意愿不强，组织协作也亟需提升的团队，一个ScrumMaster又该如何处理呢？Hersey说，优秀的领导者主要从两个行为方面进行调整：

任务行为和关系行为。

 

任务行为是领导者指导团队工作的程度。

关系行为则是领导者与团队关系对团队的影响程度。

这两种行为互相影响，构成了四种不同的领导风格：命令型，销售型，参与型，授权型。如果你们认为目前的领导是你们的“Mr Right”，他一定是在使用最符合团队准备水平的领导风格。

 

 
如图所示，x轴是领导者的任务行为，y轴则是关系行为，四个象限分别对应四个准备级别的团队，在指导团队时，提前了解你的团队处于哪一象限，我们再采取相对应的领导方式。

比如，一个能力不足，缺乏安全感的R1团队，ScrumMaster应给予更多的任务指导。

那么，ScrumMaster将更少依赖双向沟通（高的关系行为），而倾向于单向沟通（直接指派任务）。

ScrumMaster固然需要具备强大的人际交往沟通能力，但对于R1团队（能力不足和缺乏安全感）来说，则需要更高水平的任务指导，以便他们取得成就，建立信心，逐渐地加强沟通，过渡到R2团队。

相比之下，R3和R4团队能力较高，所以他们对ScrumMaster的要求只要满足低水平的任务指导就OK了。

接下来我们一起来看看，R1,R2,R3,R4这四个阶段团队的ScrumMaster应该如何带领团队？

R1：命令型ScrumMaster 

要使R1团队真正敏捷，首先要做的是帮助团队建立信心。

要帮助团队取得他们需要的认可，即ScrumMaster直接告诉团队成员该做什么，记住，此时不是建立支持或者人际关系的时候。

同时我们也知道，Scrum强调自组织。但现实的情况是，R1团队还不符合实现自组织的条件。

此阶段ScrumMaster或者敏捷教练的主要任务，是帮助团队打下良好的基础，迅速过渡到R2团队（虽然能力还不足，但是对敏捷有意愿或者有自信）。

需要注意的是，R1团队还不具备承载大型的项目，以及实现一些需要成员尽其最大努力而达成的目标，相反的，R1团队应从简单的小幸福，小胜利开始，慢慢提升自信。

ScrumMaster的角色则是帮助团队做决定，这些决定通常会涉及到建立一些能够帮助团队取得陈公公的流程。

首先，坚持短的迭代周期，比如一到两周。迭代越短越好，团队成员收到的反馈越频繁，他们就能更快看到执行Scrum的程度如何。

在大多数情况下，当我们初次引入Scrum到一个新的团队时，短期的迭代将有利于团队，因为团队需要尽快看到Scrum到底能够带来什么，这时候如果设置一个月再看结果，效果则会大打折扣。

接着，重点放在基础的敏捷技能，比如测试。告诉团队：质量是每个人的问题，人人都需要为此负责。

创建一个规则，程序员在检查代码之前必须进行单元测试。对于这种类型的团队，测试不需要自动化，但他们确实需要完成。

同时，引入持续集成，或者至少是每晚建造。理想情况下，这些构建应该伴随着一套简单的自动化测试，无论是单元还是功能级别。

在一开始，可能没有很多测试，也确实存在测试经常失败的情况。一般来说，在整个过程持续几周后，测试次数会增加并且成功的数量构建也将增加。

最终，持续几周的积极反馈，加上多个成功的构建，以及由此减少的返工，将大大增加团队的士气和信心。

R2：销售型ScrumMaster 

在R2团队中，团队成员能力还需要提升，但是非常愿意或是有自信完成工作。所以团队处于这个阶段的目标是提升团队成员的能力。

R2团队一般有两种情况：一部分团队可能是通过R1进化而来；更多的团队则是直接以R2团队开启。

R2团队需要一种销售风格的领导力 - 一种结合了高度指令性的任务行为和高度支持关系行为的领导风格。

R2团队的Scrum Master赢得了一定程度的信任和信心。现在是利用这些关系帮助提高团队敏捷能力的时候了。

在这个阶段，应该让团队成员更多地参与决策。不论是技术的，或者是关于团队的，尽量邀请团队成员都参与进来。

当然，重点必须放在帮助成员提高技能上。继续专注于测试，并要求团队成员创建自动化测试。投入更多的培训，帮助团队学习适当的自动化测试工具 - 许多工具都能立即获得显而易见的回报。

为了让小组协作起来共同提升技能，可引入结对编程。

我个人是很少要求代码成对编写的，但我确实要求团队成员尝试并自己弄清楚，何时可以做到这一点。

在采取了所有这些举措后，加上团队已经开始信任，那么此刻我们需要将重点放在代码的质量。

许多团队成员听到的都是要更快，更快，更快，他们很难听到其他的信息，事实上，如果我们写高质量的代码，速度自然会来。

如果你一直专注在速度上，并一直提醒他们在高速公路上要快，你最后很可能会得到一张罚单，或是一场事故。

所以，无论哪种方式，你不会比平均时间更快地到达目的地，那么就保持安全，高品质，每小时70英里。

就个人而言，我从不告诉团队（特别是R2团队）走得更快。

我经常告诉他们，他们可以学会写得更好，更高质量的代码，可以通过结对编程，自动化测试和重构来编写代码。

最后，同R1团队一样，R2团队继续强调短迭代。

R3：参与型ScrumMaster 

随着团队能力提高，开始走出R2，正式步入 R3，R3团队则能够以真正敏捷的方式开始工作。

优秀的Scrum Master在这个阶段将会转移到参与型的领导风格，主要包括减少任务方向，同时增加建立关系的行为。

ScrumMaster在这个阶不再是为团队做出决策，而是鼓励团队做出自己的决定。

尽快做到这一点，将有利于团队认识到他们之前没被挖掘的能力，有一个小问题，就是R3团队面对新增加的任务，将会暂时回归到不安全感。

但是，与R1的不安全感团队不同，R3团队技术高超，而且可以快速过渡到R4团队。

为了帮助团队能够迅速过渡到自己做决策的阶段，

ScrumMaster将会自动脱离决策的过程，他可以鼓励和支持团队，但是要让团队成员清楚，决定是他们自己来做的。

当然，可能团队会做出一些错误的决定，那也没关系，因为团队成员正在继续学习的道路上，他们的表现水平也已经远远领先于R1，一些错误只是很小的代价。

随着团队开始自组织并继续发展它的敏捷技能，ScrumMaster自然会开始关注更宏观的因素。团队成员将疯狂地专注于当前迭代的事项，他们有一个1到4周的迭代计划，他们可能有一个涵盖很多内容的发布计划，可能就是接下来三四个月的工作，但那个计划可以是缺乏细节的。

因为团队如此专注于当前迭代的每一颗小树 ，所以ScrumMaster应该让团队充满信任，他要让团队看到，他关注的是长期的大森林。

最后，但同样重要的是，确保团队始终致力于最高价值的工作：可以与PO一起工作，产出具有优先级的产品待办列表，并跟随项目的进展。

R4：授权型ScrumMaster 

一旦团队达到R4准备水平，一个好的

ScrumMaster将从参与型领导风格转变为授权型。

此时，团队需要最少的任务指导。如果他们求助再给意见，但是不要太细节地告诉他们任务应该怎么完成。

ScrumMaster尽可能延缓地做出决定。当一个团队在延缓决定时，将会有更多的可能性，或是新的知识会被激发进来。我们希望开发人员用他们的设计和代码做到这一点。

在Scrum项目中，我们要求他们只编写实现目前功能必要的代码，我们不要求他们进行推测：我们可能“有一天”会需要某个功能。

比如，我们的合作伙伴想要每周发送一次他们想要加载到我们系统的事务文件。

我们还不知道它是纯文本逗号分隔，纯文本固定长度或XML文件。这时候，我们没有写一个支持所有三种格式的接口，我们在此时推迟了决策。

这可能意味着我们还没有对任何接口进行编码。或者，它可能意味着我们开始编码时假设输入数据会来自某个类型，我们就从假设的那一部分开始编码。

时机是决策的一切。在Java的早期，我是管理Java客户端提供的项目或作为本机Windows客户端的项目。

做法各有利弊。我们刚开始这个项目，“解析UI平台”是在公开issues list上。所以，我把主要的开发人员聚集在一起，我们很快就做出了决定。

显然，我们做出了错误的决定。但是，即使我们这样做，选择了另一个平台，我仍然会说我们做错了决策。

所以，在这种情况下，正确的决定是推迟决定。在该项目的早期，不是我们一定要立刻做出这个决定。

当然，最终依然需要做出决定。

小结

带领团队的过程是ScrumMaster与团队的每一次互动：他们说什么，他们不说什么，怎么说，怎么样听。

一个优秀的ScrumMaster不是大喊着“该死！不是这样做的！”也不是静静地坐在团队外，像个旁观者一样听取每日Scrum更新。

相反，成为一个良好的敏捷领导者 - 一个优秀的Scrum Master--是我们必须学到东西，并经常和那些自学的团队一起学习如何变得敏捷。

培养成为ScrumMaster并帮助团队的技能变得敏捷并不难。使用情境领导模型框架，ScrumMaster将会随着团队的成功，从中获得信心，继续以不同的方式带领他们提升能力。

（内心OS：看到这里，我突然明白，在我之前工作的那个团队里，原来不是团队不能做敏捷，而是我作为一个Scrum Master，没有根据团队的实际情况，选择适合的领导方式，而是把一个领导R3团队的方式用在了R1团队中，所以才导致了失败的结果。）

不像我的高尔夫小伙伴的建议“打得更远一些，”我们已经讨论了具体可行的如何带领敏捷团队的方式，事实上，ScrumMaster可以做更多的事情，成为一个有效的敏捷团队领导者，此文给所有ScrumMaster，共勉!

---

作为敏捷鼻祖，Mike Cohn的这篇文章极富实战价值，为当下众多迷茫的ScrumMaster打开了一扇大门，如你需要英文原版PDF，可后台回复"ScrumMaster"。

• 江湖地位之争

究竟是用电子看板还是物理看板，争了这么多年终于可以消停了

• 万事开头难

我曾经做过千万级的项目需求，如今却死在了敏捷的第一步！