任何变革都是艰巨的。任何没有把敏捷转型当作一场变革来小心管理的企业，最终都难逃失败或停滞不前、悄无声息地结束的结局。此外，敏捷转型不是一场普通的变革，它有其特殊性，需要组织用敏捷的方式来领导敏捷转型，任何采用传统的计划驱动方式的敏捷转型，最终都不会成功，原因有以下几点。

1.敏捷是没有终点的

很多公司的管理层都表示：“我们公司已经做敏捷好几年了，各方面做得还挺好的，敏捷的各种实践我们多少都有去做，现在没有什么可以做的了，敏捷转型对我们来说算是过去时了。”

敏捷与传统的CMMI[导入和评级方法完全不同，敏捷没有统一的成熟度模型或评价体系。每个开展敏捷转型的组织永远行走在更加敏捷的道路上，如果需要存在一个终点的话，那这个终点的名字就是“持续改善”（Kaizen） 。

2.敏捷属于侵入式变革

敏捷对组织里每个角色的工作方式都有很大的改变，因此属于侵入式变革。

很多开展敏捷转型的企业让团队有了这样的认识：敏捷只是大家围着白板开会，就是比从前多开了Scrum的那几个会。

通常，组织的变化可能有很多种，有的只是改变了流程中的某个环节，例如，服务器环境的审批权限从高层管理者下放到部门主管。这样的变化只是改变了准备服务器环境的等待时间，间接减少了客户的等待时间，但这种改变还不能称之为变革。只有那些使组织的流程、制度、文化发生本质变化的改变，才能称之为变革。

从瀑布开发方式转型为敏捷开发方式，每个工程师需要学会将需求拆分成小粒度的用户故事，即从最后一次性提交代码到每天都提交代码的转变。而且每次提交都要编写自动化测试脚本，如果提交的代码没有通过测试，则需要马上修改代码。对于引入测试驱动开发（TestDrivenDevelopment，简称TDD）的团队来说，他们还需要学会测试先行，并且持续重构已有的设计和代码。这些都与他们之前的工作方式完全不同。

3.敏捷转型具有不可预测性

由于敏捷转型最终是对人以及人与人之间交互方式的改变，这决定了转型过程具有不可预测性。

很多企业做了敏捷转型的长期路线图，规划了未来3~5年内组织的转型路线图。然后，这些企业每年都会设定转型的目标，以及每个月的执行计划，并严格按照这个目标和计划执行。

首先，从来没有一家企业完全按照当初规划的3~5年路线图实施下去。当今世界变化太快，等不到3年的时间，组织的战略方向就已经调整，组织架构也会跟着调整，比如，上次做长期路线图的决策者已经换作他人。

其次，从来没有一家企业完全按照每年设定的敏捷转型目标和计划实施下去。在转型的过程中，总是有与计划不一致的新发现，原来做的计划已不符合实际需求。

尤尔根·阿佩洛（JurgenAppelo）在其著作《管理3.0：培养和提升敏捷领导力》（Management3.0：LeadingAgileDevelopers，DevelopingAgileLeaders）中介绍过，所有的组织实质上都是网络，这个网络由人以及人与人之间的互动与关系构成。尽管人们用组织的层级关系绘制组织结构图，但是这改变不了组织是网络这一事实。这个网络不会完全按照你的计划方式执行，因为它是一个复杂的自适应系统。在你触碰它后，它会有所反应，而通过它的反应，你才知道下一步该怎么做。这决定了敏捷转型不能用传统的计划驱动方式来控制执行。

4.敏捷没有标准的模板，也没有最佳实践。

很多组织喜欢了解其他公司的案例或业界最佳实践，拿回来照着做。

也许你学过一些Scrum或TDD的课程，然后回到公司信心饱满地开干。但很快你就会发现，将课堂上很完美的实践拿到自己团队里应用却会碰到各种问题和困难。这是因为以你团队里现有的组织结构、流程、团队能力和实践习惯，生搬硬套一定不可行。

同行的敏捷实践只具有参考价值，不具有复制价值，因为每个公司都有其自身的特殊性。即便在同一个公司里，不同的部门和不同的团队，它们的情况也会有所不同。团队需要探索适合自己的敏捷，其他团队的敏捷虽具备学习和参考价值，但是不能直接复用。

任何变革都是艰巨的。任何没有把敏捷转型当作一场变革来小心管理的企业，最终都难逃失败或停滞不前、悄无声息地结束的结局。此外，敏捷转型不是一场普通的变革，它有其特殊性，需要组织用敏捷的方式来领导敏捷转型，任何采用传统的计划驱动方式的敏捷转型，最终都不会成功，原因有以下几点。

1.敏捷是没有终点的

很多公司的管理层都表示：“我们公司已经做敏捷好几年了，各方面做得还挺好的，敏捷的各种实践我们多少都有去做，现在没有什么可以做的了，敏捷转型对我们来说算是过去时了。”

敏捷与传统的CMMI[导入和评级方法完全不同，敏捷没有统一的成熟度模型或评价体系。每个开展敏捷转型的组织永远行走在更加敏捷的道路上，如果需要存在一个终点的话，那这个终点的名字就是“持续改善”（Kaizen） 。

2.敏捷属于侵入式变革

敏捷对组织里每个角色的工作方式都有很大的改变，因此属于侵入式变革。

很多开展敏捷转型的企业让团队有了这样的认识：敏捷只是大家围着白板开会，就是比从前多开了Scrum的那几个会。

通常，组织的变化可能有很多种，有的只是改变了流程中的某个环节，例如，服务器环境的审批权限从高层管理者下放到部门主管。这样的变化只是改变了准备服务器环境的等待时间，间接减少了客户的等待时间，但这种改变还不能称之为变革。只有那些使组织的流程、制度、文化发生本质变化的改变，才能称之为变革。

从瀑布开发方式转型为敏捷开发方式，每个工程师需要学会将需求拆分成小粒度的用户故事，即从最后一次性提交代码到每天都提交代码的转变。而且每次提交都要编写自动化测试脚本，如果提交的代码没有通过测试，则需要马上修改代码。对于引入测试驱动开发（TestDrivenDevelopment，简称TDD）的团队来说，他们还需要学会测试先行，并且持续重构已有的设计和代码。这些都与他们之前的工作方式完全不同。

3.敏捷转型具有不可预测性

由于敏捷转型最终是对人以及人与人之间交互方式的改变，这决定了转型过程具有不可预测性。

很多企业做了敏捷转型的长期路线图，规划了未来3~5年内组织的转型路线图。然后，这些企业每年都会设定转型的目标，以及每个月的执行计划，并严格按照这个目标和计划执行。

首先，从来没有一家企业完全按照当初规划的3~5年路线图实施下去。当今世界变化太快，等不到3年的时间，组织的战略方向就已经调整，组织架构也会跟着调整，比如，上次做长期路线图的决策者已经换作他人。

其次，从来没有一家企业完全按照每年设定的敏捷转型目标和计划实施下去。在转型的过程中，总是有与计划不一致的新发现，原来做的计划已不符合实际需求。

尤尔根·阿佩洛（JurgenAppelo）在其著作《管理3.0：培养和提升敏捷领导力》（Management3.0：LeadingAgileDevelopers，DevelopingAgileLeaders）中介绍过，所有的组织实质上都是网络，这个网络由人以及人与人之间的互动与关系构成。尽管人们用组织的层级关系绘制组织结构图，但是这改变不了组织是网络这一事实。这个网络不会完全按照你的计划方式执行，因为它是一个复杂的自适应系统。在你触碰它后，它会有所反应，而通过它的反应，你才知道下一步该怎么做。这决定了敏捷转型不能用传统的计划驱动方式来控制执行。

4.敏捷没有标准的模板，也没有最佳实践。

很多组织喜欢了解其他公司的案例或业界最佳实践，拿回来照着做。

也许你学过一些Scrum或TDD的课程，然后回到公司信心饱满地开干。但很快你就会发现，将课堂上很完美的实践拿到自己团队里应用却会碰到各种问题和困难。这是因为以你团队里现有的组织结构、流程、团队能力和实践习惯，生搬硬套一定不可行。

同行的敏捷实践只具有参考价值，不具有复制价值，因为每个公司都有其自身的特殊性。即便在同一个公司里，不同的部门和不同的团队，它们的情况也会有所不同。团队需要探索适合自己的敏捷，其他团队的敏捷虽具备学习和参考价值，但是不能直接复用。