那些抵制冲动，不去掩盖他们的功能障碍，反而选择勇敢面对Scrum揭示严酷事实的组织，往往会经历更多的成功。
让我给你们举一个例子。在我的培训课上，我常常会说下面的话：
程序员和测试员应在同一Scrum团队。他们的目标应该是，在每个冲刺结束时，产出已知缺陷为零的功能。
在一次课堂上，我刚传达这个忠告，一位女士就举手说：“那个忠告在我们这儿行不通。”
我问为什么，她回答说：“嗯，我是QA经理，所有的QA工作人员都向我报告。你刚才说，我应该把我部门的所有人都放在Scrum团队中，而且他们应该帮助团队确保生产零缺陷。”
我说：“是的，就是这样。我知道这是一个很有挑战的目标，一开始你可能无法实现，但为什么不把它作为你的长期目标？”
她回答说：“不，这行不通，因为我们会基于我们的测试员找到缺陷的个数来补偿他们。如果在冲刺结束时，他们没有已知的缺陷，他们的薪酬实际上会减少。”
我等着看她接下来会说什么，因为她如何应对她意识到的这个问题，将在极大程度上提示该公司是否能够成功运用敏捷。
她可能会说,“你能明白为什么我无法把我的QA指派到跨职能的Scrum团队中。我只是不得不用不同的方式来做事情。”
如果她这样说，就等同于她说，当Scrum这道强光暴露了一个障碍，我们不是解决这个面临的障碍，而是调整Scrum（例如，不构建跨职能团队），这样障碍就不存在了。换句话说，我们没有兴趣处理这个棘手的问题；取而代之，我们将继续推进一个可以说是疯狂的政策：根据他们所发现的缺陷个数来补偿他们。
（说到这个，难道这样的政策不会导致串通吗？ 假设我是开发者，你是测试者。有什么能够防止我说：“嘿，我会在这里面放些缺陷，然后告诉你它们在哪里，你“找到”它们，我再把它们弄出去。然后我们一起分奖金！”但我跑题了。）
但是她完全没有那么说。相反，她说，“既然我们显然需要跨职能团队，好像我需要和工程副总裁以及人力资源总监谈谈怎样改变我的QA成员补偿政策。”
我宽慰地松了口气：她的确有兴趣来处理真正的障碍！
注意，在这个例子中，Scrum不是障碍的原因-根据测试员发现的缺陷个数进行补偿，这样一个糟糕的政策明明白白地摆在那儿。并且，Scrum不提供指导如何消除障碍本身。但Scrum的确持续的如一道强光，在这种情况下把障碍暴露给跨职能团队（可以说是良好的编码实践）。在Scrum的强光照射的地方，你的公司选择做什么，将最终决定你在多大程度上取得成功。
