Pete Deemer

经理2.0：Scrum中经理的角色

当一个组织开始探索Scrum，最初有人指出似乎Scrum中完全没有“经理”这个角色时，通常会有段令人不安的时刻。“好了，我想我们只好把他们全都摆脱掉了！”一名开发人员说笑道，屋子里所有经理们听到后，开始坐立不安。

Scrum仅定义了三个角色——Product Owner、团队和ScrumMaster——并且给组织内的其他人的基本指示是，“要么支持他们，要么就闪开”。尤其当你是名经理，且高级管理层期望你能确保一切进行良好时，这可不是什么很具体的建议。

企业中经理的传统角色基于一种“命令和控制”的模型。在这种模型中，经理的工作是：识别什么需要完成，向员工发出详细的指令，接着确保员工依照指令完成工作。这模型中员工的角色仅仅是遵从收到的指令，相信经理的判断和智慧能确保会以正确的方式完成正确的工作。

复杂情形下，如软件开发这样的动态环境下，这种方式容易失败。首先，对一名经理来说，理解每项需求的全部细节和发出准确的指令来指导每名员工的工作很困难且很耗时。一个软件开发团队中的工作高度相互关联，有着复杂的依赖关系并且变化频繁。指望经理一人为他或她的团队进行所有的基本思考是不现实的。另外，这一方式也会挫伤员工的士气；他们的角色仅仅是”命令执行者“，他们常感受不到对工作归属感。责任仅限于回答一个简单的问题：“我完成了我接收到的命令了么？”如果回答是“是的”，工作已经完成——不管正确的事是否完成，完成的很好，或者满足了客户的业务目标。

Scrum 则基于不同的方式：自组织团队。团队进行的头几步的区别就很明显。在Scrum中，团队决定一个Sprint中要承诺完成多少工作——并且这些承诺是现实的和可完成的——团队的专注、积极性和动力非常高，他们常会提出疑问，“如果团队没完成承诺怎么办？”这通常不是问题，因为确定承诺的过程非常透明和开放。实际上更常见的是，在团队的头几个Sprint中常出现严重的过度承诺，多数团队都只有很少自己进行估算的经验，需要进行一些Sprint，用经验对他们的乐观进行调节。此外，如果团队确实担心无法完成承诺，他们会提前完成Sprint，或是开始进行产品Backlog中的下一项工作。没什么大问题。

Tango团队刚刚完成了他们的第一次Sprint规划会议，规划一个两周的Sprint。会议中他们与他们的经理Jason一起浏览了他们承诺在这个Sprint中完成的工作。

最后，他们问Jason，“我们所承诺的工作量合适么？

Jason反问团队：

“你们确实相信你们能在这个Sprint结束时以高质量完成这些工作么？你们确实感觉到责任感了么？”

团队成员都对他点着头，看起来非常确信。

“那你所承诺的工作量就是合适的。”Jason回答道。“承诺的工作量是过多或过少，在今后的两周内你们就会明白，你们就能学会在下一个Sprint中承诺多少工作量”。

当团队紧密的一起工作，决定由谁来进行哪一项任务，确保所有的工作都被完成，自组织的另一个方面会在这个Sprint中浮现。当团队对决策负责时，他们专注于这一事实：他们对拥有承诺——及如果承诺需要完成，他们就是必须完成承诺的人。当团队外的人负责决定哪些工作需要由谁来完成时——比如说经理——团队会受到一个微妙但却真实的信号，那就是他们没有责任：担心如何达到承诺是经理的工作，而不是团队的工作。这并不表示经理们在Sprint期间就不再提供支持——恰恰相反——但经理们要小心在Sprint期间不要传递给团队任何信号，任何会降低团队对目标的主人翁意识或管理自我的责任心的信号。

在第一个Sprint的头一天，团队邀请他们的经理Sanjay去参加他们的每日Scrum会议。Sanjay希望能帮上忙，就同意了。在团队相互报告时，他站在团队围成的圈子之外。他发现大家似乎在强调前一天完成了多少工作，而没花多少时间报告他们所遇到的障碍。在每个人完成简短报告之后，都会期待地看着Sanjay，希望能看到他的赞同。在会议快结束时，Sanjay发现团队围成的圈子整个转了过来，所有人都面对着他。

最后一个人完成报告后，一名团队成员举起手问道“Sanjay，你有什么能给我们的反馈或指导么？”

Sanjay知道，他必须采取行动了。

“伙计们，我真的很担心。我感觉到这个会议是为我而开。我觉得你们仍然在指望我来确保每个人都在做着正确的事。咱们打个商量：在Sprint中的任何时刻，我都会给予你们任何所需的帮助。如果你们遇到障碍，并无法解决的话，我会尽我所能的提供帮助。但在Sprint结束之前，你们对怎样实现你们做出的承诺负责。那么从今往后，我不会参加这个会议了。这是你们的会议，管理你们自己，实现你们的承诺。如果我在这儿，我怕我会破坏这些。”

团队寂静无声。接着团队成员Victor说到。

“那让我确认一下。是我们负有责任？我们确实拥有这个...”

就在那一刻，团队成员开始交头接耳，他们在真正成为一个自组织团队上迈出了第一步。

成功的转变为自组织最大的挑战之一是，团队将不会开始进行自组织，直到每个团队之外的人停止对他们进行微管理。团队习惯于遵循指令而无法开始进行自组织，除非没有任何指令可以遵循。这需要经理有一个大的转变，这一转变可能会引起恐慌。这并不是说经理抛弃了他们的团队——而是经理需要改变他们交流的风格，并不断提示团队，他们现在才是负有责任的人。

Eillen是RedAlpha Systems的一名工程经理，与七名相对资历较浅的开发人员一起工作。第一个Sprint规划会议期间，团队为在产品Backlog顶部的一个大型功能进行任务分解时，她坐在会议室后面处理email。

他们完成后，转向Eileen，问道：“你觉得这怎么样？”

Eileen立刻就看出团队忽略了一些重要的数据库任务。指出这些被忽略的任务对她来说非常简单，并且这样也能解决问题。她应该这么做么？

Eileen 决定试试另一种方法。她站起来说道，“诸位，你们做的非常好，但并没完全做完。有些重要的任务被你们忽略了。我不会告诉你们到底是什么被忽略了。但我会给你们个提示：仔细思考一下用户会话数据。我现在去倒杯咖啡，五分钟后回来。看看你们能不能在我回来之前找出答案。”

然后Eileen大步走出了会议室。

团队成员面面相觑。Eileen总是会快速地指出他们所遗漏的；在这方面他们依赖着她。但这次她让他们自己找出答案。他们在白板前安静的站了一会儿，然后慢慢开始讨论起来。他们把任务一个个的过了一遍，从各种角度查看每个任务。在数分钟的讨论之后，Tony大声说道。

“等等...我们要把用户会话数据存放在哪儿？我们不得不在数据库中为之建立一张新表，对么？”。

其他的团队成员恍然大悟。

“当然！我们怎么会忘了这个！”一些人小声说道。人群中响起了尴尬的笑声，Sam开始在黄色便签上写下这些新任务并把它们贴到白板上。数分钟后，Eileen端着杯咖啡回来了。她看了看白板，点头表示赞同。

“做的不错，诸位。干嘛不接着开你们的会。我还有一堆的email需要处理呢。”

Eileen坐回原来的地方，对自己刚才所做的颇为满意。

在这个例子中，对Eileen来说告诉团队做什么会更快更容易些。但如果她这么做了，就会鼓励团队等待她给出解决方案，而不是自己解决问题。相反，Eileen选择了更难但最终更有价值的方式：她把找出所遗忘的任务的责任放在了团队的肩上，仅提供能让他们达到这一目标的必要的帮助。如果 Eileen回来时发现团队还在纠结中，她会给出另一个提示或者问另一个探索性的问题，不断这么做直到团队最终找出了遗漏的任务。Eileen甚至可以让团队继续进行下去，在Sprint中找到他们的疏忽之处；错误常常带来最有力的学习经验。

简单说来，Scrum中的经理更少的担任团队“保姆”的角色，而更多的是团队的指导者或“导师”的角色，帮助团队学习、成长和执行。这就是从“经理1.0”到“经理2.0”的转变。

为了让经理在新模式中发挥作用，组织必须重新定义经理的角色和对经理的期待。例如，在Scrum中，团队对完成Sprint中的承诺负责，为了做到这些，所有人必须清楚经理不再对此负责。同样的，在Scrum中，按时提供发布是Product Owner的责任，而不是工程管理层的责任。组织需要让每个人都清楚这种情况。当组织对经理的新角色“说的一套”而陷入困境时则“做的另一套”时，问题就会出现了。

Galaxy 团队已经进行Scrum几个月了，团队在成为真正的自组织团队上做的不错。他们的积极性高涨，他们十分专注，在几个未完全交付的Sprint之后，他们现在展示出一个做出是低昂承诺的模式，并在每个Sprint中都做到百分之百交付。士气高昂，在他们所做的工作中确实有“流”的感觉。工程经理 Francis有了很大的改进 - 他曾是名习惯性的微管理者，他现在更像是团队的导师和教练。不幸的是，在第八个Sprint中，团队遇到了些未曾预料到的困难。在Sprint进行至约一半时，他们的进度严重落后。集团的VP，Simon，不顾一切的来到团队工作区查看他们的Sprint燃尽图，接着把Francis叫到他的办公室。

“Francis，这个Sprint看起来就是场灾难。发生了什么？”他问道。

Francis回答道，“嗯，团队碰到些麻烦，他们正努力地去完成他们的承诺，但目前形势不容乐观。”

Simon皱起了眉头。

“Francis，这个项目很紧急，我们不能让它落后。我指望你来确保团队完成他们的承诺，这个Sprint以及每个Sprint。作为一名经理，你的工作就是确保团队做到这点；如果一切正常，那你可以退后点，但出现问题时，我希望你在那儿确保不浪费时间，每个人都在做所需完成的工作。”

Francis有些恼火。Simon太忙没时间参加内部的Scrum培训，但Francis曾把关于自组织团队和经理的新角色的讲义用email发给过他，Simon也未表达过任何反对意见。Francis说到：

“但自组织团队怎么办，Simon？我们对微管理的摆脱怎么办？”

在Simon回想起他数月前看的讲义时，闪过了一丝认可。

“是的，团队是负有责任，但当他们开始出现问题，我唯你是问。我们想要最大化的责任性，所以团队要负责任，你要负责任。在我们部门，每个人都要负责任！现在就开始吧。”

就这样，Simon转着椅子开始打字。Francis带着暗示离开了办公室。

第二天，Francis出现在了每日Scrum会议上。

“伙计们，从今天起我们要进行另一种形式的会议了。由于这个项目的紧急性，Simon指示我要更多地...嗯...'促进'你们在Sprint的自组织。因此今天早上我想获知你们所承诺的每个功能的状态更新 - 由谁在做，做到什么程度及还剩下多少工作 - 我将会给出些更具体的反馈，希望我们能在下周末百分百地完成每项工作。”

团队成员相互看看。团队的ScrumMaster Philip说到。

“Francis...嗯...这是不是意味着团队不再负责自我管理？”

一些团队成员点头同意。

Francis回答道，“伙计们，我们都负有责任。你们负责管理自己，我负责确保你们完成了每项工作。我们一起负责！”Francis没注意到那些微微转动的眼球。

随着Sprint的进行，Francis越来越多的参与其中。每日Scrum变成了状态更新会议，团队告诉Francis他们能完成什么，让他分配第二天的任务。团队的情绪发生了变化；积极性似乎在降低，团队成员变回了原来的角色，他们讽刺地称呼这种角色为“Francis大人的仆人”。在 Sprint结束时，团队完全变回了“命令执行”的模式，Francis一个任务接一个任务地指挥着他们。Sprint回顾会议时，Simon从会议的开始就加入了，团队对此感到惊讶。

“那么...”Simon问，“所有的承诺我们都完成了么？”

团队成员相互看看。Francis回答道。

“Simon，很不幸，还有些backlog条目没有完成。”

Simon的眼中闪过一道怒火。

“为什么会这样？谁对此负责？”

团队寂静无声，但他们的头都慢慢地转向了Francis。

Simon接着说道。“Francis，我告诉过你把这一切做完的。下一个Sprint，我不想看到再出现这样的情况。如果再出现，那你就有麻烦了...”

听到这些，团队中的每个人都默默地非常谨慎地在心里思考下一个Sprint中要承诺多少工作。他们再也不想在今后的两周内听到这样的咆哮了。

随着一个个Sprint的完成，Francis越来越多的陷入对团队工作的每个阶段进行指导了。自组织已经踪影全无，随着它的消失，团队曾显示出的高涨的积极性、动力和专注也消失了。士气直线下降，生产效率极差。午餐时间变得越来越长，茶休越来越频繁，Francis感觉到他要花费越来越多的时间来确保团队成员在座位上工作。在那些少数几个令人赞叹的Sprint中，团队真正地进行着自组织并尽其所能地工作着，这些都成了越来越遥远的回忆。回到微管理让一切变得更糟，因为团队成员已经品尝过自我组织的“幸福生活”。

这种情况中的每一步都存在判断错误。ScrumMaster没有保护团队不被Francis的微管理影响，或是与Francis来个“双边会谈 ”。Francis没做任何说服Simon的努力，或是帮Simon明白他的行为会造成的后果。但也许最大的错误是早期所犯的一个错误：关于 Scrum成功所需的管理模型上的转变以及如何在顺利或不顺时应用这种转变，Simon从未接受过适当培训；这种转变也从未在Francis的工作描述中做出“正式的”变更。因此，一个成功的、高绩效的Scrum团队快速地退化回之前表现不佳的状态。

上面的情形极其常见，这也是Scrum转变最常失败的地方。此外，在出现这种情形的组织中，消息传播的飞快，常常导致其他经理们为自我保护而主动回归至微管理。

那么如何避免这类失败的发生呢？

首先，需要头脑清晰地评估每个层次的管理层对改变的意愿和能力。如果管理和执行层对“命令和控制”方法的有效性存在信仰基础，并且严重依赖恐吓、威胁或惩罚（比如羞辱或侮辱）作为管理工具，那转变为新的思考方式会特别困难。因此，Scrum的实施就会冒着实施不完全和不正常，对组织的改进非常小的风险。

然而，如果对改变持开放的态度，并认识到现有的命令和控制式习惯也许不是最有效的方法，然后需要对每个层次的管理层进行培训和指导；在实践中，这意味着为所有经理提供高质量的Scrum培训，从最底层的职能经理到组织的高层成员（VP级别及更高层）。

完成经理角色重定义的最后必须的一步是，在组织内“正式公布”。一个选择是用下面的内容作为指导重写经理的工作描述。另一个选择是完善组织内经理们的互动活动，以打破他们已有的工作描述并融合Scrum价值观和实践后重建这些工作描述。使用任何这些方法，最关键的是得到他或她的经理（比如，工程总监或是部门主管）对新的工作描述的正式批准。没有一个来自上级管理层的明确的“正式的”批准，在出现困难时经理的新角色的保全就会困难重重。

经理作为Scrum Master

另一个重定义经理角色的方法是把经理转变为团队的ScrumMaster。这鲜有成功的记录。当经理扮演ScrumMaster的角色时，团队将不太可能开始进行自组织。之前“命令发布者”和“命令执行者”的习惯很难打破，更可能发生的是之前的命令和控制式价值观和模式将被移植至Scrum 实践的核心。因此，来自自组织团队的益处——主人翁意识、专注、动力，对质量的自豪感、高昂的士气和更高的生产率——将不可能实现。多数情况下不如让一名团队成员来扮演ScrumMaster的角色，即使他们同时还必须担负开发责任。

亲身参与：重新定义经理的角色

参与人员：经理，练习主持人

第一步。让经理在便签上写下他们目前所有的工作职责。经理应把它写得尽可能的全面和完整，包括正式的和非正式的职责，还有那些他们应该做却没时间做的事情。多数经理应该能列出至少20-25项。下面是个范例清单：

第2步。在白板上画出两栏：“在Scrum中很好”和“与Scrum冲突/在Scrum中不需要”。要求经理一个一个的过一遍便签，并把它们分别放入其中某栏中。

第3步。把所有在“在Scrum中很好”栏中的条目列入新的经理工作描述中。（在这个阶段也许需要HR的帮助。）

第4步。问经理两个问题，“作为这一新的角色，你对组织将更有用还是更无用？”和“这一角色对你来说是更有趣还是更无趣？”多数情况下，迅即得到的答复是“更有用”和“更有趣”。

第5步。得到他或她的经理（比如，工程总监或是部门主管）对新的工作描述的正式批准。这是极为重要的最后一步。没有正式的认可，经理的新角色将不被视为“正式的”，而这将会有很大退回至之前微管理和命令控制式模式的风险。

说明

在Scrum中很好

帮助团队移除他们自己无法解决的障碍

虽然ScrumMaster每一时/每一天都在做这些，而经理们需要专注于基础更具组织性的或全公司范围的障碍。这些通常是组织内最让人烦恼的问题，需要管理层的影响、权力或购买能力来解决。在SCRUM与企业管理一书中，Ken Schwaber建议成立一个经理和行政人员的企业过渡团队，该团队有一个列满各种障碍的backlog并负责推进组织的发展。

提供建议和帮助以助解决团队遇到的技术难题

每当团队需要时，经理们都能提供建议或协助。

与团队成员定期进行一对一的会议，为他们提供辅导和指导

经理们应与团队成员以适当的频率进行一对一的会谈。这不是任务状态更新会议——这是辅导和指导的时间。一些经理喜欢与团队成员肩并肩的写代码来进行这种会议！

在如何把功能做的更好上投入精力

这种投入通常是在Sprint回顾会议期间直接面向Product Owner。

与团队正在使用的开发工具、技术和技巧保持同步

这是个非常重要且常被忽视的行为。经理们的技术和开发实践有时被“冻结”在最后亲自动手开发的那一刻。

为团队成员规划培训和其他技能的发展

经理应该认真考虑团队需发展技能的领域或团队为处理将面临的产品Backlog条目所需的能力。

了解最新的行业新闻和行业发展

再次强调，这是个重要且常被忽视的行为。

预先考虑工具、技能和其他未来的需求

另一个重要且常被忽视的行为。一定要从团队获取信息。

规划和管理预算及财务

又一个重要且常被忽略的行为。一定要从团队获取信息。

在团队应开发什么样的特性/功能提供上投入精力

这种投入应直接面对Product Owner。

为团队成员提供绩效评估并提供反馈意见

多数组织中的必备活动（尽管在常用的方法论中有着已证实的缺陷）。经理应该基于他们的观察和来自团队成员的共事者的反馈来完成评估。

与团队成员一起进行职业发展和职业规划

职业机遇是人们从雇主那儿得到的最有价值的报酬之一。

招聘、面试和雇佣新的团队成员

一些最好的——在其他情况下，最坏的——管理行为是雇佣决策。正确的雇佣自雇佣之日起就能不断产生收益——而错误的雇佣则会让团队交付商业价值的能力每天付出无形的代价。

去除在团队中不能表现良好的团队成员

如果对一名团队成员提供昂贵的培训也不能帮助其为团队做出贡献、与其他团队成员协调地合作或是表现出所要求的水平，那也许就需要把他请出团队或是组织了。通常经理在这一流程上会需要HR协助和指导。

与Scrum冲突或在Scrum中不需要

决定什么工作需要完成

Product Owner来决定需要完成特性和功能，团队来决定交付这些需要进行哪些任务。

为团队成员分配工作

在Sprint期间，团队自己来做这些。

了解团队中每个人的工作进展

团队通过使用每日Scrum会议和Sprint Backlog来进行这项工作。

确保团队完成了他们的工作

团队对此负责。

对管理层做出承诺，在特定日期之前团队能完成多少工作

Product Owner估量或评估团队的速度，并对在指定日期之前团队能完成产品Backlog中的多少工作作出预测。如果Product Owner承诺了一个硬性的发布日期，那就由他对完成目标所包含的必要范围和进度缓冲负责。

对团队达到我向管理层做出的承诺负责

如果进度低于预期，Product Owner负责决定做什么——推后发布日期、移除产品Backlog条目或是简化产品Backlog条目。

向管理层进行每周状态汇报

在Scrum中不需要这么做。如果管理层想知道，可以询问Product Owner。

进行团队周会

在Scrum中不需要这么做。团队每天都更新状态，经理可以在Sprint回顾会议时更新Sprint的信息。

亲身参与：经理工作描述的样例

领导新团队成员的招聘和雇佣（包括已有团队成员的参与和投入）
与Product Owner一起在产品策略和愿景上投入精力，并在产品Backlog的内容和优先级上为Product Owner提供反馈意见。
为团队及他们的ScrumMaster提供支持和协助。主动和积极地帮助伤害团队效率的障碍。
积极支持ScrumMaster，保护团队免受打扰、免于崩溃和避免外部干涉。
在团队工作期间遇到技术难题时提供建议和协助。
识别出团队可能忽略的问题，比如可伸缩性、性能、安全性等等。
为团队成员提供辅导和职业发展建议及指导。这种辅导应包括技术辅导，还有软技能和在发展的组织中高效工作和成功所需的其他方面技能。
为团队成员规划和管理技能发展和培训。认真考虑哪些是他们最需要发展技能的领域，或哪儿有更多提升的机会；与团队成员一起工作以确定适合的培训；获取完成培训所需的预算和时间。
与团队正在使用的开发工具和技术保持同步。从团队和其他干系人那儿获得可能有用的工具和技术的帮助。花些时间亲自熟悉这些工具和技术。
了解最新的行业新闻。从各方面全面了解当前的发展：我们公司、我们的竞争对手和我们最大的客户，包括财务状况、市场份额、产品路线图和总体商业策略。
去除这样的团队成员：不能在已有团队中表现良好，与其他团队成员有效地合作或是表现出专业或质量的要求。这种措施应该在进行了修正低绩效的指导和培训并未达到效果后才进行。
为团队做财务规划和预算，包括未来预期的人员需求、技能发展和培训需求、工具和技术需求、硬件、差旅和任何其他团队所需资源。
为团队成员提供绩效反馈并完成绩效评估。正式的绩效反馈应定期进行，应包括来自共事的团队成员的反馈。反馈应把重点放在成就的认可和成长的机会上。

关于作者

Pete Deemer是The Scrum Training Institute的创立者之一，他是The Scrum Primer一书的合著者，这本书是最被广泛阅读的Scrum介绍读物之一。在最近的22年里，Pete在全球性公司内领导团队开发产品及提供服务。Pete作为高级行政人员成功领导Yahoo!的在大型企业Scrum的实施，这一实施增长至在全球的超过2000名员工。在Yahoo!的任期内，他是Yahoo!美国产品考分的VP，也是Yahoo!位于印度邦加罗1500人的研发中心的首席产品官。