这篇文章很难写，并不是因为我没有足够的错误可以分享，而是因为错误实在太多了！错误是我们学习的地方，而我也正是这样做的。我希望分享我的错误能帮助你们避免犯同样的错。
1、在团队之外分享速率
我曾经把速率分享给了高层管理人员。我特意加上了所有的注意事项。“你不能拿一个团队的速率去和其他团队比较，”我说，“这只是用来做计划的一个工具。”我还给他们提供了价值指标，以便他们能看到全貌。
为什么我会这么做？
我以为我是在保持透明度。
为什么这是一个错误？
他们并没有听进去那些注意事项。他们只看到团队A的速率高于团队B的速率，这就触发了他们的指挥与控制本能。即使他们看到速率较低的那个团队实际上也取得了很好的成果，但他们还是觉得有必要要求更高的产出。
结果如何？
团队改变了他们的评分系统，使用了千位数，因为说到底，速率只是一个数字。一个团队的5分故事对另一个团队来说可能是8分的故事。它是主观的，而且只对团队自身的计划有用。（如果你厌倦了速率，可以看看流动效率指标！）
应该怎么做？
分享真正重要的指标——比如客户成果。关注产品目标的进展，而不是毫无意义的数字。
2、让“完成的定义”包含客户批准
这一点至今仍然让我感到痛心。我当时正在与一个主要客户进行一次大规模的敏捷转型。我们希望得到客户的认可，因此我们在“完成的定义（DoD）”中加入了“客户批准”。
为什么我会这么做？
我想保持透明度，并让客户满意。
为什么这是一个错误？
我们的“完成的定义”变成了一个不断变动的目标。原本应该是清晰且可实现的目标，现在却依赖于他人（客户）的意见，而这些意见经常发生变化。
结果如何？
我们的Sprint评审会议变成了审批会议。我们不再是审查已完成的工作，而是花费时间说服客户我们所做的工作已经足够好。这延迟了反馈，减慢了决策过程，并让团队感到沮丧。客户还利用Sprint评审会议来扩大单个产品待办事项的范围，并绕过产品负责人的权限。
应该怎么做？
保持“完成的定义”在团队的控制之下。它应该是一个清单，团队可以在Sprint结束时拥有并完成。客户反馈固然重要，但它应该属于Sprint评审的一部分，而不应作为“完成的定义”中的一个门槛。
3、让Daily Scrum拖得太长
这一点有点令人尴尬。我让每日站会（Daily Scrum）持续了一个小时。每天都是如此。为我辩解一下的话，这是我第一次担任Scrum Master的角色，并且当时还没有接受过培训。
为什么我会这么做？
我认为给每个人足够的时间发言能有助于促进协作。
为什么这是一个错误？
没有人愿意每天坐一个小时的会议。事后看来，这是显而易见的。
结果如何？
几位开发人员好心地把我拉到一边告诉我每日站会应该只有15分钟。我没有听从建议——我以为我是保护了“有价值”的讨论时间。在一个Sprint周期内，有人自愿接手Scrum Master的角色，很快我就被从团队中撤换了。
应该怎么做？
保持每日站会简短——不超过15分钟。这是一个快速同步的机会，帮助团队调整当天的计划。如果有问题出现，在每日站会之外解决这些问题。这样做可以让会议保持聚焦，并让人们尽快回到工作中。
4、误解了Scrum Master的角色
我开始提交任何安全请求或变更控制文件给Scrum团队处理。
为什么我会这么做？
我以为我是通过承担行政工作来帮助他们。
为什么这是一个错误？
承担团队的行政负担使我无法去做我本应做的事情，即帮助团队变得更加自组织。
结果如何？
承担团队的行政负担使我无法去做我本应做的事情，即帮助团队变得更加自我组织。不仅如此，我还成了一个瓶颈。最终，开发人员来找我，问我是否可以让他们自己提交安全请求，因为我拖慢了他们的进度。
应该怎么做？
信任团队处理像提交工单这样的任务。Scrum Master的角色是移除障碍，而不是成为障碍。
5、跳过Sprint评审
我们跳过了Sprint评审，因为我们暂时不准备发布到生产环境。我们认为，“为什么要浪费大家的时间呢？”这是一个大错误。
为什么我会这么做？
我认为如果没有立即发布的计划，Sprint评审是没有必要的。
为什么这是一个错误？
我们错过了与业务部门讨论最重要事项的机会。我们没有根据反馈进行调整，而是试图一次性交付所有内容，结果导致预算超支。
结果如何？
当我们最终交付时，我们发现我们所做的工作并不是业务部门关心的重点。如果我们没有跳过Sprint评审，我们本可以更早发现这些问题。
应该怎么做？
永远不要跳过Sprint评审。即使没有发布，也要用它来与相关干系人沟通，并在必要时进行调整。Sprint评审是为了尽早和频繁地获取反馈。
结 语
我们都会犯错误，这是正常的。关键是要从中学习。我认识到透明性很重要，但前提是这种透明性要有意义。指标应该关注价值，而不是虚荣。会议应该简短并直奔主题。信任你的团队——他们会给你惊喜。记住，Scrum是为了交付价值，而不仅仅是忙碌。记住这一点，你就能避免这些以及其他错误！
原文地址：The 5 Worst Agile Mistakes I’ve Made | Scrum.org
注：部分图片来源于网络
关于作者
【作者】Mary Iqbal
Mary Iqbal 是 Rebel Scrum 的实践敏捷顾问和讲师，教授过数以千计的软件专业人士，是一位经验丰富的敏捷转型教练。Mary擅长通过定义产品和帮助团队自组织以形成最适合的结构，来帮助组织实施规模化敏捷。
Scrum中文网是全球第一个Scrum中文网站，中国最早的Scrum和敏捷教育及推广机构，也是国际Scrum联盟（ScrumAlliance）官方授权教育机构，Scrum.org官方合作培训机构，大规模敏捷SAFe官方机构SAI中国区授权合作伙伴。
Scrum中文网是国内领先的敏捷培训及教练咨询机构，作为中国敏捷教练的摇篮，启蒙和培养了数万名敏捷专业人士，帮助数百家知名企业成功转型敏捷。
