敏捷开发系列学习总结（18）——Scrum Master的情景领导力模型

素颜马尾好姑娘i 2021-12-09 06:55 317阅读 0赞

几年前，我把几个高尔夫球打到湖里了，一起打球的朋友给了我一些建议。现在那位朋友打高尔夫球已经不比我强了，但他仍在没完没了地建议。他说，“问题是，你得把球打得更远。”他这样说还不如告诉我，“问题是，你打了很多次才把球打进球洞”。我当然需要打得更远。但怎么做到呢？类似的，你们可能也被告诫过——ScrumMaster、敏捷教练或敏捷项目经理都可能告诫你——敏捷项目管理是要领导团队而非管理团队。然而，指导ScrumMaster“要领导而非管理”，并不是什么有信息含量的指导。这相当于告诉高尔夫球手要把球打得更远。这是正确然而没有可操作性的指导。如何才能最好地领导那些想变得敏捷的团队，ScrumMaster们想理解这一点，首先要理解团队需要什么样的领导力，然后看看提供领导力的四种不同方法。这源于保罗·赫塞（Paul Hersey）的情景领导力模型。赫塞的模型为要采用新工作方式的团队，描述了四个就绪级别，如图1所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly96aGFuZ2hhaXlhbmcuYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70][]

根据赫塞的理论，领导者们需要调整其行为以匹配团队的就绪级别。换句话说，ScrumMaster在与有能力和有意愿的团队合作时采用的团队领导方式，跟其与无能力、无意愿的团队合作时是不同的。赫塞建议，优秀的领导者从两个维度来调整其领导行为：任务行为（Task Behavior）和关系行为（Relationship Behavior）。领导者的任务行为，是指领导者对团队工作进行指导的详细程度。领导者的关系行为，是其在多大程度上使用与团队的关系来领导团队。这些行为共同构成了四种不同的领导风格：告知（Telling）、推销（Selling）、参与（Participating）和授权（Delegating）。而“正确”的领导风格，就是最匹配团队就绪级别的领导风格。在图2中，以图形化的方式，展示了团队就绪级别与领导风格间的关系。在图2中，沿着X轴分布领导者的任务行为，沿着Y轴分布其关系行为。图2被划分为四个象限，四个就绪级别被分配到各个象限中。每个象限都包含着最适合该象限团队的领导风格名称。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly96aGFuZ2hhaXlhbmcuYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 1][]

例如，一个无能力和不安的R1团队，需要团队ScrumMaster给予更多的任务指导。ScrumMaster将减少对双向交流（高关系行为）的依赖，而更倾向于单向交流。ScrumMaster必须具备很强的人际技能，但R1团队（无能力和不安）需要高水平的任务指导，才能赢得足够的信心，并得以成长为R2团队，并积极参与双向交流。相对而言，R3和R4团队，由于他们的能力水平较高，对ScrumMaster的任务指导需求程度则要低得多。接下来，本文将详细剖析ScrumMaster在领导各象限团队时具体该做什么。

##   R1：告知型领导风格的ScrumMaster ##

**R1团队的ScrumMaster须为团队做些决策，以便让团队走向成功之路。**

在一个无能力且无意愿或不安的团队（R1团队）真正变得敏捷前，其成员们首先需要获得信心。为了帮助他们获得定心丸，优秀的ScrumMaster会更聚焦于告诉团队成员做什么，而不是建立支持和交流关系。

尽管这似乎与Scrum对自组织团队的强调不一致，但现实情况是，R1象限中的团队并没有为更好的自组织工作方式做好准备。然而，ScrumMaster和教练可以为此象限团队打下基础，使之能迅速成为一个R2（无能力但有意愿或自信的）团队——一个已经为变敏捷而准备就绪的团队。

对于大型项目或者需团队成员竭尽全力才能完成的激进目标，R1团队并未做好准备工作。相反，这种团队要先从赢得简单的小目标开始，以增强信心。

R1团队的ScrumMaster需要为团队做些决策，来促使团队走上成功之路。（是的，我刚说过。）这些决策通常涉及到建立一些基本的过程，这些过程将能帮团队开始感受到成功。

首先，要坚持一到两周的短冲刺。冲刺越短，团队成员越能频繁地感受到Scrum执行反馈的效果。在向团队引入Scrum时，短冲刺是非常有帮助的。新晋敏捷团队需要评估工作方式。等一个月才能看到冲刺结果，这往往太长了。

接下来，要学习基础的敏捷技能，例如测试。要解释质量是每个人的问题，也是每个人的工作。要建立程序员在签入代码前必须进行单元测试的规则。对于这类团队，测试可以不实现自动化，但必须被完成。

同时，引入持续集成过程，或者至少做到每日构建。理想情况下，这些构建应该伴随一个简单的自动化测试集，可以是单元测试或者功能测试。

在开始时，预期可能不会有太多的测试用例，并且测试还可能会经常失败。然而，在大多数情况下，经过几周后，测试用例的数量会增加，构建成功的次数也将会增加。连续几周收到构建成功次数翻番的正向反馈（以及由此而减少的返工），可以打造奇迹般的团队士气和信心。

几年前，我被指派给一个R1级的、无能力和不安的团队。团队成员几乎都是PC机环境下的COBOL程序员。公司刚被收购，之前的管理层曾一再告诫团队成员，说他们没有能力工作于更新或更有趣的技术。

这个团队包含一些非常聪明的程序员，但是在被如此对待几年后，他们毫无信心且技能过时。我为团队提供了非常具体的指导，指导他们使用什么技术、如何工作等等，几个月后，团队恢复了信心。曾经功能失调的团队进入了R2象限。

##  R2：推销型领导风格的ScrumMaster ##

**R2象限是敏捷化的起点。在R2阶段，相关团队成员进入自我决策阶段。**

在R2象限，Scrum Master正在合作的是一个能力不足而又有意愿或信心的团队。在本阶段，团队的发展目标是提升团队成员能力。尽管有些团队是在经历了第一象限和ScrumMaster的告知型领导风格之后才到达这一步，然而许多团队一开始就是R2团队。此象限团队具备敏捷化的必要基础，但它们还不敏捷。R2团队需要ScrumMaster采用推销型领导风格——一种由高度指导性任务行为和高度支持性关系行为结合而成的领导风格。

R2团队的ScrumMaster已经赢得了一定的信任和信心。现在，是时候利用这些关系来提升团队敏捷能力了。

在本阶段，应当让团队成员更多地参与决策过程。尽管仍然需要ScrumMaster为团队做些决策，但要尽可能邀请团队参与。

ScrumMaster还会聚焦于帮助团队成员提高技能。ScrumMaster会继续关注测试，但要开始让团队成员去挑战自动化测试的创建。要投入培训以帮助团队掌握合适的自动化测试工具——许多工具都能给投入的工作带来立竿见影的回报。

为了加快知识和技能在整个团队中的传播，可以引入结对编程。我很少要求团队成员以结对的方式编写代码，但我确实会要求他们尝试结对编程，并自行识别结对编程的合适时机。

所有这些行动方案，都是建立在团队初露头角的信任之上，传递着这样一个信息：关注代码的质量是可接受的和可取的。长久以来，很多团队成员听到的一直是快点、快点、再快点；但却很难听到这样的信息：如果我们编写出高质量的代码，就能得到更快的速度。提醒他们（以及那些只关注速度的人们），如果你上了高速公路，加速到每小时120英里，你就有可能会收到罚单或出交通事故。不管发生哪种情况，比起安全、高质量的每小时70英里速度，你最终到达目标的速度都不会更快。

就个人而言，我从不告诫团队（尤其是R2团队）要加快速度。不过，我会经常告诫他们，通过结对编程、自动化测试和重构，他们能学会编写更好、更高质量的代码。

在“推销”象限中，要继续强调短迭代。R2团队仍然能从每1-2周评估其进展中获益。许多新晋敏捷团队都很难适应这样一种理念，即能在每个冲刺中创建高质量的软件。他们已习惯于先进行编码阶段再进行测试阶段。

要提醒团队成员，在Scrum项目中，编码和测试同时进行的，这样才能每个迭代都产生潜在可交付的产品增量。在一开始时，由于导致上周所有人都陷入恐慌性加班，许多团队会拼命对此进行抵制。团队最终还是能摸索出一种工作方式，使他们每个冲刺都交付高质量软件，但往往需要花费几个（甚至更多）冲刺才能学会如何做到这一点。冲刺不妨短点，这样团队才能尽快掌握这项技能。

## R3：参与型领导风格的ScrumMaster ##

**对于R3团队，要鼓励他们自行决策。**

随着能力的提升，团队开始走出R2象限。R3团队能够以真正敏捷的方式工作。因此，在此象限中，优秀的ScrumMaster会转变为参与型领导风格，减少任务指导，同时增加建立关系的行为。不要把为团队决策作为输入（就像R2/推销象限一样），而是要鼓励团队自行决策。要尽快这么做——即使团队还没意识他们已掌握新能力。面对新增的职责，R3象限团队通常会短暂地回退到不安。但与R1团队不同的是，R3团队能力很强，能快速转变成R4团队。为了帮助团队转变为自行决策，ScrumMaster要彻底退出决策过程。ScrumMaster可以在旁边鼓励和支持团队，但必须向团队成员清楚地表明由他们自行决策。当然，团队可能会犯一些决策错误。但那又怎样呢？团队成员们正在持续学习，其绩效水平通常会比R1时要高出一大截，少许错误也只会带来少许代价。

当团队开始自组织并持续发展其敏捷技能时，ScrumMaster自然地会开始不再狭隘地关注团队绩效，而是更广泛地关注全局因素。团队成员们将狂热地聚焦于当前迭代选定的工作——未来不超过一到四周的时间范围。是的，他们可能有一个发布计划，会涵盖未来三到四个月的工作内容，但该计划会刻意在细节上只进行简短的描述。由于团队成员们太聚焦于当前迭代的树木，因此不得不信赖其ScrumMaster来关注长期的森林。

在这方面，ScrumMaster可以做很多事情。

首先，ScrumMaster可以看看当前迭代之后有什么需要提前规划的事项。例如，与公司内某项特定技术专家进行面谈，或许能为团队带来好处。不幸的是，专家的办公室在2000英里之外。而为了符合公司的差旅准则，他的机票必须提前两周以上购买。又或者在几个冲刺后，团队计划实现的某个特定用户故事，这个故事需要销售副总裁、市场副总裁和部门总经理的大量投入。需要提前规划好与这三个人的协作时间。

其次，ScrumMaster要确保每个冲刺所关注的用户故事都不会偏离已纳入发布版本的主题。由于Scrum鼓励在每个冲刺开始时重新评估所规划工作的优先级，产品负责人和团队可能会逐渐偏离于更大的里程碑或发布版本。

如果这些偏离是刻意的，是从前期冲刺中吸取教训的成果，那这是一件非常棒的事情。然而，如果这是团队和产品负责人过于关注树木而忽视森林的结果，那么ScrumMaster就能协助让项目回归正确方向。

最后但并非最不重要的，ScrumMaster要确保团队始终尽可能地从事最高价值的工作。为了做到这一点，可采用的方法是：在项目的推进过程中，投入精力与产品负责人一起对产品待办列表进行优先级排序和调整。

##   R4：授权型领导风格的ScrumMaster ##

**一旦团队达到了R4就绪级别，优秀的ScrumMaster将从参与型领导风格转变为授权型领导风格。ScrumMaster必须更多地关注如何最大化团队产能。**

一旦团队达到了R4准就绪级别，优秀的ScrumMaster将从参与型领导风格转变为授权型领导风格。此时，团队只需要最少量的任务指导。需要时ScrumMaster可以提供帮助，但不要具体说明如何完成工作。

首先，除了授权团队决策外，还要向团队展示如何尽可能长的延迟决策。在延迟决策时，团队能继续接纳其他方案，并将新的知识融入到最终决策中。我们希望开发人员在设计和编码时能够做到这一点。在Scrum项目中，我们要求团队只编写实现正在开发特性所必需的代码。我们不会要求他们猜测着构建我们“某天”可能会需要的低优先级功能。

例如，假设我们的一个合作伙伴想要向我们发送一份他们要加载到系统中的每周事务文件。我们还不知道它是采用逗号分隔的、固定长度的还是XML文件。我们不会写一个支持所有这三种输入的加载器，而是会延迟决策。这意味着我们可能不会编写任何加载器代码。或者，意味着我们在开始编码时可能会先对输入数据源进行假设，并基于问题假设进行编码。

决策时机是一切。在早先Java开发的日子里，我管理过一个项目，这个项目既可以交付为Java客户端，也可以交付为原生的Windows客户端。两种方式各有利弊。我刚一启动这个项目，就把“解决UI平台问题”列入了待解决问题清单。为此，我召集了主要的开发人员一起讨论，并一起快速做出了决策。

当然，我们做出的决策是错误的。然而，即使我们选择了另一个平台，我仍然会说我们做出了错误的决策。在当时这种情况下，正确的决策应该是延迟决策。在项目早期，我们没有任何决策依据。当然，最终某天还是会做出决策，但这事绝不应该发生在项目的第二周。

因此，要让团队自行决策，但还要指导和建议他们，将决策推迟到尽可能晚的时候。

第二，致力于最大化团队的总体产能。传统管理的项目常常令人感觉像是一场有明确终点线的比赛，就像是10公里徒步跑或50英里自行车赛。而Scrum则更像是一场让你明白24小时能跑多远的比赛。Scrum项目通常没有终点线。取而代之的是，只要时间用完了你就得停下来。如果需要交付更多的功能，你可以再重新开始；否则，你的工作就已经完成了。这种差异导致Scrum团队处理项目的方式，与传统管理者不一样。

传统的项目经理聚焦于实现最终目标，即在特定日期发布特定的功能集。

没什么可以超出这个目标。起初，这似乎是支持传统项目管理的一个优势。然而，如果在项目截止日期前一个月时，有位开发人员告诉项目经理，担心某领域代码虽然暂时能用但却结构脆弱，并在随后几个月可能会成为问题之源。你认为，项目经理可能会作何反应。传统的项目经理非常可能会做出短视的决策，冒险采用脆弱的代码。

而ScrumMaster则必须更加关注团队产能的最大化。在某些特殊情况下，团队或许也会赞成不重构脆弱的代码以满足一个月的最后期限。然而一般来说，正确的做法会是为保护团队的整体产能而进行代码重构。ScrumMaster的工作是鼓励团队朝此方向转变，并保护他们免受外界的非议。

这只是一个例子，或许还有其他很多例子。这里的关键区别在于，传统项目是以满足截止日期交付特定功能集为唯一目标进行管理的。敏捷项目当然也可能会承诺功能的最后期限，但与此同时也看重团队的长期持续产能。

##   ScrumMaster情景领导力模型的应用 ##

**随着团队从成功中获得自信以及能力的提升，他们需要被以不同的方式进行领导。在正确的时间引入和提炼技巧是至关重要的。**

领导是ScrumMaster与其团队所进行的每次交互的总和：说什么，不说什么，怎么说，如何倾听。作为一名优秀的Scrum团队领导者，ScrumMaster不要大喊“该死的鱼雷！”（译者注：“该死的鱼雷！全速前进！”是美国海军上将大卫法拉格特的命令，这里是指让团队全速前进，奋力向前冲），也不要只是安静地坐在团队之外听团队召开每日立会。取而代之的是，ScrumMaster必须学会如何才能成为一名优秀的敏捷领导者——一名优秀的ScrumMaster，必须经常陪伴着正在学习如何变敏捷的团队。

提升技能成为一名ScrumMaster和帮助团队变敏捷并非难事。然而，建立一个关于团队就绪度和向给定团队应用领导风格的心理框架，确实是有帮助的。情境领导模式提供了这个框架。随着团队从成功中获得自信以及能力的提升，他们需要被以不同的方式进行领导。

能力有限且信心有限的团队，通常需要告知型领导风格。当领导R1团队时，可以通过引入短冲刺和组织团队赢得一系列的小目标来增强他们的信心。要引入基本的敏捷实践，例如增加对测试和持续集成的关注。从这些实践中，团队将会获得以新的、更敏捷方式工作在技巧和能力上的信心。

一个能力有限而又有意愿和自信的团队，会受益于推销型领导风格。领导R2团队时，要关注与团队的关系，而不能只进行任务指导。这类团队只是需要时间、动力和练习来提升他们的技能。

为了创造学习机会，要强调每个冲刺结束时交付高质量产品的必要性。通过工作于短迭代，并在每次迭代结束时聚焦于创建潜在可发布的软件，团队成员们会自然而然地探索提升技能的方法。

能力已显著提升的团队，已经为接受更具有参与性的领导风格做好准备。然而，当团队必须自己做决策时，他们往往会变得紧张，想知道他们新获得的技能是否足以胜任。通过在决策中支持R3团队，以及把自己的关注集中于长期（3-6个月）范围，使团队能够将所有注意力聚焦于当前冲刺，来引导他们完成这一转变。

要做到这一点，有一种方法是确保冲刺都始终聚焦于下一个发布版本的目标，即使在每个冲刺开始时都重新排定了工作的优先级。同时，通过与产品负责人协作，对产品待办列表进行适当地优先级排序，以确保公司为团队选择高价值的工作。

一些ScrumMaster非常幸运，能与有能力、有意愿的、已经准备好承担更大责任的R4团队合作。在这种情况下，应采取授权型领导风格。在Scrum项目中，需要考虑不局限于单个项目范围的产能最大化。这意味着要帮助团队学会延迟决策，以便尽可能长时间地保持各种候选方案都可用。

不同于我的高尔夫球友只会给出“把球打得更远”的建议，本文介绍了ScrumMaster可以实施的具体事项，这能帮助他们成为更有效的敏捷团队领导者。虽然这里提及的所有技术都可以应用于任意级别的团队，但是我结合就绪级别来描述这些技术，我认为这种应用方式是最有益的。在正确的时间引入和提炼技巧是ScrumMaster 帮助团队演进到R4级别和授权型领导风格的最佳方式。

**说明：英文版PDF下载链接：https://www.mountaingoatsoftware.com/blog/tag/scrummaster**

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly96aGFuZ2hhaXlhbmcuYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70]: /images/20211208/02a0957c90e34c43a9a5f327fcfe08b8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly96aGFuZ2hhaXlhbmcuYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 1]: /images/20211208/1b1677bdfc40436bbc1a40b7d2c10c29.png