葡萄牙语版本在这里
我们尝试在许多公司中实施它们的方式，Scrum不起作用…敏捷不起作用。
为什么在Scrum指南中“理解/理解”一词仅在19页中出现23次是有道理的。
许多公司不了解 Scrum，也不了解 Scrum Master的角色。 这些公司希望实施一种“敏捷”的方法，该方法鼓吹一个自组织的团队，并聘请“ Scrum Master”担任项目经理。
总是欢迎拥有并应用Scrum Master知识的项目经理。 但是，雇用Scrum Master并指派他担任项目经理的角色是一个强烈的信号，表明在该公司中，每个人都会觉得敏捷不起作用。
也许会感到有所改善！ 公司的情况“最糟”是，敏捷方向的微小变化更容易产生积极影响。 但是，团队的开发人员可能会讨厌该公司表示使用的Scrum。
开发人员独自工作：他使用耳机，喜欢开发，以自己的步调发展，一切都很好。 但是这里出现了一家拥有“ Scrum”的公司，该公司说，从现在开始，他将必须参加无数次会议，让他和他的同事在一个可见的框架内向所有人公开，并且仍然必须处理这样的Scrum Master和Product所有者。
当公司聘请Scrum Master担任“了解Scrum的项目经理”时，它期望有人知道当前的“敏捷规则”，并通过负责和控制开发团队来执行这些规则。 很少有人知道Scrum不是确定的过程，技术或方法。
根据《 Scrum指南》，Scrum Master通过多种方式为组织服务：
了解和练习敏捷性；
了解经验环境中的产品计划；
帮助所有人了解 Scrum的理论，实践，规则和价值观；
帮助Scrum团队之外的人了解他们与Team Scrum的哪些交互有用，哪些无用；
确保Scrum团队的所有成员以最佳方式理解目标，范围和产品领域；
帮助Scrum团队了解清晰明了的产品待办事项的需求；
在没有完全采纳和理解 Scrum的组织环境中对开发团队进行培训;
帮助员工和利益相关者了解并应用Scrum和经验产品；
确保事件发生并且参与者了解他们的目的。
没有这种理解，也没有敏捷的思维方式，Scrum公司的所有事情都会出错。
仅谈论Scrum框架的基本结构，该公司将开始其“敏捷转型”：
任务板
- 通过使用任务板，开发人员了解到有自己的名字的帖子和带有同事姓名的帖子，并且从现在开始，每个人都将看到其他同事更快地“交付任务”比他强，除了被迫加快自己的步伐，失去工作质量，失去工作动力和成就之外。
此外，开发人员可能会觉得他的同伴要完成比他更多的任务，就好像这表明他们更有生产力，然后决定再执行一项任务，而不是帮助同事完成已经完成的任务。 这会产生WIP（进行中的工作），并因此延迟发布用户故事进行测试，从而导致同时发布多个故事进行测试的结果，从而导致质量检查队列出现瓶颈。
没有Scrum Master的正确工作，可能无法理解此工具的用途。 该框架是一种视觉资源，可用于增强可见性和透明度的概念。 使用该框架，可以在几秒钟内概述项目进度：排队的任务，开发，测试，阻止等。任务不能按数量交付。 谁移动了更多任务，谁就不会比那些少移动任务的人工作得更多，即使是冲刺属于团队，董事会也属于团队，而任务属于团队。
日常会议
- 在每天的会议中收取参加者的费用，开发人员得知那是他需要“负责任”的时刻，因为他需要告诉所有人，特别是老板，他所做的一切。 现在该显示他的工作量了。
没有Scrum Master的正确工作，可能无法理解这次会议的目的。 在15分钟以内的会议中，团队只是在同步。 目标是使每个人都知道在冲刺结束时每个团队成员都在寻求价值，并可以帮助其同事完成或解除他们正在从事的任务。
冲刺计划
- 在Sprint计划会议中向与会人员收费，团队了解到该团队需要使用通用的工作量度对每个故事进行评分，查看其在先前的Sprint中能够实现的工作量点，然后确定“适合的故事数”在当前的sprint中。
没有Scrum Master的正确工作，可能无法理解这次会议的目的。 团队需要详细了解每个故事。 当目的是了解所涉及的业务规则时，不会有太多问题。 团队需要建立Sprint目标，并且哪些Product Backlog项目（如果完成）将实现此目标。 根据DOD（完成的定义），开发团队从那里决定如何在Sprint期间开发这些功能，并将其转变为“就绪”产品增量。 产品负责人需要与利益相关者充分合作，并了解开发团队针对此Sprint的故事制定适当的优先级和谈判条件的能力。
冲刺回顾
- 收取参加审核会议的费用，在该会议上，将不收集将要审核的产品的增量或对其进行修订的方式。 在拥有分布式系统的大型企业中，增量通常是API和服务端点的实现或更改，因此，本次会议不会为利益相关者增加价值，也可能根本无法完成。 在小型公司中，团队经常在没有利益相关者在场的情况下参加会议，这常常使会议失去对会议目的的关注，这也仅仅是“作为Scrum的一部分”而完成的，然后我们甚至看到老板为未完成的部分负责开发人员通过指出“另一个同事的责任分担”作为失败的原因来捍卫自己免受批评。
没有Scrum Master的正确工作，可能无法理解这次会议的目的。 在这次会议上，产品负责人邀请利益相关者，并说明哪些项目已经完成。 开发团队演示完成的工作，并回答有关产品产生的增量的问题。 他们一起讨论下一步要做的事情，为下一次Sprint计划产生有价值的信息，以便针对市场量身定制产品，调整时间表等。
冲刺回顾展
- 在Sprint结束时举行的回顾性会议中增加与会者的出席率，在该会议上，团队了解到每个人都应该表达自己的不满，对出现问题的地方进行投诉，并为取得成功的情况做出反击。
如果没有Scrum Master的正确工作，就可能无法理解这次会议的目的，那时团队可能正处于经验研究过程中的最重要时刻。 在检查和修改的主要时间。 团队可能不明白目标是让这次会议有待执行的措施，以维护甚至改善进展顺利的事物，改善甚至阻止发生错误的事情。
许多开发人员已经因在其他公司中配置错误的Scrum部署的不良经验而来。 通常，宣布公司决定开始与Scrum合作已经在这些人中产生了可怕的抵制，他们已经给他们带来了对Scrum和Agile的深刻印象。
Scrum Master需要发展他的教练技能。
例如，如果您到达一个使用较旧模型（而非敏捷）的开发团队，并询问：
“嘿，伙计们，您认为我们在这里，靠近我们，对业务有更多了解的人……在我们与利益相关者之间建立联系的人是谁？ 它有助于了解活动吗？ 它有助于解决疑问吗？ 你怎么看？ “
每个人都为这个想法欢呼的可能性是巨大的。
这跟告诉所有人我们现在有一个产品负责人不同。
向“时间”询问类似的事情：
“您如何看待我们每天早上非常迅速地站在一起站起来，互相告诉对方每个人在做什么？”
要么
“我们每两周召开一次会议，讨论为了改进我们的流程哪些方法有效，哪些方法出错了？”
每个人都为这些想法欢呼的可能性是巨大的。
如果您谈论每日和回顾，则有所不同。 如果您谈论Scrum，那就不一样了。 因为它会唤醒人们对以“自动模式”完成的过程的糟糕记忆，而在这种情况下， 人们对原因为何一无所知。
为了使Scrum工作……为了使敏捷工作，人们需要成为团队的一部分。 他们需要真正感受到团队的一部分。 一个自我组织的团队，每个人都有自己的决定并拥有自主权。
施加规则或告诉人们如何执行规则几乎不会产生持久的行为变化。 团队需要自行决定。 Scrum Master必须在场，以利用他的知识，工具和经验来鼓励问题，进行讨论并提出可能。 整个团队决定。 小组做出的决定仍然存在，然后进行敏捷转换。
这样，Scrum起作用了……敏捷起作用了。
