首先声明1：敏捷毒药不是说敏捷是毒药，而是指敏捷中有损组织整体的负面实践，或者说在敏捷旗帜下的负面实践。笔者认为敏捷整体上是很好的，当前研发开发不学习利用敏捷，那就是固步自封了。
声明2：本文做说的组织是多于200人的商业组织，尤其不包括少于50人的创业组织。
声明3：来自Scrum创始人的一句话-There are a lot of development centric practices that are being passed off as Scrum, and worse the best way to do business with customers. These hurt rather than help us.
--- Ken Schwaber
#敏捷毒药#之没有数据支持的计划会议细节任务估算。识别小于16工时的任务，并对每个任务花2分钟以上的时间进行头脑风暴式估算。结果：不可能识别所有细节任务，估算的任务不足，加班；基于不完整工时估算的燃尽图无法使用；计划会议本身耗时过长。
#敏捷毒药#之以Excel为工具，每天跟踪以任务小时为单位来绘制燃尽图，共享Excel为载体，模式一：每人各自跟踪自己的任务，张三修改时，李四最好别改，一个一个轮着改；模式二：一个人修改，这个人每天询问团队每个人:手头任务还需要多少小时做完啊？ 无论哪种模式，都是#敏捷毒药#
由于燃尽图是每天需要跟踪，那么剩下多少人天的填写与剩下多少小时的填写是一样的。 //@JoneQian:如果是按人天呢？我觉得还是毒药！ //@张克强-敏捷307:回复@JoneQian: 所以我将它来绘制任务小时燃尽图的做法称为#敏捷毒药#。
#敏捷毒药#之以xp的隐喻为依据，不维护设计文档，假设团队共享记忆。在竞争变化的环境下，指望稳定的团队及其记忆是不恰当的。
#敏捷毒药#之无视长远和整体的简单设计，简单设计， “收钱走人，剩下不归我管”，设计文档如何做到刚刚好！
#敏捷毒药#之相信代码就是设计，忽略设计文档沟通，以代码作为设计沟通基础，居然就有人相信这个更好？！
#敏捷毒药# 之追求建设多面手团队。人类数千年的历史表明，分工是提升生产效率的一个关键。各专其能、优势互补的团队在现实和银幕上大展神威。建设一支合格的多面手团队耗费太高的成本和时间，对绝大多数组织而言都是不合适。但是多面手能力培养对个人而言是有强大的诱惑力。作为团队的领导尤真是团队以上的领导不要迷信多面手
#敏捷毒药#之以团队自组织为名义，不遵守组织的书面流程和要求，言称我们团队认为……我们团队的情况是……，我们的实践没有必要如何……，将团队决策凌驾于组织决策之上，号称自组织团队是不应当被命令与控制的。
#敏捷毒药# 之全职Scrum Master，有观点说 Scrum Master原则上不应该参与具体的任务，而是应该扮演一个敏捷教练，关键在于empower团队。如果全职Scrum Master只指导一个团队，那成本很高。就算是指导多个团队，其本身也是不稳定因素。因为有如下矛盾：
所掌握的技能 vs. 所在岗位和薪酬
所掌握的权限 vs.所担当的职责
所获得的学习计划 vs.晋升空间
当然如果组织已经对全职Scrum Master的绩效考核和职业路径有方案，那会相对好些，但并不能彻底解决。不如取消全职Scrum Master。
#敏捷毒药#之理想工时和Capacity，一般的计算公式是Capacity=理想工作时间/总工作时间，在使用的时候是理想工作时间=总工作时间×Capacity。Capacity常见的取值范围是50%～80%，在强调价值交付的敏捷中，为程序员争取到了这样的Capacity。
这含糊的指标貌似对程序员有利，从长远看这个指标是含糊的，对团队和组织长远都没用。
#敏捷毒药#之承诺代替数据，按优先级依次逐个回答是否能在本迭代完成，承诺完成的待办事项。 无视历史数据， 将历史数据比喻为昨日天气，无法预测今日天气。
#敏捷毒药#之让他们犯错，然后从中学习。未来需要他们做决定，所以我从现在开始就让他们自己做决定。They decide for themselves, not I. --- 作为指导者，旁观者，可以让他们犯错。 但如果作为上级，最好是追求第一次就做对。