敏捷（Agile）是2001年由17位资深软件领域专家们一起发起的针对软件开发工作价值观的倡议。
作为一种软件开发理念，与之伴随出现了很多实践框架和方法，如Scrum、Kanban和XP。
而这些方法目前已经逐步成为了我们软件开发的事实标准，
类似持续集成（Continuous Integration）这样10年前，
被大家认为是“极限”的方法，现在也已经成了开发团队的一个标配。
值得一提的是很多开发组织里敏捷的大规模应用仍然是一个非常有挑战性的任务。
软件自身的多样性和这个行业的高速发展，造成了敏捷方法落地的种种挑战。
在过去10年时间里，我自己在这方面的咨询辅导工作或多或少跟适配团队和实践有关。
相信在下一个10年，我们还需要持续去解决敏捷开发落地的问题。
市场的需求当然也催生出了一些所谓“规模化敏捷”框架，如SAFe和LeSS。
很多需要解决敏捷大规模应用的组织，于是感觉有了框架和标准。
也有很多企业，询问我支持什么样的规模化敏捷框架。
希望通过本文总结一下这两年来我持续表达的观点：规模化敏捷是一个伪命题！
所谓伪命题就是不要为一个不存在的问题，去寻找一把看似精美的战斧——敏捷这把锤子，
遇到组织级灭霸，可能不好使了。
敏捷正走向生命周期的尽头
说这句话的时候我自己也带着一些伤感， 这里并非是想哗众取宠地呐喊一句 “敏捷已死”。
敏捷作为一种开发理念，已经成为了现代软件开发的基础。
然而，软件开发作为接下来这个数字化时代的基建行业，仍然有很多超越当年敏捷所谈及的事务。
从时下爆款的区块链，我们就可以看到完全不一样的“开发团队”
形象代言人和挖矿小分队，都成为了这个开发团队里必不可少的成员。
什么标志着敏捷走向了生命周期的尽头？为什么不是持续演进成为敏捷2.0呢？
咨询行业对理念和方法的生命周期是有着最快感知和反馈的。
一旦一个理念和方法成为了事实标准，那么咨询公司需要做的事情就是体系化总结，
通过标准化来帮助目标企业更快落地。
一个我们都知道的案例，就是华为在IBM的帮助下，在上个世纪成功规模化应用了IPD。
但即使有了华为这样的成功案例，IPD在后续中国企业落地时也是普遍失败的，
原因是下一代的方法显然已经显现出了更大的优势。
IPD有着完整的流程、方法和实践定义，当年的敏捷相比之下是混乱之极的，
但仍然不可阻挡一波拥抱敏捷精神的互联网企业快速崛起。
当下的敏捷是何其相似！各大咨询公司蜂拥而至，
都开始了“敏捷咨询”，资深的敏捷专家们开始总结大而全的框架，
生怕遗漏了任何一个时髦概念——“价值流”大家都谈就加一个，“DevOps”火就先放里面。
当你艳羡框架的完整时，往往需要警惕这个框架的时代价值，别忘了你做敏捷的初衷是什么？
在这个问题上，我在ThoughtWorks曾经纠结了好多年，
每次有“写框架、卖咨询”的冲动时，
都先后被老马和Jim Highsmith这样的敏捷宣言签署者给拍了回来。
确实也要感谢他们，能够站在行业发展的角度Let Agile Go。
早在10年前，华为给我的命题是：用敏捷开发改造IPD。
记得我们最后“成功”把大家痛恨的“软需”改造成了用户故事（User Story），
并构建起来了一条嵌入式系统的持续集成流水线。
虽然现在看来，那是多么简单的任务，但当时大家还是激动地出了一本“葵花宝典”，记录了整个改造过程。
听到这个名字大家可能都会笑而不语，XXX之后的IPD还是IPD吗？
同样的事情可能马上就会发生。
有一天，中国的BATJ们可能会说：用XXX改造敏捷。
我相信这个XXX不会是敏捷2.0，而我不希望成为那个在汇报中必须听到“敏捷改造成功”的管理者
（即使团队写了另外一本“葵花宝典”）。