1、在团队之外分享速率
我以为我是在保持透明度。
他们并没有听进去那些注意事项。他们只看到团队A的速率高于团队B的速率，这就触发了他们的指挥与控制本能。即使他们看到速率较低的那个团队实际上也取得了很好的成果，但他们还是觉得有必要要求更高的产出。
团队改变了他们的评分系统，使用了千位数，因为说到底，速率只是一个数字。一个团队的5分故事对另一个团队来说可能是8分的故事。它是主观的，而且只对团队自身的计划有用。（如果你厌倦了速率，可以看看流动效率指标！）
2、让“完成的定义”包含客户批准
这一点至今仍然让我感到痛心。我当时正在与一个主要客户进行一次大规模的敏捷转型。我们希望得到客户的认可，因此我们在“完成的定义（DoD）”中加入了“客户批准”。
我们的“完成的定义”变成了一个不断变动的目标。原本应该是清晰且可实现的目标，现在却依赖于他人（客户）的意见，而这些意见经常发生变化。
我们的Sprint评审会议变成了审批会议。我们不再是审查已完成的工作，而是花费时间说服客户我们所做的工作已经足够好。这延迟了反馈，减慢了决策过程，并让团队感到沮丧。客户还利用Sprint评审会议来扩大单个产品待办事项的范围，并绕过产品负责人的权限。
3、让Daily Scrum拖得太长
这一点有点令人尴尬。我让每日站会（Daily Scrum）持续了一个小时。每天都是如此。为我辩解一下的话，这是我第一次担任Scrum Master的角色，并且当时还没有接受过培训。
我认为给每个人足够的时间发言能有助于促进协作。
几位开发人员好心地把我拉到一边告诉我每日站会应该只有15分钟。我没有听从建议——我以为我是保护了“有价值”的讨论时间。在一个Sprint周期内，有人自愿接手Scrum Master的角色，很快我就被从团队中撤换了。
保持每日站会简短——不超过15分钟。这是一个快速同步的机会，帮助团队调整当天的计划。如果有问题出现，在每日站会之外解决这些问题。这样做可以让会议保持聚焦，并让人们尽快回到工作中。
4、误解了Scrum Master的角色
5、跳过Sprint评审
我认为如果没有立即发布的计划，Sprint评审是没有必要的。
我们错过了与业务部门讨论最重要事项的机会。我们没有根据反馈进行调整，而是试图一次性交付所有内容，结果导致预算超支。
结 语
我们都会犯错误，这是正常的。关键是要从中学习。我认识到透明性很重要，但前提是这种透明性要有意义。指标应该关注价值，而不是虚荣。会议应该简短并直奔主题。信任你的团队——他们会给你惊喜。记住，Scrum是为了交付价值，而不仅仅是忙碌。记住这一点，你就能避免这些以及其他错误！
https://www.scrum.org/resources/blog/5-worst-agile-mistakes-ive-made
注：部分图片来源于网络
关于作者
【作者】Mary Iqbal
【译者】Scrum中文网翻译组
Scrum中文网是全球第一个Scrum中文网站，中国最早的Scrum和敏捷教育及推广机构，也是国际Scrum联盟（ScrumAlliance）官方授权教育机构，Scrum.org官方合作培训机构，大规模敏捷SAFe官方机构SAI中国区授权合作伙伴。
Scrum中文网是国内领先的敏捷培训及教练咨询机构，作为中国敏捷教练的摇篮，启蒙和培养了数万名敏捷专业人士，帮助数百家知名企业成功转型敏捷。
往期回顾 | |
| 精选合辑 | SAFe规模化敏捷 | |
