最近和一个同事聊起某业务部门的敏捷实践，很惊讶的是该部门在10多年前就已经开始敏捷转型了，然而现在居然感觉不到任何敏捷的存在。
最近正好读完Gartner的同名文章，结合自己的经验和思考，来说说为什么有那么多名存实亡的敏捷，已经可以做哪些努力来避免重蹈覆辙。同时也欢迎诸君发表自己的看法。

业界敏捷现状

• 无论出于什么原因或目的，许多组织都在尝试第二、三次敏捷转型；
• 可能有50% - 75%敏捷转型失败或没有达到预期效果
• 有外部专家参与的敏捷转型，在外部专家撤离后，敏捷转型的成果几乎难以持续
• 敏捷转型时，大部分企业只是简单的将敏捷框架叠加到现有的流程和组织。此举往往增加复杂度和工作量，导致转型失败
• 大多数敏捷转型中，开发者只是被动的接受，而没有机会了解转型完整的背景
• 实施转型是，决策层往往会认为敏捷只与开发有关

成熟敏捷观点

成功的敏捷转型需要组织各层级共同参与、努力。不仅包括开发者团队，也包括管理团队、企业高层，通常需要自上而下的进行思维、文化、组织上的转变，而不是简单照搬官方的敏捷指导或业界实践。在转型过程中，需通过工具和实践进行初步的实施，然后通过学习、反馈和创新进一步完善转型实践，以确保转型的可持续，最终满足多样化和不断变化的业务需求。

根据大量敏捷转型失败的案例，业界总结了导致敏捷失败的十二种错误行为。通过深入了解、思考这些行为产生的原因，为当前计划或正在进行的敏捷转型提供参考，以确保转型能够成功实施。

行为1：汉堡式敏捷

汉堡式敏捷属于典型的部分敏捷，将敏捷实践夹杂到当前重型的瀑布流程中。在传统V模型中，每一个阶段都需要1-2个月，甚至更多，而仅在其中编码阶段引入迭代式交付。

具体表现为：

• 仍按传统思维，需要对需求尽量的收集完整、彻底的分析和设计，确保每个环节没有问题，并且每个环节都需要层层审批，以此来确保“降低风险，成功交付”
• 汉堡式敏捷不一定是“敏捷开发”，其他环节都可能单独“敏捷”，如敏捷测试、敏捷构建；但敏捷阶段前后皆是重型的阶段。
• 每个阶段仍是等待前一阶段一次性大量的输入，并一次性大量输出给下一阶段。

思考：

• 此种行为可能是最常见的行为之一。公司高层往往认为交付仅是开发者的事，或某一环节的事。此时，虽然实施了敏捷，但结果没有任何不同；
• Scrum Master和PO被限制在某一环节，无法为整体质量负责。
• 一次性大批量交付无疑会导致问题的集中爆发，从而导致下游甚至全阶段都手忙脚乱，难以应对。
• 层层审批并不能提高交付质量，降低风险
• 重型分析、设计结果虽有参考，但仍是以“假设”为前提，而不是以“事实”为依据

预防或纠正措施：

• Scrum Master和PO有理由去向公司高层普及必要的敏捷思想和基础，必要时引入外部专家————通常外来和尚好念经。
• 由高层驱动各个环节的整体转变会容易的多，但Scrum Master和PO首先需对敏捷有深刻的理解，再次需确保高层能理解到位。
• 树立PO是产品交付的核心总指挥、Scrum Master是军师和指导员的地位；
• 将大V改为小V，将瀑布嵌入到敏捷迭代，而不是敏捷嵌入到瀑布阶段；
• 通过观念转变、数据洞察、技术分析或流程改进手段减少审批环节

行为2：有名无实

有名无实的敏捷实践仅在交付团队中套用了敏捷流程框架，而没有进行思维、文化上所需的转变，仍以过程为中心，而非交付价值为中心。

具体表现为：

• 虽然按照敏捷框架进行组织变革，但各团队仍以孤岛形式存在。在团队与团队之间传递信息仍以文件、邮件、会议为主。
• 虽然也有迭代计划，但按迭代发布几乎没有，仍是原来一月甚至几个月一个版本。
• PO或Scrum Master对其角色定位模式，没有承担相应的职责
• 身兼多职情况比比皆是，无法完全专注于业务交付

思考：

• 敏捷法则要求打破信息孤岛，要求团队是一个全功能团队，所有成员需共同工作
• PO或Scrum Master是敏捷团队运作成功的核心，如果对角色职责不清晰，就无法保证工作顺利开展
• 按迭代交付版本其价值不仅仅是快速交付给客户，更重要是的说明团队对产品理解到位、对需求拆分到位、架构和设计合理；
• 专注是高效工作的前提之一
• 自认为没问题，那么请和过往进行比较，如果没有变化，或变化不大，那么肯定走错了路

预防或纠正措施：

• 团队所有角色需重复学习敏捷思想、宣言和机制管，而不是停留在字面和照搬，尤其是掌舵了Scrum Master，必要时可解决外部力量，如顾问、敏捷教练；
• 全功能团队中角色虽有侧重，但需要全员参与，因此不仅组织上需要是一个团队，物理位置、沟通渠道、信息分享同样是一个团队；
• 坚持没迭代一个交付，即便开始无法达成，也要不断的学习，纠正。实际上敏捷无止境，持续学习和改进才是敏捷核心
• 和其他团队交流敏捷实施心得。

行为3：脆弱敏捷

组织通过强大且冗余的组织架构、复杂的多级流程、完备的风险规避措施来确保业务上的成功；甚至在实施敏捷时依旧试图通过各种框架和规则来确保敏捷的成果。这种内在的冲突不仅不利于敏捷的转变，反而会让敏捷僵化，会产生一个僵化的，无法适应不断变化业务的脆弱研发模式。

具体表现为：

• 在企业内部把敏捷过程标准化为通用的企业标准，明确角色和上下文分工。每个环节做好本职工作，不用也无需问为什么，也不能越界。
• 由上层定义每个阶段的完成或就绪标准，而不是根据业务特点。交付团队只能被动接收，而无法改变。
• 横向组织负责所有决策，并提供统一的配置；交付团队不能个性化配置；
• 对交付进行回顾总结时往往采用“如何规避”的方法，而不是“从根本上”解决；
• 交付服从指令进度，技术服从业务，优化服从功能开发，技术债务高筑

思考：

• 当各种流程和框架叠加与敏捷时，交付团队的交付过程将束手束脚，无法敏捷
• 流程和规则应该是团队敏捷的有力帮手，而不是重重障碍
• 符合各种规章制度、规范与灵活满足业务个性化并不矛盾，可以同时满足
• 长远利益需与近期利益达成一致，而不是退让

预防或纠正措施：

• 通过知识传递和技术分享，与高层达成一致，建立信任，并赋予交付团队更多自主权；
• 通过先进技术的引入来弱化各种流程和强管控，提供个性化能力，给予交付团队更多的自由度；
• 利用业界共识以及试点，获取高层支持，达成长远利益与近期利益双赢

系列文章

• 敏捷的十二种死法(一)
• 敏捷的十二种死法(二)
• 敏捷的十二种死法(三)
• 敏捷的十二种死法(四)