传说之一：敏捷就等于极限编程(结对编程、Scrum、测试驱动开发、用户素材、或者其他敏捷方法)。敏捷方法实际上是软件开发实践的一个集合，这些实践共享公共的一套原则定义，但除了原则之外其他方面都不相关，有时甚至还是对立的。

　　传说之二：敏捷方法不适合大型组织。这种说法很荒谬。敏捷是包含很多各不相同的方法的一个集合。这些方法中有一些不适合大型组织，但有一些适合，还有一些如果你创新一下的话也可能适合。在做出一个空洞的结论之前，你必须带着问题去研究具体的方法。

　　传说之三：敏捷方法可以用于大型组织。敏捷哲学崇尚“客户合作胜过合同谈判”和“响应变化胜过遵循计划”。跟1亿多个客户合作是艰难的。合同谈判在跨团队依赖性管理方面是至关重要的。(参见第8章的“要么听我的，要么走人”栏目。)遵循计划对于商业承诺来说是必要的，因为合作伙伴在上百万美元面前会变得难以相处。在大规模项目上应用敏捷方法，要求你灵活而创新地去处理好这些问题。

　　传说之四：敏捷意味着不写文档。敏捷哲学崇尚“可以工作的软件胜过面面俱到的文档”。很多敏捷的狂热者看到这个就认为，“啊，不需要文档了!”如果你认为走廊的尽头也就是世界的尽头的话，那你也不该得到在你的围墙之外产生的大量收益。敏捷哲学申明了，“虽然右项也具有价值，但我们认为左项具有更大的价值。”换句话说，可以工作的软件比文档更重要，但必要的文档对客户、合作伙伴和跨部门的依赖方仍然是有价值的。

　　传说之五：敏捷意味着没有前期设计。敏捷哲学崇尚“响应变化胜过遵循计划”。 很多敏捷的狂热者把这误解为，“没必要思考或做计划，设计到时候将突然出现!”突然从哪里出现?一个放射性污水堆积处吗?这里的要点是说，响应变化胜过过分死板地遵循原来的计划，而不要纵身跳下悬崖之后再去看会有什么后果产生。

　　传说之六：敏捷意味着没有个人责任。敏捷哲学崇尚“个体和交互胜过过程和工具”和“响应变化胜过遵循计划”。很多管理者看到这个感到很恐惧，认为这个意味着完全没有责任可言。实际上，敏捷在这个领域收到的效果恰恰与管理者担心的相反。敏捷使个体对团队负责，而团队对管理层负责。责任性大大地加强了，并且额外的间接层次让敏捷团队更加有效、有韧性、并且名副其实地“敏捷”。

　　传说之七：Scrum是个缩写词。这是个很无聊的传说，但它几乎让我发疯。Scrum是最有名的、并且实践得最广泛的敏捷方法之一，但它绝不是一个缩写词。Scrum是根据橄榄球术语来命名的，代表比赛双方的团队聚在一起，两手呈圆形闭止，准备争球。它也是Scrum团队每日例会的名字。在微软，我们已经使用了一种类似Scrum的方法达数十年，比这个术语出现要早得多。Scrum是最简单的敏捷方法之一，也最接近于微软的很多团队在现实中采用的方法。后来，更多的团队转向了Scrum。