《2020年敏捷状态报告》中显示，现今许多组织还在学习如何实施敏捷。受访者中也有大约50%的人表示，他们的团队中只有不到一半的人在使用敏捷，而其中仍有高达84%的人承认他们的组织没有达到高水平的能力。
一部分公司或团队在践行敏捷后取得了巨大的成功，让更多的人趋之若鹜，纷纷转型敏捷。但转型敏捷绝非易事，在这一过程中，最常见的问题就是团队并未真正理解敏捷原则及核心价值观，而是一味地照猫画虎。自然，照猫画虎最终还是失败了，这时候经过这一系列变动的团队或成员就开始大肆宣扬“敏捷无用论”：搞那么多虚头巴脑的招式，只会浪费更多的人力物力财力，增加时间成本，到头来没有什么实质性的用处。但是，真的是敏捷无用吗？还是你用错了敏捷？
敏捷宣言的主要内容是：
- 个体和互动高于流程和工具；
- 工作的软件高于详尽的文档；
- 客户合作高于合同谈判；
- 响应变化高于遵循计划。
但在很多公司中，团队打着“敏捷”的旗号，实际行动却严重偏离敏捷宣言及价值观，最后往往“欲速则不达”。敏捷宣言合著者Robert C. Martin接受采访说，任何工具或者流程如果让人们在自己的工作环境中感到举步维艰，那它就不能被称为敏捷。因此，这些仅披着一层“敏捷”外壳的团队，只能称之为“伪敏捷”。
当团队或者公司踏入“伪敏捷”的怪圈时，如何发现这一问题，就是我们要去解决的问题了。
什么是伪敏捷？
1.极端的敏捷
1）“敏捷”并不是一味的“快”
谈到敏捷，作为一种轻量级方法，很多人误认为敏捷就是“快”：快速反应、快速交付。因此整个团队只顾追求速度，认为“时间紧任务重”，以致于为了追求速度而不得不放弃质量。这种以快速交付为重心的产品无法满足客户的需求，甚至无法通过测试的质量鉴定。
2）“敏捷”并不是一味的“简洁”
敏捷十二原则中第10条为“以简洁为本，极力减少不必要工作量的艺术”。有的人就会说了，既然要提倡简洁，那么就把不必要的流程简化吧：每日站会太浪费时间了，减掉；回顾会议毫无意义，减掉；准备文档太复杂了，减掉；敏捷提倡响应变化，所以不需要计划会议了，减掉……绝对主义者往往会觉得既然要简化就简化的彻底一些，就要进行大刀阔斧的改革。然而在一通乱裁之后，真正有价值的东西被“淘汰”了，留下一群摸不着头脑的程序员在重复繁琐的任务中继续敲代码。
2.僵化的敏捷
1）站立会议
每日站会是敏捷团队进行工作互通的桥梁。每日站会不需要团队成员对自己的工作内容作出详尽而清晰的报告，只需要用两分钟的时间进行一个简单的陈述，总时长一般在15分钟左右。这里的15分钟只是一个大概的时间，具体时间会根据每个团队的成员数量以及工作性质而变。在敏捷的实践过程中，一些团队将站立会议的概念混淆，只是死板地遵循15分钟会议时间的规定，不论团队成员数量多少，要求必须在15分钟内结束。
一旦会议时间被刻板化，这会给团队成员增加很大压力，促使他们不得已找些零零碎碎的任务来敷衍会议，因此也就无法达到每日站会促进团队内部交流的目的。
2）看板
敏捷团队中通常应用看板帮助团队实现任务可视化、工作状态透明化，激励团队成员工作、提高工作专注力及效率。但是在设置看板后，也会一个很大的缺陷：看板处于半闲置状态，无法得到及时更新，团队成员无法从看板中获取响应的信息。这样的结果就是：看板成为了一个代表敏捷的摆设。负责人在汇报工作的时候，一指墙上的看板：看，我们团队在转型敏捷。但实际上，敏捷的观念有没有深入贯彻，除了团队内部成员，其他谁也不知道。
3.传统型领导的敏捷
之前写过一篇关于规模化敏捷变革的文章，文中强调了在团队转型规模化敏捷之前，首先需要领导者转型敏捷。同样，在传统团队转型敏捷的过程中，也需要领导者率先转型敏捷，具备精益敏捷思维。只有精益敏捷的领导者才能通过挖掘、利用团队和个人的长处推动团队的敏捷化。
我曾了解过这样一家公司，领导者思维延续着传统的瀑布式开发模式。当整个团队开始转型敏捷的时候，领导仍在提倡开发流程的前后延续关系，导致团队在实施敏捷开发的小周期迭代时遇到很大的阻力，整个团队呈现出一种“高不成低不就”的状态。如果公司内部都没有达成统一的敏捷转型态度，这时的敏捷团队就会举步维艰。
因此，要想打破敏捷转型效果不佳的“诅咒”，就要勇于冲破团队现行模式的桎梏，识破团队中的“伪敏捷”现象，根据团队的实际情况适当改变策略，真正做到让敏捷“活”起来。
