在一次行业聚会上，又一次遇到了李剑,和他开玩笑：
……
我：你翻译的这本书（《硝烟弥漫中的Scrum和XP 》）害了好多人。
李剑：呵呵， 我知道，我道歉。@# ￥ # ￥ %… ，很多人把这个当成了敏捷…
我：哈哈… ，关键它太流行了。你现在成敏捷的罪人了，你竟然一下子送给了我们公司 5本。
李剑： @#￥ # ￥ % ……
内部培训或者跟初学者交流的时候，我都会推荐大家读一读这本书，因为这本书写的很不错，翻译的也很好。但每次推荐之后，我心里都有一丝不安，不安的原因就是上面提到的：我很怕大家把这些具体实践，尤其是别人的实践，照搬过来当成了敏捷。
很多的实践，在别的公司用的很好，效果显著。拿过来使用后却感觉怪怪的，根本达不到预想的目标。为什么？
如果你曾经使用过Scrum 方式开发软件，管理项目，想想下面的场景，看看您除了采纳相关的具体实践外，是否仔细想过这些实践后面的原则和价值观？
1） 原来你都是自己或者专家拆分需求，之后直接将相关任务分配给了Developer 。现在你是团队一起拆分需求，你为何这样做？这样做有何好处？而不仅仅因为是“Scrum 要求”？
2） 你的团队需要Daily meeting ，为什么要这样？ 思考一下它的真实意义在哪里？而不是仅仅机械的回答3 个问题。你是否说过类似的话：“你不要说了，等你考虑好了再告诉我吧”。“我给你记下来了，这是你的责任”。
3） 同样都是回顾会议上，为什么你主持的回顾会议，大家集体缄默，不愿意说出自己的真实想法? 如果有人曾经说出过自己的想法，你是否积极帮助分析并解决了问题？为什么要回顾？他对你的团队有什么意义吗？还是该死的Scrum 要求你这样做？
4） 为什么要做Demo 给客户？他不参加的情况下你又如何？直接放弃 Demo 实践，还是有其他的行动做补充？刚刚发布了一个版本，客户却要求你打一个补丁版本，客户为什么对当前版本不满意？是否能够避免类似情景？
……
他山之石，不可攻玉。如果我们只会照搬别人的所谓的“最佳实践”，而忽略其背后的原则和价值观的话。
就像你去看濮存昕主演的话剧《雷雨》，你会看到他的走位，听到他的对白，但却不知道排演的时候的情景，导演又是如何要求演员，他们如何准备自己的角色，编剧如何修改剧本，或者今晚濮存昕的表演和昨天或者明天又有什么不同。
一样的道理，你打算改进公司的开发过程，你去参加研讨会，只能看到他们使用的工具和技术，却看不到他们背后的整个运营系统；你去Thoughtworks 参观，也只能看到那些卡片墙，开放的办公空间，舒适的座椅，却看不到隐藏其后的敏捷原则和相关管理及文化。
所以，对于使用Scrum 方式进行开发管理的团队，在日常的工作实践中，一定要注意仔细的体会实践背后的原则和价值观。只有你对事情的理解就位了，你才能更好的更有效的使用它。敏捷在企业内部的实施，绝对不是静态的，而是动态的。绝对不是机械的照搬模仿，而是在学习的基础上不断补充，形成自己的实践。
对组织一级来说，忽略这个问题更严重。
在企业内部实施敏捷改进的经验和跟同行的交流中我发现：
1、 很多的企业认为敏捷就是Scrum ，或者 XP 。
2、 很多的企业只是采用的Scrum 或者 XP 中的一部分，甚至只是有个开头，很快就放弃了使用。
3、 许多人依然使用旧有思维去诠释敏捷。
4、 许多企业的自身领导并未参与到日常的持续改进中。
既然大家都认为敏捷功效非凡，Scrum 等方式又是如此简单，那为什么只有少数几个企业才能才能称的上是“敏捷”的企业？不是都说“他山之石，可以攻玉”吗？看看别人怎么做，我们照做不就好了吗？
还是前面说的那个道理。敏捷也好，CMMI 也罢，它们都是一种有效的工具，仅此而已。组织应该了解的是，它们只是某一个层面的方法而已，而其背后，却需要有相关的企业文化和运营系统来支撑。
任何企业都是独一无二的，都有其相关历史和自身环境，企业在设计自己的敏捷模式的时候，也需要考虑自己的需求，资产、目标等。参观学习标杆企业，复制其他企业的模式，遵循相关样板或者指南，不可行也不理想。适宜的策略是，企业需要在敏捷相关原则的指导下，在符合企业文化的前提下，采用小步走的循序渐进的方式，逐步改进。
在我看来，要想使自己的企业真正的“敏捷”，而不仅仅限于表面上采纳“他山之石”，需要付出的艰苦努力远超想象。成功的敏捷企业，需要有敏捷的DNA ，这需要相关的文化土壤，敏捷才能生根发芽，而不是胎死腹中。敏捷型企业涉及到更深入、更普遍的思维转变，文化转型，大多数公司根本没有意识到这一点。
为了保证敏捷的有效实施，需要持续的关注以下几点：
1、 公司高层作为推动者，这是敏捷改进实施的先决条件。
敏捷的改进涉及到方方面面，离开了企业高层的支持，任何的改进都不可能成功。而且，工作方式，管理思维等的变化，也需要高层的投入和认可，这一点至关重要。 另外，工作模式的转变，涉及到企业的很多部门，也需要获得高层的支持和认可。只有你拿到了令牌，你才能有效的开展工作。如果相关高层不懂敏捷，那就先让相关领导意识到问题的存在，让他们理解敏捷，进而支持敏捷。
2、 由下而上的参与。
一线的员工来自于开发现场，他们往往能最先感知到危险或者问题的存在。多听取大家的意见，及时解决大家关切的问题，并从整个组织的角度考虑问题，同时，吸引他们参与到过程改进中来，也是非常关键的一点。
对管理者而言，与其等待着自上而下的发酵，自上而下的渗透到整个组织的各个层级，然后再等着看产生的实际利益，还不如从工作现场着手开始改善。
3、 中层经理作为变革的中坚力量
经常听到类似的声音：“我们经理根本不关心这件事…”, “我不关心你用什么方法，我关心的是，你下个月…”
中层的管理者应该成为敏捷实施的中坚力量，没有他们的理解与坚持，我们建立的任何机制都会土崩瓦解，任何优秀的方式方法都不可能成功。所以，让经理们理解敏捷，支持敏捷，实施敏捷是整个改进过程中应该重点关注的一个关键环节。
4、 长期的，持续的关注和投入
公司的高层也需要以长远的眼光看问题，避免杀鸡取卵的短期行为，遵守最初对持续改进的承诺，并持续性的投入和关注。
必要的时候，可以采取自上而下，强制实施的有效手段，才能使得企业获得更多的成效，才能使得企业走上一条不断优化，不断学习的敏捷之路。
其他的方面，比如价值观的转变，企业文化的转变等等，在这里不再讨论。
关于作者
李忠利
毕业于东北大学，软件行业从业十年，现任某美国财富500强企业Scrum培训师及教练, 有六年多敏捷实践经验，是中国早期的敏捷实践者及推动者之一。从2006年至今在某大型跨国企业担任Scrum培训师及教练，是企业内部认证Scrum培训师，在该企业从事敏捷的应用和推广工作，负责制定企业敏捷转型路线图、带领团队研发企业内部Scrum工具等，并在企业内部开展ScrumMaster培训及认证，对企业Scrum实施起到了极大的推动作用。在此之前，李忠利曾在该企业负责项目管理工作4年，从事离岸项目研发管理工作。李忠利在ERP系统研发方面也有丰富的经验，曾在北京用友软件工作3年，从事用友高端ERP-NC研发工作。
