我们习惯性地喜欢更多更快，无论团队负责人，还是每一位团队成员，所以会花更多时间工作，或者让更多人加入团队。很多人认为敏捷开发就是求快，快速迭代，快速上线。更多更快往往会掩盖一些问题，如果我们一味求多求快，问题就会毫无悬念地暴露出来，所谓“欲速则不达”。不论用什么方法，软件所要达到的目标，并不是快速交付，而是创造价值。

花更多时间或者扩大团队，或许能够“更快”，但并不一定能够产生更大的价值，因为扩大的团队只是增加了劳动力（工作量）。团队生产的价值，要从用户角度去看，我们的软件解决了什么问题，好用吗？容易维护吗？如果这些问题只有团队负责人在考虑，拉长团队成员的工作时间，能创造更多价值吗？

如果我们把时间拉长来看，追求价值与速度是同一件事。两者不一致，甚至有冲突，是因为观察者的时间轴不够长。如果在一个需求固定的项目里看，人手越多，工作时间越长，交付就可以越快，因为需求不变，价值也被固定了。从价值的角度讲，追求更大价值，需求就要不断改进。实际工作中，随着项目的进展，客户和我们自己都会发现更有价值的需求（工作）。如果我们只追求速度，不去理会需求改进，项目进度是保住了，但返工就不可避免，返工最终抵消了我们努力争取的速度，同时还会带来更多成本。

返工带来的成本并不是线性增长，因为系统会因为返工变得越来越复杂，即使是自己写的代码，返工几次，可能连自己也看不懂了。这样的系统想要做任何改变都极其困难，我们从系统上破坏了质量，每向前走一步都会让开发变得更缓慢。看起来“更多更快”的过程，生产的结果就是遗留项目（Legacy System），工作软件的死胡同。

要想以可持续的速度更快发展，唯一的方法就是放慢速度，不急于交付什么，把软件的价值因素考虑进来，用户会怎么用，怎么用更好用？将来能不能升级？这些问题看起来会拖慢速度，却是解决遗留项目问题的唯一方法，开发团队里每个人都要思考这些问题，只靠项目经理或架构师是不够的。我们相信围绕项目经理或架构师制定的流程和工具，可以带来更快的速度，但流程和工具不能生成产品，生产产品的是人。

团队合作是个体实现更大价值的途径，但不要把自己当成团队里的螺丝钉（工具），负责人也不能把团队成员当流程或工具的一部分去追求速度。好的团队里，每一位成员都可以追求价值。在软件领域，敏捷开发并不仅仅是“快速”迭代，而是让团队里每个人都实现价值的方法。

如果你的团队里，大家都很忙，但只有你自己在思考，你和你的团队很可能已经掉入更多更快的陷阱了，陷阱里只有内卷。反内卷，就有让团队每个人都创造更多价值。只靠负责人创造价值，其他人不内卷还能做什么？