“敏捷已经死了。” 人们一直在说。 但是他们必须补充道：“我们只是在开玩笑。” 他们的意思是
你的错误和愚蠢的做法使敏捷对
你死了。 但是“真正的”敏捷并没有死。 只是每个人都做错了。 所以我意识到：
理论上 ，真正的敏捷就是敏捷。 即使我实现了它。 你知道吗？ 我讨厌
最近，我在我的文章中看到了相同的旧防御：“但是，但是，问题是瀑布，混乱和敏捷的错误实施，不遵守宣言……等等等等。” 然后鲍勃·马歇尔告诉我真相。 他说：“闭嘴，查尔斯。 敏捷宣言就是我们要填补的水罐。” 他发表了一些我必须同意的意见。 我考虑过了 结果就是这篇文章。
这是给您的测试。 敏捷清单的第一行如何开始？ 不要窥视。 不知道吗 一切都很好。 没关系 它说：“我们正在发现更高级的软件开发方法……”停止。 注意，它说：“软件开发”。 它没有说：“拉动您的组织”，“偿还债务以进行转型”，“用这种命令和控制手段将其消除”，“专注于结果并改善开放工作”，“固定您的中世纪预算制度”或其他人们试图投资的更高级的增值。 但是事实是，当人们说敏捷是指整个组织时，这就是修正主义。 这不公平。
还要注意，它开始于“我们
发现 ...”，他没有说：“我们是从上方得到的……”您难道不认为我们从2001年中学到了什么吗？ 我的意思是，是的，大多数大型组织仍陷于1987年，但是，您呢。 与普遍的看法相反，下面的照片并非真的来自签署宣言的行为。 我们最终可以停止假装吗？
清单用于特定目的，但不会引导您到达需要的地方。 因此，开始您的学习。 我们的知识有一个有效期，并且期限不长于我们的想法。 每个人都有同事（通常是老板）声称他们“没有时间学习”。 您自己知道，他们对自己的知识过于自信。 因此，找到一个好的书籍清单。 跟上好的博客。 这是一个开始：如果您还没有读懂
Sense＆Respond ，
精益企业 ，
在桌子上坐下并且
每个人都是变革推动者 ，我建议您立即这样做。 和您的上司。
开始阅读John Cutler，Melissa Perry，Bob Marshall，Allen Holub，Laura Klein，Erica Hall，Neil Killick和他们所引用的文章。 他们是否都同意（或同意我）？ 不，但是它们很聪明，它们也会使您更聪明。 开始阅读并鼓励他人。 Fast Company表示，平均每位首席执行官每年读60本书。 您的领导人读了几本书？ 他们读什么书？ （HBR文章，Gartner报告和Maeve Binchi小说不计在内）。 因为我们面对现实：如果您的领导者是Scrum大师，那么您将牢牢地陷于80年代和90年代。
让我们继续学习，不要假装敏捷是某种治愈方法。 必须这样说：
敏捷一直是局部优化，以稍微提高系统效率 。 只有敏捷将不公平地置于软件开发人员团队之下。 这不会增加组织的灵活性。 不行 有趣的是，根据肯·施瓦伯（Ken Schwaber）的观点（请参阅他的“以任何速度都不安全”），敏捷是一种“补偿瀑布造成的损害”的尝试，但它从未给组织提供全面，可行的替代瀑布的方法。 因为理论和实践之间存在差异。 处理产品更多是一种实践。 当我们抱怨AINO（仅名称敏捷）时，我们对自己并不诚实。
理论与实践，还记得吗？ 我们必须务实。 在实践中，敏捷几乎总是AINO。 机芯本身似乎有问题，对吧？ 无论如何，还有很多重要的事情要学习，包括（但不限于）精益用户体验，精益企业，超出预算，约束理论，吞吐量会计，设计思维，DevOps，马歇尔组织疗法等。
您可能会问，为什么精益UX排名第一？ 由于从
本质上讲，精益UX普及了结果定向的概念。 想想：如果您不知道要尝试创建哪种行为更改，那么您将不了解自己的行为。 如果没有清晰的枢轴信号，那么您将不再灵活。 毕竟，这就是敏捷的关键所在。 有些人可能会反对：“不，不，请检查并适应！” 当然可以 理论与实践，还记得吗？ 我没有看到可以测试和适应的灵活团队。 我看到敏捷团队试图追赶，与吉拉（Jira）和拉力赛（Rally）混在一起，并像在按订单建造砖墙一样工作。
敏捷实际上往往掩盖了主要问题-这是系统的，双向的，缺乏垂直信任的问题。 敏捷的Coachis离开了，情况变得更糟：他们离开了讲猪的经理和开发团队，他们改用了世界语。 团队认为管理层已被打破，管理层认为主要重点仍应放在数量，时间和效率上，而忽略时间表是任意的，而时间估计是
浪费 。 （您知道为了
隐藏时间并帮助解决问题本身而实际发明的故事点吗？这里也有不愉快的后果，对吗？理论和实践）。
猜猜谁会赢？ 有两个截然不同的观点的两个阵营，一个阵营从另一个阵营获得评级？ 如果团队像盲人一样感觉大象并且不同意大象，那么领导力就像盲大象攻击人们并同意他们都是平坦的。 解决方案是认识到系统是
一个团队。 已经完成局部优化，并意识到信任是第一位的问题。 停止不公平地将开发人员放在显微镜下，让其他人躲在黑盒子里。 （为什么我们对战略开发团队的工作方式不感兴趣？还是传统架构师的系统约束如何？）
在执行此操作时，我们应该停止将开发团队当作在工厂工作一样对待。 我们不给塑料碗盖章。 我们创建软件。 您需要停止行动，就像我们在
服务比萨店一样 。 这是其他规则。 我们不会使用相同的经过验证的配方。 我们
开发食谱 。 如果您还不了解，那就是开工，而不仅仅是交货。 忽视发现会导致巨大的损失：未使用的功能和其他无法取得成果的工作。 这揭示了敏捷的另一个深层缺陷。 他建议可以将用户视为豚鼠：“嘿，只要使用这种低劣的产品，我们就会对其进行改进。” 除了低劣的产品通常保持这种状态，不是吗？ 未来的改进成为不必要的“成本”。
但是，但是，但是，敏捷确实专注于研究！ 对不对 我们会诚实的。 理论与实践，还记得吗？ 如果您通过设计或研究谋生，请回答此问题。 您通常如何与灵活的团队合作？ 您最初是否被视为价值并被要求帮助“测试和适应”？ 还是要求您“证明自己的价值”？ 正如艾伦·库珀（Alan Cooper）所说，当您被要求“证明自己的价值”时，您很清楚自己处在一个不重视自己的系统中。 请注意，他们要求参加者证明自己的价值，而不是询问他们的代码中有多少实际上使指标朝着正确的方向偏离。 换句话说，他们仍然专注于人，
而不是工作本身 。 他们可能仍然专注于骨骼，而不是价值，而忽略了价值的很大一部分实际上流失的区域。
如果您与灵活的团队一起工作，则下次要求您“展示您的价值”时，请尝试此操作。 首先问
他们问题。 他们知道延迟的代价是什么吗？ 他们使用什么练习来评估此参数？ 他们试图达到什么具体结果？ 他们的产品实际达到其性能的比例是多少？ 他们不知道吗？ 如果有更快，更便宜的方式找到开发内容的方法，而不仅仅是发布代码，他们是否有兴趣学习？ 它们的流动效率是多少？ 有多糟 他们花多少时间参加会议？ 如果有设计师的游戏和简化的操作可以在更短的时间内带来更好的解决方案，他们是否有兴趣学习？ 因为我不仅会向您展示我的价值，而且还将教您
在所做的每件事中创造更多的价值。
这是另一种思维方式。 这是meta。 这是战略性的。 正如奥斯汀·戈韦拉（Austin Gowella）指出的那样，敏捷和瀑布都专注于
发展 。 设计是
测试 。 如果他们不感兴趣，则可以离开。 如果他们只是放下头来发布产品，专注于成本，他们甚至将永远不会足够了解您通常所获得的不只是您所关注的东西（嗯，骨头）。 这是功能工厂。 相互负责。 他们假装制造塑料盘。 您还有更重要的事情要做。 因为真正的价值是通过
研究产生的选择提供的。 您创建的选项越多，您的方法就越灵活，那么可能的途径就越多，结果越好。 他们想达到什么目的？ 他们是否探索了三到五种方法来实现这一目标？ 这将导致更好的未来决策。 一个选择不是选择。 二是两难。 三-现在您已经取得了一些成就。
听说过必要的《多样性法》吗？ 具有最多选项的组件将
控制系统 。 将其应用于敏捷与瀑布的愚蠢的权力斗争。 您有执行人员试图从上方保持对系统的控制，而灵活的团队则试图将价值带到源头（真实用户和客户）。 摆脱无意义的内战的出路是教人们如何
在各个层面上产生选择。 前进的道路不是针对瀑布的敏捷。 这是明智的自上而下的战略工作（瀑布），具有以经验为导向的自下而上的策略。 两种情况下的设计和发现帮助。
那么...解决方案是什么？ 这是合理地关注清晰结果，而不是交付结果，而不是计划结果，而不是计划结果，而不是项目，而是由可靠的产品团队授权检查假设并找到最短的价值途径。
现在进行培训（根据约翰·卡特勒图改编）。
那么...这是否意味着敏捷将离开？ 当然不是 这只是一个愚蠢的博客文章。 我没有力量 即使是这样，敏捷仍然不会消失。
敏捷运动使许多这样的概念成为可能 。 另外，与普遍的看法相反，敏捷实践不是敏捷运动发明的。 它们出现在几十年前。
所以，不，我不想敏捷离开。
我只想让我们更诚实。