盲点
敏捷（Agile）和Scrum常常被相提并论。通过实施Scrum，你应该能够在一半的时间内完成两倍的工作。这能促成更快的创新，以及快速响应市场变化的能力——灵活、机动。对于管理团队来说，这是梦寐以求的东西。
管理层指定了一个Scrum试点项目。新成立的Scrum团队满腔热情地开始，并且全力以赴。遗憾的是，他们背负的期望太高了，他们无法达到，结果常常还比以前更糟！试点项目失败了，敏捷遭到了非议。所不为人知的是，通过实施Scrum，你并不会自然而然地变得敏捷。
Scrum不等于敏捷
仅仅在软件开发部门实施Scrum是不够的，这不足以达成真正的敏捷。很多公司忽视了在企业文化、管理风格、流程以及项目执行方法上的必要改变。
Scrum是一种流程，而敏捷是一种观念。
管理扼杀创新
改变一家公司的企业文化从改变管理运作方式开始。自顶而下、命令控制式的管理时常相伴在Scrum的左右。当一件事情失败时，管理层要求一个解释，并且寻找相应的责任人。于是，通过实施很多正式的检查点，流程被设计出来以避免再次犯错。在你被允许做一件事情之前，你必须递交详尽的文档，请相关部门盖章以获得批准。因为不主张员工跨越这些边界，创新和敏捷也就被扼杀了。
凌驾于Scrum之上的项目
伴随着老的企业文化，计划驱动的项目管理也得以保留。只有当管理层被说服他们将会赚钱时，项目才会被批准。在成本预算和既定范围之内按时交付仍然是他们的期望。在一个Scrum组织里，这会导致项目经理不得不与产品所有人（Product Owner）和Scrum Master交涉。范围常常被定义为一种期望的交付物，而不是达到一个业务目标。产品所有人决定如何达到一个业务目标的授权是非常有限的。当最后期限不再可行（比如因为有了新的深入认识），压力便接踵而至。为了赶上最后期限，团队被要求通宵加班，周末也不能休息，最终导致质量方面的问题。
相比于以前的情况，把瀑布模式与Scrum混合在一起更加低效、无用。
只有改掉旧习惯和老的工作方法，敏捷才能达成！
敏捷文化
什么是敏捷的企业文化呢？它以信任为根基。管理层相信，只要让正确的人在一起合作，就不愁找不到最好的解决方案。人们被赋予信任和自由，可以自主探寻思路和解决方法，而不必事先征得许可。即使失败了也没关系。犯错以及从错误中学习是受鼓励的，因为有了试验和失败的铺垫，才会有创新。
为了达到敏捷，做决定的权力和责任应该下放到一个组织里尽可能低的级别，也就是说，要下放到Scrum团队。如果人们被允许去做他们认为是最符合公司利益的事情，他们就会有主人翁精神。管理层只是通过解释清楚战略优先级和（可衡量的）业务目标来掌控大局。Scrum团队深得信赖，他们自己能够想办法实现这些目标。
管理者成了服务型领导，他们只在团队依靠自身的力量无法解决问题时才伸出援手。
向敏捷转变
一个公司不可能仅仅在IT部门实施Scrum就变得敏捷。如果管理层希望Scrum来解决所有的问题，那他们一定会大失所望，除非他们准备好了满足前提条件。向敏捷转变常常是一次大的变革，需要改变的地方有很多。
传统公司与敏捷公司之间的最大差别
规则与政策
敏捷：因为对人的高度信任，规则和政策就没必要了，数量非常有限。只有在关键的业务领域（比如安全和合规性）才会制定一些规则。Airbnb的大部分政策都是基于“直觉判断”是否有风险。
传统：存在很多规则和政策。但凡你想要做些改变，必须先征得中央集权部门（像架构和安全）的同意。即使是小修小补，也必须在获得批准之后才能动工。
译者注：Airbnb是AirBed and Breakfast（“Air-b-n-b”）的缩写，意思是空中食宿。这是一家联系旅游人士和家有空房出租的房主的服务型网站，可以为用户提供各式各样的住宿信息。2015年6月，Airbnb完成15亿美元融资后，公司估值达到了255亿美元。
工作移交
敏捷：团队可以自己把代码部署到生产环境，并且继续负责处理突发事件和故障。拿亚马逊公司CTO的话来说：“你做的东西，你负责让它运行起来。”尽量避免移交给别的部门。
传统：软件会被移交给测试和运维部门。在得到他们的批准之后，会被部署到生产环境。当有突发事件时，运维团队会尝试分析并解决它们。
管理行为
敏捷：“管理者鼓励通过合作来解决问题，而不是直接指出解决方案。管理者帮助解决那些团队依靠自身力量无法解决的障碍。”——这是Spotify关于服务型领导的敏捷宣言。
传统：管理者口述解决方案，告诉大家应该做什么。遇到问题的时候，人们常常不会尝试自己去解决，而是把问题逐级上报给管理层。
译者注：Spotify是全球最大的正版流媒体音乐服务平台之一，2008年10月在瑞典首都斯德哥尔摩正式上线。截止到2015年1月，Spotify已经拥有超过6000万的用户，其中1500万为付费用户。Spotify公布过一份文件，解释了它怎样做到：在快速实现规模化的同时还让企业对外界保持敏捷性。
管理知识
敏捷：工程师的管理者总是掌握着技术技能和知识，因为他们自己通常也是工程师出身的。如果你在Airbnb申请一个管理职位，你首先必须是一位成功干了6个月的程序员。
传统：管理者通常不需要掌握技术知识。也许因为他们管理的是流程吧。结果是：在他们为工程师们做一个决定或尝试解决一个问题时，会制造不必要的噪音和困扰。
角色
敏捷：在多工种团队里，角色是混合的。比如说，Spotify没有雇用专职的测试人员，但他们确实有一些工程师去教会其他团队如何取得和衡量产品的质量。测试成为了一种能力，而不是一个角色。这是从质量保证（Quality Assurance）到质量援助（Quality Assistance）的改变。
传统：人事部门设置了固定的角色，并且为每个角色定义了岗位要求和职业发展路径。如果你是一名测试员、架构师或系统管理员，你就一直做与你的角色匹配的工作。
心态
敏捷：人们都有“我可以做到”的心态。InfoScout是美国旧金山的一家初创公司，在它办公室的显眼位置贴着萧伯纳的一句名言：“一个说不能干的人不应该打断别人去干。”
传统：人们常常抱怨，总是强调问题，而不是去寻求解决方案。当面临挑战的时候，他们寻思的是任务不可能完成的理由。
译者注：萧伯纳（George Bernard Shaw），爱尔兰剧作家，1925年因作品具有理想主义和人道主义而获诺贝尔文学奖，他是英国现代杰出的现实主义戏剧作家，是世界著名的擅长幽默与讽刺的语言大师。
人才
敏捷：只雇用顶尖的人才。除了工程技术，态度、沟通等软技能也是很重要的。新员工是否能适应公司的文化，是否有足够的责任心——这是面试流程中需要重点考察的部分。这确保了敏捷的企业文化，吸引更高水平的人才加入。
传统：如果能力强的人不能持续承担有挑战性的任务，不能从其他能力强的人那里学到东西，他们就会不乐意。很多传统公司的环境很难留住他们。这会导致恶性循环。拿乔布斯的话来说：“一流公司雇用一流的人才；二流公司雇用三流的人才。”
决策
敏捷：决策常常是基于数据做出的。所有一切都用数据来衡量，通过试验不同的做法，最好的解决方案也就显而易见了。
传统：决策常常是基于管理者的意见做出的。在谷歌，他们倡导远离危险的Hi.P.P.O（Highest Paid Person Opinions的缩写，即拿最高工资的人的意见）。
产品开发
敏捷：只有当预定的业务目标达到之后，工作才算完成。在谷歌，他们称之为“发布后迭代”。尽快把你的产品送到客户手中。收集反馈，衡量效果，快速迭代以做出最好的产品。尽可能避免设定了最后期限的大项目！
传统：产品开发是通过执行设置了固定的最后期限和范围的大项目来完成的。工作怎么开展通常是预先定义好的，但在项目启动之后，业务目标就会被遗忘，甚至都无法衡量。当产品的第一个版本正式发布之后，项目组也就解散了。
译者介绍：陆其明，拥有10几年的软件技术研发和管理经验。已经出版的著作有《DirectShow开发指南》、《DirectShow实务精选》、《Windows Media编程导向》、《脚本驱动的应用软件开发方法与实践》，译作有《代码之道》、《高效能程序员的修炼》、《程序员的修炼——从优秀到卓越》。
原文来自：Medium