顾名思义，这是一系列有关Scrum角色的文章（ 第1 部分和第2部分 ）的延续。 今天，我们将考虑以下角色扮演大师 。 矛盾的是，Scrum的成功很大程度上取决于Scrum管理员。 因此，我想再次唤起想象的力量并给出一个隐喻（ 免责声明：一个例子绝不应该冒犯任何人的感受 ）。 有一种文化，有其自己的邪教，有其仪式，有该邪教的传道人。 部长可以分为以下几类：
- 那些与自己的文化更喜欢一对一的人-隐士，隐居者，开悟者；
- 那些了解所有规则，发现漏洞，了解如何做，如何将邪教用于自私的目的，从人，他们的恐惧和偏见中牟利的人；
- 那些试图在自己的地方种种文化的狂热分子。 对于他们来说，除了知识之外，其他一切都是异端。
- 那些真诚地相信，感到并试图分享，帮助并将这个奇迹带给人们的人； 他们交谈，解释，倾听并尝试提供帮助。
在我看来，Scrum和SM发生了非常相似的故事。 尝试通过这样的棱镜看熟悉的SM。 您想使用哪种SM？
让我们看看SM可能有哪些令人震惊的症状。
与产品负责人的互动
症状 ：SM不适用于杂货积压。 完全将其交给PO的良心。 他希望团队在没有SM参与的情况下，将以他们需要的形式接收积压订单及其要素。
不好的是 ：SM的任务之一是建立一个有效且透明的过程，让所有参与者都可以舒适地工作。 SM需要跟踪所有Scrum要素才能对其进行改进，并且产品积压是非常重要的Scrum工件，SM无法忽略。
如何处理 ：SM应该与PO协商以共同处理积压工作，并了解PO的工作； 分析过程； 提出改进建议； 提供您的帮助。 SM应该询问团队对积压工作有什么期望，以及如何改进积压工作。 为了做出集体决定来改善积压，积压的要素，与积压的交互的过程和活动，我们可以对此进行单独的回顾。 并以一定的周期性返回这个问题（ 请记住，混乱的基础是一个经验过程 ）。
症状 ：SM不听取PO的想法/愿望。 他与自己形成鲜明对比。 有一场影响力的小镇之战。 SM和PO之间没有建设性的相互作用。
不好的是 ：我喜欢将Scrum团队与家庭进行比较，这种隐喻通常有助于理解和解释为什么需要这样做，而无需其他方式（ 只需将情况转移给家庭，问一个问题：“您将如何在家庭中行事？”。通常您可以找到答案的路径 ）。 很难建立一个幸福的家庭，在这里父母经常吵架，因为孩子们为此遭受很大的痛苦（ 重要 ：SM和PO不是团队的“父母” ）。 如果SM和PO之间没有相互理解和建设性互动，团队将遭受苦难：卧底比赛，破坏公开性和透明度。 如果SM无法同意PO，那么他将无法完成他最重要的任务之一：“ Scrum Master可以帮助每个人更改这些交互以最大化Scrum团队创造的价值。 ”
如何治疗 ：我们需要经验丰富的调解人，他们会揭示冲突的根源，以便开始改善局势。 活跃的团队本身可以开始记录有关SM和PO之间差异对团队结果的破坏性影响的事实-只需记录工作情况即可。 然后回想一下，当两个参与者都出席时，给出这些事实，进行讨论并尝试找到解决方案。 如果无法进行对话，而最终只能是找到有罪感，而不是解决办法，那么您就需要寻找外部协助者，并将问题升级到团队之外。
同时，对于团队而言，重要的是不要站在一边：“不要像您所同意的那样将我们拖入纠纷，所以请让我们知道解决方案。” 此职位将指示SM和PO的现有问题。
团队互动
症状 ：Scrum主管没有“讲究”：它没有解释Scrum元素的本质，没有进行培训，游戏和培训，这些培训，游戏和培训使团队无法更好地理解Scrum并参与敏捷文化。 不向团队解释或回答与流程相关的问题。 目前尚不清楚Scrum团队成员的接受程度和了解程度。
不好的是 ：如果没有定期讨论团队的团队会议，那么对框架的理解和信任就会消失。 任何文化（ 敏捷也不例外 ）都需要加强（ 不要与货运邪教混为一谈 ），该方案很可能行不通：我们已经受过训练，我们知道scrum，scrum起飞了。 随着时间的推移，人们会积累经验，他们有新的问题需要关注，解释。 如果您不帮助人们理解，那么他们将停止接受这些想法，并陷入问题和误解中，最终，他们将感到失望。
如何看待 ：首先，SM必须一直独自学习，与同事沟通，阅读文章，参加会议，会议等。 他应该定期与组织的/ PO /团队共享此知识：进行培训和游戏，阐明敏捷/敏捷的原理。 团队/公司正在发展，有必要提供满足当前需求的相关知识。 为了实现这些需求，您需要与人们就流程和工作困难进行更多的沟通。 SM应该定期与团队中的每个成员进行私人对话，以了解团队中对Scrum的期望，问题和理解水平。 与Scrum一样，在团队/公司内部树立敏捷文化和Scrum的活动节奏非常重要。
症状 ：部分SM，例如，与另一个角色组合。 而且，根据剩余原理，他此时会精打细算。
不好的是 ：如果SM没有完全屈服于在团队/公司中发展Scrum的任务，而是将其与其他活动结合在一起，那么所有结果都将很可能遭受损失。 成为一名优秀的SM并不容易，而且如果一开始就做得好，那么混乱可能会恶化。 例如：如果一个人将开发人员和SM的角色结合在一起，那么在实现sprint目标时遇到问题时，他宁愿急于自己完成任务以实现目标。 这太糟糕了！ 在这种情况下，SM最正确的行为是组建团队以取得成果，发展团队，帮助团队变得更好。
如何看待 ：如果我们谈论的是SM在一个不成熟的团队中的工作，我们需要设法找到使SM从Scrum-mastery之外的任何其他工作中解放出来的方法。 可以在几个冲刺中作为实验来提供，以了解这会给团队带来什么。 如果组织正在测试敏捷性和混乱性，那么他们应该开绿灯。 实验之后，所有感兴趣的各方都应该评估结果并就Scrum的命运，分配的SM和敏捷文化做出决策。
SM已经成长为一支公交车因素不只一个，并且在没有SM的情况下完成工作的成熟团队，因此有能力与第二支团队合并或合作（ 但不要忘记第一支团队，也许在那里为自己找一个替代者 ）。
症状 ：SM无法召开会议。 它可以掩盖自己，“知道”所有问题的答案，并且不允许团队成员大声疾呼。 或者他不“主持”会议，他只是召集人，然后让事情自己进行。
不好的是 ：如果SM无法帮助，不能帮助建立有效的沟通（ 在团队成员之间；与PO，利益相关者等沟通；召开会议等 ），那么很多精力都可以花在可以指导的沟通上用于产品开发。 会议可能无法完成分配给他们的任务。 误解可能会引起冲突。 通过有效的决策工具，会议可能会变成压力源。 而且，SM在股东大会上的支配地位将激励团队，并不利于主动性和自组织能力。
如何治疗 ：SM必须能够促进 。 他的任务是建立团队内部的开放式沟通。 与外界建立团队互动； 教您的团队举行有用的会议。 SM应了解会议的必要性，制定会议的目的和议程，并提前注明会期。 在会议期间，您需要关注议程和分配的时间范围，中断有关抽象主题的讨论，例如：“我们肯定会在以后再回到该主题，它已经被记录下来，现在让我们继续讨论当前问题。” 您可以请一位参与者协助会议（ 或将部分会议委托给团队 ）。 在每次会议结束时，总结和记录结果很重要。 实施会议评估工具非常有用，这样最终参与者可以再花几秒钟的时间并提供反馈（ 我们建立了一个经验过程，可能会很有用 ）。 所有结果应在会议结束时传达给所有有关各方，例如通过信函。
症状 ：SM不会组成一群真正的Scrum团队。 不建立信任的专业关系，不顺利。
不好的是 ：不愿意沟通，冲突，不工作的气氛-对团队的结果产生负面影响。 在其他条件相同的情况下，紧密联系的团队可以提供最佳结果。
如何对待 ：SM的重要任务之一是使一群人成为一个团队，即 壮大团队并使其成熟（ SM待命并感动时 ）。 为此，请花尽可能多的时间与团队合作，注意冲突，以便可以解决冲突并不允许其发展，了解通信的建立方式（ 如果坐在彼此旁边的人不交谈也不互相写电子邮件-这令人震惊 ）。 SM应当在实际情况下证明实时通信相对于通信的好处。 他需要找到冲突和分歧的根本原因，并帮助人们彼此谈判。 一种有用的分析工具是构建交流图（ 放置每个团队成员的顶点，并且每个边缘都是交流的事实 ），对其进行分析，可以查找交流中的弱点（ 例如，通过一个团队成员进行交流-这是“ 狭窄的脖子 ”）；或特定人群之间缺乏沟通 ）。 在此基础上，您可以为交流的“组合”创建情境，在此情况下，您将“非交流”人员聚集到一起； 反之亦然，您可以从某些情况下排除与之建立联系的人。 跟踪这种图的发展动态是有用且有趣的。
症状 ：SM不会发展团队，不会提供不断的变化，不会使团队脱离舒适区，不支持主动行动，并且对当前的成功感到满意：“我们很棒！ 我们是一个团队！”
不好的是 ：如果SM不是变革（ 和发展 ）的引擎，那么他的团队很可能会降级。 该过程中的任何参与者都可以要求进行更改，但这不应该指望。 如果不进行任何改进的尝试，随着时间的推移，团队将落后于需求。 敏捷就是要能够迅速适应变化。
如何看待 ：SM应该是变更的发起者，提供在流程，任务中尝试新事物，实施工程实践的能力。 您不能休息，您需要寻找改善的机会。 要了解正在进行的更改以及更改的状态，您可以增加透明度并可视化该过程。 与团队合作及其发展与创建产品相同。 SM可以拥有自己的董事会，他可以在该董事会上进行实验，回顾性活动的倡议，倡议等。 董事会上没有任何变化可能表明SM停滞不前。 与团队长期合作时，SM可能会模糊他的视线，存在停止寻求改进机会的威胁，然后您可以离开团队一段时间（ 一方面对SM有用，另一方面可以很好地测试团队的成熟度，表现如何将导致缺少SM的领导 ），或寻求外部帮助，例如，与相邻团队的SM达成共识，以进行一段时间的更改以帮助彼此找到成长点。
症状 ：SM允许您不要乱搞，从容是指破坏活动。 例如：
“-是的，似乎sprint毫无缺陷地通过了，让我们不进行追溯，然后讨论什么？
-好的，我们下次再做。”
不好的是 ：如果SM无法在团队，PO，公司面前捍卫Scrum的纯正性和必要性，那么其他任何人都不会这样做。 如果不捍卫这些原则，那么就没有任何意义和意义。 SM应该具有很好的适应性，并忠于任何变化。 优秀的SM不会拒绝，而是说“让我们尝试。 我们将进行实验。” 但是，关于Scrum框架的原理，您需要保持持久性，并清楚地了解Scrum的工件，事件，仪式，价值和其他元素，以及对于它们的需求以及它们要解决的任务。 成熟的团队已经在更改框架，在成为Scrum的阶段，您不能放弃懈怠并远离Scrum指南（ 违反其中一条规则会引发一个合理的问题：为什么不打破另一条规则？ ）。
如何对待 ：SM的任务之一是监视Scrum的“清洁度”，直到团队成熟，它必须制止所有针对Scrum的骚乱和破坏。 SM有助于进行怀疑的互动练习。 找到一个精明的“怀疑论者”，例如一个SM同事并与他一起进行锻炼是个好习惯：请他破坏秩序，然后SM应防身。 您需要准备好回答以下问题：我们为什么进行Scrum事件，如果我们错过其中一项事件是什么坏处，为什么我（ 团队成员 ）应该做某事。 如果SM自己不知道答案，那么您应该联系社区，参加培训，阅读文献。
症状 ：SM向团队成员发出指令，担任董事。 如果将SM的职责赋予前一线经理，而没有说明应该在工作，方法和沟通方面进行哪些更改，则可能会发生这种情况。
不好的是 ：当SM感觉到有力量并开始担任导演时（ 任务分配，会议上的广播等 ），它会杀死团队合作，使人们失去动力，这不再是混乱。 您可以结束自我组织。
如何对待 ：一个不错的选择是将这样的SM发送到培训中，他们将告诉他敏捷文化，并为与团队合作提供新工具。 对于团队本身而言，另一个更困难的选择是尝试更改与SM的通信：建立对话，在做出本地决策时承担责任，提供SM解决方案的替代方案。 您也可以考虑将角色转移到另一个团队成员。
公司互动
症状 ：Scrum主机不共享敏捷值。 这种文化离他不近，他坚持其他观点。 如果SM任命了一个人，而不是他本人表现出履行这一角色的愿望，就会发生这种情况。
不好的是 ：如果一个人不相信敏捷文化，不分享价值观，但同时又是SM，那么他们很可能追求非常雇佣的目标，并且在这些情况下不太可能使团队，产品和公司受益。
如何对待 ：我们寻求/教育/培训SM，谁了解并分享敏捷价值，谁了解Scrum：正在做什么以及做什么。 我们为他设置了运行Scrum的任务，并提供了命令PO和产品。 了解组织中的Scrum面临的挑战非常重要。 我们需要立即确定我们如何理解Scrum的工作原理，以及如何评估指标。
症状 ：SM没有组织团队之间的经验交流。 不能将团队成功转化为公司水平。 没有为整个组织提供其团队的结果和流程的透明性。
不好的是 ：团队存在于公司内部，具有高度自治性，但与公司紧密联系。 如果团队自身处于封闭状态，那么它可能脱离公司的现实，可能变得不必要或无关紧要，可能会在两个方向上产生不合理的期望，等等。
如何对待 ：这一切都取决于公司的敏捷程度和团队所面临的任务。 通常，这是一个非常广泛的选项，但请考虑简化的情况：
- 一家公司的飞行员团队正在考虑Scrum应用程序 ：对于SM来说，这是一个真正的挑战。 他的团队受到整个公司的关注。 我该怎么办：
- 找出（ 有可能与变革的发起者一起发展 ）公司的Scrum面临什么挑战？ 为什么要启动“飞行员”？ 正在检验什么假设？ 如何评估结果？ 它将就实验的持续时间以及公司Scrum命运的决定点达成一致。
- 将此信息带给团队。 开发公司将要监视的指标的可视化。 定期更新视觉指示器。
- 尽可能开放工作。 使员工有机会观察公司的新流程，但又不会损害团队。 定期通知整个公司工作进度。
- 在指定的时间之前准备实验期间获得的结果数据（ 试验小组的工作 ）。 对决定公司的Scrum命运进行广泛的回顾。
- 公司中的团队之一，一部分员工负责Scrum，另一部分员工不负责 ：最有可能的是，公司正在过渡。 SM应该帮助整个公司过渡到Scrum。 在这种情况下可以做什么：
- 保持团队流程和结果的透明性，在公司内部传播此信息（ 公开冲刺审阅，新闻通讯等 ）。
- 组织SM联赛，在这里互相交流，传授新的想法和做法。 分享经验，互相支持。
- 与其他SM一起对抗组织功能障碍 。
- 要参加非Scrum员工的工作，对他们进行Scrum培训，提出他们的流程变更建议（ 如果变更可以带来改善 ）。
- 基于Scrum的公司的团队，使用各种Scrum缩放方法： LeSS ， SAFe ， Nexus等。 ：这里团队同步的问题在于SM。 我没有在此类公司中的实际经验，因此我将不提供任何报价。 但是，了解您的经历将非常有趣-在评论中写下。
结论
再次简短地回忆一下（ 请参阅第一部分的结论 ）如何处理收到的信息：
- 为自己选择最相关的症状；
- 与团队讨论其负面影响，作为推理的起点，请参考我的观点；
- 团队想出减轻症状的方法；
- 做你想出的事;
- 分析结果；
- 从第一点开始重复。
在三篇文章中，我已经能够描述Scrum中角色最明显的症状。 此外，
Scrum指南中的角色描述占19页中的3页。 Scrum指南说“需要做什么”，但要由“如何做”命令来决定，因为它很大程度上取决于特定情况。 在我看来，分享您的实际表现非常重要的经验和做法很重要。 我想相信该材料是有用的，并且您采用了本系列文章中介绍的“医疗”卡。
非常感谢您对Sai Kin的说明！