案例分享：度量和怀疑论者
我们团队里一位满头华发、经验丰富的程序员给了我一个脸色，仅仅扬了扬眉，给了一个假笑。是的，这个脸色是在告诉我，把度量告诉那些年轻的家伙吧，看他们打算怎样帮助提升我们的团队，你们做你们的，我不会搞砸什么，他的沉默表明了他的观点。我不想说什么，但是他仰起的下巴让我知道他并不买账。他是一个怀疑论者。
一个月过去了。我们召开了团队会议，我给每一位同事展示了一组公司和产品的度量。它展示了我们的产品目前情况怎么样，我们怎样与竞争产品（就我们知道的而言）相比较，已完成的单个特性如何。我们关注那些在过去6个月里实现的产品特性。每个人都非常投入。这是我们整年中开过的最活跃的一个会议。即使我们满头华发的程序员也提出了很多看法。
又一个月过去了。我们召开了另一个团队会议。在这次会议中我们着眼于公司和产品度量的更新，但是我们同样着眼于从我们近几个sprint（我们使用敏捷方法，因此我们工作的增量是“sprint”）提取的团队度量。我们刚刚发布了一个新的特性。我们思索团队度量如何才能够关联到新特性的接受度、哪些度量是重要的及其原因。那位满头华发的程序员说实现最后一个sprint中特性的工作的复杂度太高，他预计我们的测试或许有些一些问题没有发现，并且我们可能预见有不少的问题会在最终产品中发现。尽管我们的QA经理指出所有计划的测试及完整的回归测试都完成了，但我们都认为有些事值得关注。
又过去了几个月。现在我们拥有关于新特性客户接受度的良好数据，虽然不是十分壮观惊人，但很确凿，并且在产品中发现了一些问题。我们的程序员是对的。相对其他我们跟踪过的特性来说，这个特性的问题的比率和复杂度明显比较高。大多数的问题已经在那个点上修改掉了，但是团队依旧做了记录以便于未来考虑。第一次，我们同样开始考虑个体程序员的度量。我们考虑了在sprint中工作的复杂度，包括产品特性开发和产品bug的修复。我们考虑了每个程序员处理的打断事件，并且我们也考虑了每个人负责多少部分的代码。我们考虑了程序员花了多少时间帮助他人，这称为“助攻”。我们也考虑了基于团队收集的度量。我们讨论这些度量怎样可以关联到团队目标、团队的成功、产品的成功和公司目标。我们同意在接下来的月份继续关注这些度量，看我们可以从中学到什么。
有些有趣的度量显现了出来，一些团队成员对它们提出了自己的看法。例如，有一部分程序员有非常高的工作负荷，但是他们负责的事项的平均复杂度又不高。其他程序员又刚好相反，负责高复杂度但是更小工作负荷的事件。我们没有从中得出什么结论，只是发现这非常有趣，并且说出心中的疑惑：这看起来分布不均的任务复杂度对于团队来说是否是件好事。另一个显著的事实是，当其他程序员没有提供任何协助时，一些程序员拥有非常多的“助攻”。我们讨论了怎样度量这个，请主管来扮演观测员。在这一点上，看起来大家都没有问题。那位经验丰富的程序员什么也没有说。
然而，在两天后他走进了我的办公室。“Dang，”这位程序员说道，“一群伙计对那些年轻人帮助了很多。我没有任何“助攻”—— 我没有做这些。我只是想让你知道我明白了。我肯定会去做我的那一部分。”就是那样。
又一个怀疑论者被同化了。