企业敏捷的前提假设是工程师不够聪明，无法自己搞清楚内部客户需要什么。工作被原子化为”用户故事”和”迭代”，剥去了任何成就感，剥去了设定长期愿景的希望。结果是一个接一个盲目的、短视的冲刺，没有进步，没有改进，只有工单接工单接工单。
简单图景
想象一个小说家每两周必须向一群不会写作的人解释每一段的存在理由。委员会评不了文笔，只能数页数、量速度、看大纲。小说家不再为美写作，开始为指标写作。书按时交了。是垃圾。所有人宣布流程成功，因为流程被遵守了。
暴力透明
开放式办公是最显眼的症状。需要向投资人汇报的风投支持的创业公司用它让工作空间看起来很忙。但更深层的形式是流程层面的：敏捷系统要求程序员对自己的时间和工作提供**屈辱性的可见度，且没有对等关系。**业务侧看到工程师做的一切。工程师对决定他们做什么的业务决策一无所知。
这就是可读性即权力在组织中最纯粹的形式。工程师被置于对坐在系统之上的人最大程度可见的位置。上面的人则保持不可见。每一次映射都是一次圈地，暴力透明将工程师的整个工作生活圈进一个由别人阅读的仪表盘里。
创造性的人在被要求边工作边解释自己时，就会失去创造力。内在博弈精确地解释了原因：当自我1的干扰消退时，自我2才能做出最好的工作。对创造性工作要求实时论证，就是要求自我1全程监督自我2，而这恰恰是自我2停止运作的条件。玩耍的框架也映射于此：分心是你的潜意识在用脚投票，因为它怀疑这趟旅程的意义。敏捷没有修复分心，它将分心制度化了。
暴力透明文化是为最不敏感于地位的人设计的：年轻的、特权的男性，没有在工作中被考验过或烧伤过。年长者、女性、少数族裔和残障人士在职场中往往对地位敏感，因为这关乎生存。单向透明对他们打击最大，不是因为他们能力更差，而是因为当你的位置本就岌岌可危时，可见性的代价在结构上更高。
永久初级
两周一次的冲刺**没有退出策略。**没有”一旦我们达到X就不再需要这个”的条款。流程是永久的，无论资历还是已证明的能力。这就像在组织层面告诉一位资深外科医生，他必须向一位行政人员实时解释每一刀，永远。
程序员在掌握基础后想要承担的项目，架构改进、长期技术投资、探索性研究，被忽视了，因为它们很难用短期业务价值来论证。约束理论解释了机制：估算将人推向做可估算的工作，也就是低价值、容易、可预测的工作。任何值得做的事都有太多未知的未知，让估算毫无用处。敏捷对短期价值的聚焦把人从公司真正需要的工作上推开，转向每个程序员的实时声誉管理。这就是团队层面的古德哈特定律：速度变成了目标，而一旦变成目标，它就不再衡量生产性产出，开始衡量工单博弈。
专家型初学者在这种环境中如鱼得水。永久初级意味着没人被期望发展超出高级初学者阶段。系统奖励工单吞吐量，而非深度。技术债堆积如山，因为做决定的业务人员直到为时已晚，或至少修复成本过高，时才看到问题。
五个结构性缺陷
**1. 业务驱动的工程。**就像一个通过扩散贫穷来实现平等的失败共产主义国家，Scrum把所有工程师放在同一个低层级，在决定做什么的业务人员之下。当人们感觉所有重要决定都已在别处做出，他们就没有动力做出最好的工作。格维斯原理精确地框定了这一点：工程师被置于失败者位置，意识到糟糕的经济交换，被剥夺了有意义的能动性，被告知保持忙碌。
**2. 永久初级。**第一年的程序员和十五年的老兵没有区别。两者都拿到”用户故事”。两者都参加同样的站会。两者都被同样的速度指标衡量。这就是制造稀缺性应用于职业意义，系统承担不起承认有些人已经超越了它。
**3. 危险的短视。**在紧急情况下激进的项目管理说得通。作为永久安排则说不通。在敏捷之下，每个冲刺都被当作紧急状况处理。OSS破坏手册的指示，“在有更关键的工作要做时召开会议”，完美地描述了每日站会。
**4. 没有职业连贯性。**说”我曾在一个Scrum团队中”传达的信息是你被视为可替换的。面具-守护灵动态适用：工程师的职业人格（面具）必须不断表演合规，而守护灵，他们真正的技术抱负和创造驱动力，在底下日积月累地无人理会。
5. 假阳性识别。Scrum被包装为”移除障碍”，一种”揪出懒人”的好听说法。问题是它制造的低效者比它揪出的更多。人们知道谁是低效者。他们之所以持续存在，是因为没人对此采取行动，这是人员层面的管理问题，不是工作流层面的流程问题。反馈管道是正确的框架：流程无法替代管理者进行一场直接对话的勇气。
低手 / 中手 / 高手
低手的看法是”敏捷很棒，它让团队负责任并交付产品。”
中手的看法是”敏捷理论上没问题但实践中糟糕，团队只需要正确地实施它。”
高手的看法是企业敏捷不是方法论的失败，而是一种伪装成流程的权力安排。它给予业务侧对工程的全面透视，却不给工程真正的权力。它用合规替代了主人翁意识。它将工作原子化到没有任何个人能为任何有意义的东西邀功。敏捷起源的咨询场景，高风险的客户项目，存亡攸关，确实受益于激进的短期迭代。将这种应急姿态移植为产品开发的永久安排，就像让一家医院每天都在分诊模式下运行。所有人都很忙。没有人在治愈。
核心收获
关于Scrum的真相是它并没有让工程更快或更好。没有证据支持这一主张。它所做的是让工程变得可读，对不理解这项工作的人而言可见、可测量、可控制。这笔交易是用自主权换可读性，而做出这笔交易的人不是付出代价的人。工程师付出的是创造力、职业连贯性，以及任何超越下一个冲刺的抱负的缓慢死亡。
人件早在一代人之前就阐述了同样的论点：方法论是试图集中化思考，隐含地宣布人们不够聪明，无法自己思考。如果人们严格按照方法论说的去做，流程就会磨到停摆，这就是为什么恶意合规永远潜伏在一次挫败之后。
修复之道不是更好的流程。修复之道和花园中反复出现的答案一样：**信任。**信任工程师能搞清楚什么需要做。信任创造性的人需要松弛、自主权和在产出最重要的工作时看起来不生产的自由。信任瓶颈很少是工程产能，几乎总是那些软约束，政策、站会、估算、工单，它们在看似管理瓶颈的同时消耗着瓶颈的产能。
参考：
- Michael O. Church, Why Agile and Especially Scrum Are Terrible