敏捷最大的敌人是客户
比起组建高素质和自管理的团队更难的事情是遇到负责任和价值驱动的客户。业界对敏捷最大的担忧是如何才能够组织起一支不需要任务驱动且充满活力的职业团队，特别是在大型开发团队中。然而往往被忽略的是，在这条价值产品线的最开端，我们是否能够保证，提供需求的客户团队是价值驱动且负责任的。
有一个非常坏的语境—敏捷就是拥抱变化。这样经常被销售人员兜售的卖点往往被客户曲解，敏捷从适应市场快速变化追求快速反馈的一种较为科学的方法论，成为一种放纵客户需求变化的托辞—我不需要想太清楚，因为你们告诉我敏捷拥抱变化。结果变成，当我们需要合理的快速反馈时，我们得不到真正的反馈，那个我们唯一希望拥抱变化的理由—既通过快速反馈改进我们的软件—成为一种可有可无的东西。
问题的关键在于拥抱变化被严重曲解，这样的曲解使得我们的客户变得越来越不负责任。这种曲解被转化成最有杀伤力的销售语言：如果你们总是拿不定主意，你们的需求总是摇摆不定，那么请使用敏捷。而拥抱变化的含义应该是：我们希望快速反馈，不断改进我们的软件，让它快速投入市场满足变化的市场需求。而往往我们在犯得错误是，我们乐观得认为没有反馈或者反馈很少是因为我们做得不错，于是这样的鼓励机制很默契地变成一种大家皆欢喜的幼稚，我们时常感到前4个迭代会很愉快，不是吗？
我经历过负责任和不负责任的客户，我也经历过我们面对不负责任客户，负责任和不负责任的态度。负责任的客户不会只是坐收其成，他们会关注每个特性所带来的价值同时考虑投入产出比；他们会细心地回答需求确认中产生的任何疑问，避免因为需求不明造成的浪费；他们欢迎任何业务上的讨论并认为这是件令人愉快的事情；他们会认证验收每一个被交付的特性并努力收集有价值的反馈帮助改进。
不负责任的客户认为能不能把需求弄明白是承包商的事情而跟我是不是说清楚没有关系；他们反复跟我们强调所有东西都是优先级很高的东西；他们永远在等待我们的反应，并不主动提供任何信息；他们总是需要等到一切就绪再提出改进意见；他们总是说：“不要问，只管做”或者“挺好挺好，没什么问题”。
而对此不负责任的反馈是跟着客户一起睁一只眼闭一只眼，对于客户的无价值反馈或不反馈坐视不管，甚至不在乎客户是不是验收用户故事，或者说更在乎团队velocity和进度—并不是一个“done－done”团队。应该做的是让客户明确认识到这样所带来的巨大风险，我们曾经遇到过，客户不验收不进行下迭代开发的案例。但是，坦白说，只有足够信任的客户关系才能达到后面这种情况，更多的情况是，面对客户我们，至少是开发团队无法足够有勇气做出这样负责任的决定。
最重要的是请理解拥抱变化的真正含义。对于交付团队来说，最安全的事情就是不变的需求（我们当然乐意不变的需求）。传统方法的不足在于花大量时间确定的需求最后在业务上就已经改头换面，但是敏捷的优势不在于灵活变化交付物适应需求变化，而是通过拆分需求将需求确认的颗粒度变细，从而降低需求变更的风险。也就是说我们解决不了需求变化的问题，我们只是减小了需求变化造成的浪费而已。
敏捷项目的销售者，请努力澄清关于敏捷拥抱变化的概念；敏捷项目的风险控制者，当你意识到团队面对的是一群不足够负责任的客户，请动用自己可以动用的一切资源，帮助客户认识到不负责任的巨大风险，这将是你对项目有可能产生的最大贡献。