Scrum反模式：微观管理
译者：Fish
审校：Bob
设计模式是对重复出现的问题的解决方案的描述，概述了解决挑战所必需的要素，且不提示读者以特定方式解决该问题。
不幸的是，我们还是会经常看到无效行为的反复出现，这些被称为反模式。
以下是对最常见的一种反模式的探讨：微观管理。
- 反模式[ 1 ]名称：微观管理
- 别名：过度控制；监督
- 规模：单团队或多团队
- 相关反模式：冲刺燃尽图，速度很重要，时间跟踪，个人激励
潜在解决方案：
- 服务型领导或仆人型领导
- 冲刺黑匣子
- 关注成效而不是产出
- 领导层专注于战略和创造有效的工作环境
为什么会发生微观管理
刚接触Scrum的人通常很难把握有效管理者、ScrumMaster和产品负责人之间的控制界限。这是一个至关重要的考虑因素，因为敏捷的核心是试图去帮助一群人成长为一个有韧性，高效能的团队。这些角色不仅能够促进这种成长，也能阻碍这种成长。允许团队自组织进而蓬勃发展是一个关键因素。
无论您是ScrumMaster还是经理，一旦发现某事可能要出问题，就会想要提供帮助。这可以理解：您是出于好意。但您没意识到这是正在进行微观管理；您觉得这只是给些建议，提供些帮助、点子，使其避免风险。然而，微管理有多种形式：管理层给出建议或直接向团队成员下达命令；利益干系人指导产品负责人用户故事；经理们坚持以某种方式做事，因为他们以前已经做过很多次；还有很多……这些行为都有一个共同的特征：那些并不直接做事的人在试图影响真正做事的人该如何做事。
微观管理在Scrum环境中有很多存在方式。接下来，按角色概述常见的几种。
ScrumMaster的微观管理：
- 将工作分配给团队成员，而不是鼓励他们进行自组织。当ScrumMaster被赋予ScrumMaster和Project Manager的双重角色时，这种可能性更大。
- 运作每日Scrum，而不是引导团队开展会议。
- 将Daily Scrum变成状态报告，而不是团队协作的契机。
- 将自己的想法和观点注入回顾会中。
- 告诉团队成员如何工作。
- 告诉团队成员如何解决问题，这样会损害团队自己解决问题的能力。
- 告诉团队成员问题出在哪里，而不是帮助他们自己发现问题。
产品负责人的微观管理：
- 在Sprint中添加新工作，并要求立即完成。管理层有时也会这样做。
- 参加Daily Scrum以获得状态更新。（Daily Scrum用来帮助团队在一天中进行协作和集中精力。如果团队邀请产品负责人，则产品负责人必须记住这一点，并且不得干涉。）
- 将Daily Scrum用作向团队询问其工作的机会。
- 监督团队，检查所有的细节。（一个好的产品负责人应该赋能团队，小事团队可以自己决定。）
管理层和其他干系人的微观管理：
- 参加Daily Scrum并注入自己的想法，称其为”建议”。（管理层的大多数建议会被自动视为命令。）
- Daily Scrum中有管理人员出席，也会使人们将事件转变为状态报告事件。团队成员会不自觉经常去看管理者，而不是看同伴。届时，Daily Scrum便成了以管理者为中心而非团队。
- 管理者，特别是高管的建议通常被当做命令，因为这些人控制团队成员的绩效评估，薪水增加和长期雇佣状态。团队成员自然会去取悦那些拥有权力的人。
- 要求ScrumMaster在Sprint中频繁更新进度。
- 使用Sprint Burndown图监察Sprint期间团队的进度。
- 将Burndown / Burnup /累积流图视为进度的度量标准，而不是将其用作预测工具来查看Product Backlog中的哪些项目将完成。
- 要求更高的速度或要求团队更快。（团队最终会更快，但只能专注在提高技能和工作质量。）
- 告诉团队如何工作。
- 告诉产品负责人如何写用户故事。
- 将ScrumMaster视为差事。
提示：告诉/分配/应该这样的词是发生微观管理的警告信号！
最终，所有这些都归结为相同的基本问题：通过施加控制被误导的需求和提供帮助的愿望，通常是基于这样一种想法，即：说的人比做的人更知道如何做得好，[ 2 ]以及更能感受是否可控。
我们都会偶尔做一些这样的事情，不要自责。这是正常的人类行为，但是当它成为您的管理风格中反复出现甚至将其定义为您管理风格的一部分时，就是问题。
微观管理的后果
近几年，一些理解现代工作环境中人类行为的模型逐渐出现。作者及其框架研究如下：
- Dan Pink –自主，专精和目标[ 3 ]
- Susan Fowler–自主，亲和力和能力[ 4 ]
- David Rock–身份确定性，自主，亲和力和公平性[ 5 ]
自主程度是所有研究的核心吗？他们每个人都说人们需要拥有自由和独立性，才能做到最好。我还可以说，自主，参与和自组织也是Scrum的核心，这并非偶然。当允许进行微观管理时，这些方面都会受到破坏。
为了说明微观管理的个体效果如何导致更大的，自我延续的负面后果，我们为每种情况提供了一个简单的因果回路图（CLD），最后提供了更全面的CLD。为了使它尽可能简单，我们不会在较小的CLD中重复关联，但是您会在主CLD中看到整体效果和关联。
微观管理的后果：
A）团队成员投入不足
全球有67％的员工不够投入。[ 6 ]他们工作因为有报酬，而不是因为他们关心或喜欢工作。工作不投入的员工仍然会做他们的工作，但通常不会在产品或流程改进上投入太多精力，并且可以确定他们不愿意尝试甚至也不愿意失败。如果一个地方有足够多这样的人，他们会像僵尸一样杀死其他人的能量。在极端情况下，这些工作不够投入的员工可能会造成破坏。[ 7 ]在2017年，全球18％的在职人员工作不够投入。这些人不仅感到无聊不快乐，他们还充满怨恨并破坏了他人的工作。
当管理者（或ScrumMaster或产品负责人）发现自己承受着加快工作速度的压力时，通常会造成这种不投入。他们认为提高工作速度的最简单方法是查看团队的工作，并找到一种”帮助他们”的方法。这种”帮助”总会影响团队的自主权，并损害团队成员参与手头工作的热情。随着团队参与度的降低，工作的质量和数量将下降，如下面的因果循环图所示，这表示客户满意度的下降。毫不奇怪，随着客户满意度的降低，这会给管理层带来更大的外部压力，要求他们更快地工作。
B）减少自组织
如果没有自主和自组织，团队的能力就会降低，他们尝试失败并从中汲取经验的机会就消失了。
C）决策延迟
延迟将会出现，因为微观管理者会造成瓶颈，团队成员会害怕在没有微观管理者的支持、同意或更糟糕的情况下做决定。因此，他们宁愿等待，有时甚至更糟，工作仅仅是为了保持忙碌的状态，而不是做最重要的工作，为客户创造价值。
这些延迟显然会损害生产力和对客户的产出，从而导致更大的压力去适应并挽回损失。然而，这些延迟意味着微观管理组织无法快速地适应变化的环境，会使整个情况变得更糟。这是另一个增强回路。
管理者控制的越多，必须由他们做的决策就越多。决策越多，每个决策必须花费的时间越长。随着决策时间的增加，团队成员将在等待时执行优先级较低的工作，他们不想开始任何重要的事情，因为如果问题的决策到了，他们将不得不放弃当前正在做的一切来做新工作。延迟的决策和低优先级的工作都意味着使客户满意的工作很少。
D）团队内部交流受限
随着微观管理的增加，团队越来越需要决策者的决策来推动事情前进。由于需要讨论的事情越来越少了，与同事交谈的需求也就少了。结果，普遍存在于瀑布式工作中的”知识孤岛”（Knowledge Silos）出现了，甚至可能永远不会消失。另外，由于沟通的减少，解决问题的想法的多样性也会随之减少，从而会损害问题解决的质量。孤立的微观管理者还会直接损害决策质量，因为他们通常不会征求他人的意见。
在职能经理对谁从事何种工作有发言权的地方，这些问题通常会变得更加严重。例如，负责质量保证（QA）的职能经理可能会建议只有QA人员才能创建和运行测试用例。这种武断的人为制造的墙阻碍了具备多技能的团队成员及想学习如何测试的成员参与测试，而这些成员很可能可以帮助提高工作质量或加快交付速度。职能经理，一个重要的职位特征：维护个人帝国的既得利益，因此他们致力于确保界限和壁垒保持不变。最终，在一个健康敏捷的工作环境中，不需要职能经理，他们需要重新定义其角色，以更积极地为他们所带领的团队的成长和自主做出贡献。
这些竖井（silo）随后衍生了英雄主义需求，因为只有少数人能从事这些工作。这些”英雄”最终会损害自组织、损害工作质量，为了更快地工作承受着越来越大的压力，而又无法寻求自己团队的帮助。（因为团队太忙了，所以我们没有在上面的图表上显示质量。相反，质量低下只是导致客户不满意的一部分）。
最后，减少交流也会损害尝试、创新和从失败中学习的能力，从而阻碍任何改善的希望。
微观管理反模式CLD（因果回路图）
如果以上内容看起来很复杂，那……好吧，事实确实如此。人类是复杂的，要使我们以组织的形式去从事复杂的工作尤其具有挑战性。由微观管理者来管理所有的这些更是难以置信的复杂。
微观管理的典型原因
矩阵式组织或职能经理 –通过管理Scrum团队以外的独立职能团队来展示个人功绩。
个体激励催生英雄主义，增加知识孤岛的规模并损害团队的自组织
相信一个人比另一个人了解得更多，这与个人激励密切相关。
相信可以通过控制员工来进而更好地控制结果。这是一个延迟的负反馈循环，因为在任何情况下，这些行为都会损害工作质量，从而损害客户的满意度。在日常工作中很难看到这一点，因为客户的负面影响会延迟。总之，客户仅注意到交付后的某个时间交付物质量变差。
当一个人接受到微观管理时，他们通常也会对其他人施加相同程度的控制。不幸的是，这也是负增强的反馈回路。
微观管理解决方案
1）将团队与上述因素隔离开来：
- 使Sprint成为黑匣子–向干系人说明，Sprint开始后团队需要获得成功的空间
- 不要跟踪或显示Sprint Burndown图表–团队外部的人员经常会使用Sprint Burndown来问一个问题：”为什么团队工作的不够快？”
- 如果官方电子工具是用来监视Sprint中的团队，则团队可能要考虑使用该工具之外的其他东西来管理Sprint Backlog。（例如索引卡）。
- 如果产品负责人在每日Scrum期间进行微观管理，则ScrumMaster应该建议他们在关系改善之前不要参加。
- 暂停对Scrum团队成员的个人奖励。（这是一个短暂的回避，而不是解决方法。最终，个人奖励应该结束。）
2）不要仅给管理者团队交付速度这个数字，而要始终使用概率范围。我通常建议给出三个数字：20％，50％和80％置信区间。
3）在没有提供产品待办事项的上下文的情况下，切勿查看”发布燃尽图”和其他图表- 将对话从”团队能以多快的速度进行”，到”Sprint结束时可以完成哪些事项”。
4）重新协商管理者与开发团队成员之间的关系。
5）加强开发团队，ScrumMaster和产品负责人之间的工作协议，以便所有人都了解他们的界限。
6）引导教育管理者：许多开发团队成员都将管理人员的要求视为”需求”。
7）引导教育管理者：管理者定期参加Daily Scrum会向开发团队发送这样的信号，他们需要监督。管理者最好的参与方式是参与Sprint评审。
8）培养团队多技能以分解整个组织中的技能孤岛。
9）消除个人奖励。更好的是，完全取代年度绩效[ 8 ]评审，并转向持续反馈模型。
10）让组织负责人专注于结果，而不是工作的细节或团队的工作方式。
11）领导者的职位越高，就越应该鼓励他们寻找长期战略。
12）试图了解管理者和干系人的压力来源，Scrum团队，敏捷教练可以运用一种系统化的工具：Systems Thinking得到帮助。一旦我们了解了压力，便可以寻求改变环境以减少/消除压力。
敏捷的军队
管理者和高层谈论他们的组织，就好像它是受过训练的军队一样。讽刺的是，现代军队在200多年前就已经知道，非常规工作（例如在战场上）过于复杂且变化太快，微观管理无法发挥作用。取而代之的是，他们采用冯-莫尔特克的简述 实践 - 领导者描述目前所知道的情况，概述目标；下属提供简短的摘要，[ 9 ]并在摘要中解释他们对当地条件的更详细理解以及实现所述目标的计划。
您想教练您的团队寻求更好的解决方案吗？
在敏捷转型的过程中，从根本上改变团队的工作方式是打造高效能团队所面临的比较具有挑战性的问题。如果您想学习如何处理组织在Scrum转型过程中面临的此类问题，请加入敏捷家社区（公众号：敏捷家），在该社区您将获得有关这些挑战和解决方案的实践学习，以及如何很好的将他们融入到您的Scrum的一些贴士。
[1] “An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.” ~ Wikipedia
[2] My personal kryptonite: I often assume, without thinking, that I know more than the person doing something, and that if I speak up it will save them time, pain, loss, etc.
[3] Drive: The surprising truth about what motivates us (YouTube)
[4] Why Motivating People Doesn’t Work … and What Does: The New Science of Leading, Energizing, and Engaging
[5]See https://www.edbatista.com/2010/03/scarf.html and https://www.mindtools.com/pages/article/SCARF.htm
[6] State of the Global Workplace 2078 – Gallup – https://www.gallup.com/workplace/257552/state-global-workplace-2017.aspx
[7] Ibid
[8] Abolishing Performance Appraisals: Why They Backfire and What to Do Instead – Tom Coens, Mary Jenkins
[9]“The process of giving instructions often leaves a significant amount of room for misinterpretation…” https://www.velaction.com/briefback/
