反敏捷宣言
很多时候，敏捷在实践中并没有帮助团队更好的完成工作，而是成为了某种障碍以及僵化的流程。原文: The Anti-Agile Manifesto
警告1: 如果你是敏捷教练或Scrum Master或任何其他形式的敏捷支持者，本文的很多内容都会让你不爽。本文的目的之一是通过指出敏捷的问题让大家重新关注敏捷，而不只是对敏捷进行羞辱。
警告2: 本文有多个梗是来自《甜心先生》。
我在过去几个星期里参与了很多次关于敏捷教练如何与错误的人群接触的讨论，我们无法和只知道写代码的开发者建立联系。通过和好友(Colleen Johnson，Daniel Vacanti，Janee McConnell的谈话，我们还发现另一个问题，CXO以及高级管理人员也对敏捷不感兴趣。与此同时，我们还抱怨中层管理人员，抱怨他们很难转向我们的敏捷方式。如果没有人真正对敏捷感兴趣，那或许问题是出在产品本身。
这就是触发我们写这篇杰里·马奎尔式宣言的原因。
造成伤害
敏捷促使人们采用很多东西，这些东西一直困扰着行业，其中许多是故意的，也有许多是无意的。
去任何开发人员聚集的discord或reddit子站，看看他们对敏捷的看法，绝大多数人讨厌敏捷。他们认为敏捷是:
- 通过会议给一天的工作带来不必要的干扰。
- 估算故事点，并对错过承诺"找理由"。
- 让非技术管理员(Scrum Master)跟踪研发状态，对他们进行微观管理。
- 在满足Sprint承诺的压力下，还必须将支持和业务工作作为日常工作。
- 花好几个小时在无关紧要的计划和回顾上。
- 额外的开销和更多的官僚主义，在大规模团队中尤其严重。
这是因为他们不得不承担额外负担，而且妨碍了他们完成工作。如果我现在是一名"敏捷转型"中的开发人员，我不知道该听谁的——我的经理、Scrum Master、RTE还是敏捷教练，也不知道我的主要职责是完成工作还是谈论工作。
我们非但没有提供帮助，反而伤害了我们一直想要支持的人。在大多数敏捷实现中，开发人员被忽视了。
现在我已经知道了，这些都是"糟糕的"敏捷实现。我当然接受这个结论，不过还想问一下——有多少比例的敏捷实现是"糟糕的"？我不知道，但根据我亲自看到的以及线上的讨论，我猜超过90%是糟糕的实现，并且并不是因为人们没有努力。后续问题是——如果我们同意90%以上的实现都是糟糕的，那么问题不就是实现本身吗？如何保证未来90%的实现不会出错？
敏捷在其价值观和原则上可能很伟大，但在实现上却并不是。这并不是因为没有聪明和专注的人用它，而是因为作为工具，大多数敏捷方法都是有问题的。
敏捷无法为开发者解决问题，对CEO/CTO/CIO来说也毫无意义。作为高级管理人员，我为什么要关心Sprint、故事点、PI、WIP限制或任何类似的东西？我在这里不是为了"让组织变得敏捷"，而是为了提高投资回报率——"Show me the money"。
关注错误的东西
所以，开发人员讨厌敏捷，高管们对此漠不关心。因此我们不得不(有意或无意)成为了团队领导，让Scrum Master领导团队。或者，虽然有其他人领导团队，但我们创造了敏捷教练。敏捷业务已经变成了如何帮助Scrum Master成为更好的Scrum Master，以及如何帮助敏捷教练更好的指导敏捷。
在这个过程中，我们并没有试图回答每个服务提供者都应该回答的简单问题: 敏捷的经济效益是什么？有多少敏捷教练或Scrum Master可以直接展示他们的工作对组织的财务意义？消费者的期望是获得更大的价值回报，为此他们付给我们报酬。我们能用金钱证明我们能让组织更有效率吗？我们能证明我们提高的组织收入或降低的成本，可以超过他们在我们身上的投资吗？
敏捷在很长一段时间里一直专注于错误的事情，reddit的敏捷版块就是个很好的例子。看看过去一周(2023年8月中旬)的热门职位(我敢肯定，如果你现在去看也还是一样)，很多帖子都在讨论该拿哪个证书、讨论"UAT应该通过PO还是BA来完成?"、如何处理表现不佳的开发者、讨论"信任比敏捷更重要"，以及我最喜欢的关于框架、方法论的区别的讨论，最后是"你能坚持做敏捷多久?"
总是有人会问——"你给缺陷分配故事点了吗?"问这些问题的人没有错，我们所建立的这个让他们问这些问题的行业错了，我们一直把注意力放在错误的事情上。
把敏捷做的更好
我们太过专注于"把敏捷做得更好"，以至于没有为那些我们打算帮助的人提供足够的服务。开发人员并不关心敏捷，他们想要创造人们会使用的东西。作为开发人员，最满意的时刻是解决了客户问题，而不是完全正确的完成了Sprint计划。敏捷并没有帮助开发人员解决正确的问题，而更多的是阻碍了开发人员解决客户问题。
开发人员要花更多时间参加敏捷活动(我们没有偷懒，而是认真召集会议)和冲刺，而不是与客户一起解决问题。花在会议上的钱比花在与客户合作创造他们愿意为之付费的产品和服务上的钱要多。开发人员不知道如何为组织做出贡献，但肯定知道冲刺速度是多少。他们被反复告知没有正确的做敏捷……而这是理所当然的事情。
我们需要从"更好的做敏捷"转向"高效的打造客户愿意为之付费的产品"。
忽视组织需求
我们自欺欺人的认为，组织需要能够帮助他们"实施敏捷"的教练。这对组织来说并没有投资回报率，组织实际需要的是效率、效益和可预测性，需要的是真正承认资源有限、需求不断增加的经济现实，需要能帮助他们了解如何改善财务状况的方法。多少次sprint等于提高10%的效率？还是以讨论会的次数来衡量？也许和我们花了多少时间梳理积压工作而不是开展工作有关。
在经济困难时期，需要把重点放在使组织盈利上，这样人们才不会失业。这也应该是敏捷的重点，如何在资源稀缺的条件下运营并做出更好的决策，其他都不是必要的，让别人去研究吧。敏捷教练的价值最不为人所知，因此会首先被解雇。不仅管理层这么认为，教练本身也这么想。我们没有经济框架来体现价值，无法证明我们为降低成本或增加收入做了什么贡献，所能证明的只是"现在做的是敏捷的事情"。
在此提出一个转向建议，我们需要停止谈论敏捷，而更多开始讨论如何帮助组织变得更有效、更高效、更可预测，帮助组织更好的管理风险，而不是更好的完成敏捷仪式。当前我们在敏捷中谈论的很多事情，都与之背道而驰。
确定性思考
我们延续了完全反敏捷的确定性思维。故事点、迭代计划、冲刺、优先级排序和backlog排序在本质上都是确定性的。这些做法鼓励人们从以下角度思考问题：这是要在规定时间内按照规定顺序完成的工作量。不管出现什么情况，即使我们知道了新信息，未来2-4周或一个季度的计划也不会变化。我们知道这不对，但还得这么做。但世界不是确定性的，不是每个人的想法都一样。
在每个评估和流程中都存在可变性，而我们的"计划"方法不承认。我们从单一的确定性计划中出来，这个计划不承认敏捷所基于的多个选项和支点。然后，当高级管理层没有看到敏捷性时，我们却会觉得很惊讶。
很多人读了这篇文章之后都会说:"我们被迫以错误的方式使用这些敏捷概念，这不是我们的错，因此我们觉得至少应该尝试在团队层面上做出一些小改变，即使公司在泰勒主义、急功近利和无知的助推下熊熊燃烧，我们也从未真正回答过如何让组织变得更高效、更有效和更可预测....因为大多数人都无法有把握的回答这个问题，更不用说用数据和金钱来支持这个问题了"--Janée McConnell
是的，我知道这不是开明的敏捷人士想要使用的方式，但现在就是这样被使用的……是的，这就是敏捷的错。如果枪支继续被用于自杀和大规模谋杀，作为社会来说，某种程度上必须审视我们的文化，而不只是坐下来说"人们使用枪支的方法不对"。
我们所有方法都被认为是精确和确定的，很少有人谈论风险。高级管理层感兴趣的是--风险在哪里，有多大，如何管理风险。所有关于敏捷的讨论都围绕着如何组建团队，如何进行站会和回顾，以及组建发布团队的正确方法，只有极少数人谈论实际的风险管理，而高管们真正感兴趣的是风险管理。
小团队
大多数敏捷教练和Scrum Master都只有团队级经验，我也一样，直到我回去积累了更多组织级经验。这种团队级经验最适合转化为教练团队的经验，也是所有敏捷教练的起点，可以让我们帮助团队更加敏捷。此外，我们一直在向组织推行小团队的废话。我们告诉人们，小团队更敏捷。在这个过程中，我们把200人的组织变成 25个团队。很好，现在我们在一个充满依赖性的系统中拥有了敏捷团队，在整个组织中存在着一大堆乱七八糟的依赖关系，导致整个系统的运行速度慢如蜗牛。每个团队本身都能产生更多的产出，但由于依赖关系，没有任何东西能送达客户手中。
然后我们来解决这个问题，创建更多角色，这些角色的工作是管理依赖关系并每周检查状态。事实上，我们创建了一个为期3天的大型计划活动来发现和协调所有这些依赖关系，在此期间我们需要讨论未来3个月的计划中出现的所有依赖关系。虽然我们很清楚，在现实世界中，这个计划将在未来5天内分崩离析。
通过减少团队数量来降低依赖性怎么样？如果把200人的组织分成7-8个小组而不是 25个小组呢？这对依赖关系有什么影响？这对互动有什么影响？更重要的是，这对组织层面的效率有什么影响？可预测性如何？投资回报的整体效益如何？规模更大的团队可以拥有更多类型的专业人才，从而提高端到端协调效率，有更多后备人员来确保可预测性，以及更好的处理反馈的能力，从而真正提供客户愿意付费的服务。
所以不要再设立奇怪的"两个披萨"式的规则了，这些规则实际上会限制组织的改进。我们需要帮助组织更加有效、高效和可预测，而不是使团队更加敏捷。
底线
多年来，我一直宣讲和教授敏捷，我并没有对它"一见钟情"，但敏捷绝对是我工作的重要组成部分。我认为，敏捷需要转向组织真正需要的东西--效率、效益和可预测性，敏捷教练需要成为这些方面的教练。
我对以敏捷为名的做法感到愤怒，你可以继续教授Scrum(或SAFe，或Kanban)，但一定要告诉学生，如果不能改善组织的底线，那就做出改变，告诉他们转向真正有帮助的实践，而不是去琢磨15分钟的站会。敏捷是实现效率、效益和可预测性的一种方法，但其本身并不是最终目标。敏捷并不是唯一的方法，组织成功的时间比敏捷的时间要长得多。帮助开发人员和组织把工作做到最好，而不只是做敏捷。
- END -你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！
本文由 mdnice 多平台发布