Scrum很好。如果对于敏捷开发的好处存在异议，不建议继续阅读，否则会加深对敏捷开发的误解。
究竟是什么让Scrum转型变得困难呢？
第一，成功的变革不是完全的自上而下或者完全的自下而上（敏捷的提出者和支持者错误）。
完全自上而下的变更过程，容易出现上有政策下有对策的内耗。完全的自下而上，容易出现关键时刻高层不支持导致全面失败的情况。最好的引入变革的方式是自上而下的，同时需要各个执行层给予支持。成功的关键就是自上而下和自下而上相结合。
说到底，还是全员是否有一致的目标。共同的目标会自然的消除层级之间的不信任感，建立在信任基础上的组织更容易实施变更。
第二，结束状态是未知的（唯结果论错误）。
做一件事，是否做完？是否做好？这样的评价过程，任何人都有了自己的思维习惯。然而，Scrum是一个持续改进的过程。在实施Scrum过程中，无法知道最终的情况会是如何，也不知道应该如何具体的走第一步，第二步，第三步，唯一能感觉的是效率在慢慢提升。现实中，人们在Scrum还没有形成价值时，就给出了否定评价。
作为团队，特别是Scrum主管，必须拿出表明团队有提升的过程证明，在他人质疑之前，进行展示。
第三，Scrum无处不在（独立Scrum团队会受到非Scrum团队的干扰）。
其实，把Scrum和敏捷开发放在一起是错误的说法。Scrum是一种敏捷的框架，不仅仅适用于开发过程中。如同开发本身就需要其他部门的配合一样，实施敏捷开发也会影响到相关的部门。由于仅仅是开发团队实施Scrum，就会导致部门配合存在问题。例如，开发团队每两周进行一次冲刺，在冲刺计划确定后，本来不应该添加其他的需求或者非冲刺计划中的工作，由于其他部门的要求，加入新的工作项，破坏了冲刺过程，导致次次冲刺失败，最终导致Scrum失败。
使用慢起步进行冲刺。预留足够的时间进行非冲刺目标的工作。但是一定要表明给合作部门，由于预留了很多时间留给未知事件，导致进度缓慢。慢慢的让配合部门懂得Scrum的节奏，让他们实现自我调整。如果无法实现自我调整，团队主管需要寻求更高领导层的裁决。
第四，Scrum是截然不同的（转型Scrum必须度过一个低效率的适应期）。
所谓的截然不同指的是采用Scrum后，资深人员会感觉到和过去工作在做法上有很大差异。这种差异，在刚开始时表现为团队低效率。
测试人员不仅仅是最后测试阶段按照需求说明书来测试，而是在开发过程中，就深知用户需求并进行测试。
配对编程，让同构甚至异构技术栈的人共同工作，两人使用一套生产工具。
测试驱动开发，原来一步到位的代码编写，要被拆分到多次完成，甚至一开始故意要写错代码（测试驱动开发的核心思想：每次编码应刚刚只够满足单元测试用例）。
工作会有更多的标准化，使用Scrum事件（站会，冲刺目标会议，冲刺评审会议，冲刺回顾会议）。
第五，变化来的太快（Scrum引入了更多的变化）。
任何的改变都会对现在产生冲击。实施Scrum，会把隐形改变变成显性改变。例如，出现了新的编程技术，在以往的情况，都是项目组成员产生恐慌（更不上技术更新），架构技术组进行学习和相对慢的技术升级实践（只是可以快速掌握，但是也可以完全不用），最终等新技术变成老技术时，项目组成员依旧恐慌。这样的迭代多了之后，项目组成员麻木了，变得似乎不害怕技术更新，没有了危机感。但是Scrum不一样，它是一个框架，敏捷团队是一个自团队，完全可以为自己的决定买单，由于拥抱变化，会给团队带来许多不稳定的因素。不得不承认，有些公司是惧怕变化的。
所有项目组都应该实施敏捷。如果技术部门能很快的将学习知识进行沉淀，对项目组进行提高，最终是会给公司带来价值。
第六，最佳实践是危险的（没有直接可复制的方法，只有可以复制的思想）。
敏捷是一个持续改进的过程，也是因材施教的典型。因此，没有绝对正确的做法可以借鉴。铺开敏捷时，应该教导思想，而不能仅仅是方法。