【IT168 专稿】
原文链接：http://www.scrumalliance.org/articles/123-top-ten-organizational-impediments（撰文/Craig Larman, Bas Vodde；编译/张恂, Sun Yuan）
当我们在撰写新书Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-scale Scrum中“组织”一章的时候，我们请教了一批大型企业的敏捷开发专家，什么是他们组织在敏捷改进、实施过程中遇到的最大障碍。我们将这些专家的回答汇编成了以下清单，取名为敏捷改进/实施的“十大组织障碍”。
10. 排除组织障碍失败
Scrum 方法的联合创始人 Jeff Sutherland 认为，排除组织障碍失败是大型组织面临的一个主要障碍。无法排除组织障碍的最常见原因是“这是我们一直以来的工作方式”以及“我们不会改变的，因为我们为此已经投入了很多” 。
9. 错误的成本节省和整合努力
在施乐公司推广精益原则方面经验丰富的开发经理 Peter Alfvin 与 Reaktor Innovations 公司敏捷教练部主任 Petri Haapio 都指出，因中央集权部门寻求成本节省和整合而导致的局部优化是一大障碍。他们列举了几个这种错误努力的事例。第一个是，一个中央集权的工具部门强制规定公司的所有部门都必须使用同一个工具，尽管这种做法的出发点是好的，是为了节省成本，但由于该“强制性工具”并不适合某类工作，因而至少导致一个开发团体的工作效率降低。第二个例子是，所谓的“家具警察”强制规定所有部门都使用隔断来标准化办公环境，以最小化成本，结果却导致了对于许多团队来说相当低效的工作空间。另一个例子是，公司的 IT 部门限制视频会议以降低网络流量，结果却妨碍了依赖这种沟通方式的团队开展有效工作。
8. 缺少必要的培训
诺基亚西门子网络（NSN）的全球敏捷开发活动协调员 Sami Lilja 发现一些组织倾向于认为学习是一种时间和金钱上的浪费。这类组织通常教育和训练员工，告诉他们只在“时间允许”的情况下才会安排他们进行学习。这种扭曲的观点常常导致糟糕的“救火”循环 —— 由于开发人员技能不足造成错误，进而导致匆匆忙忙的紧急修补，而管理团队又不愿花时间分析造成这些错误的原因，结果就导致了更多的错误。
7. 单一职能团体
爱立信上海的专家 Larry Cai 提出职能化组织（单一职能团体）是敏捷实施的一大障碍。单一职能团体容易阻碍沟通，造成部门间的互相指责。
6. 局部优化与全局优化
咨询顾问、教练、推广专家（expert facilitator）以及两本关于组织学习图书的作者 Esther Derby 认为，那些提倡局部优化而非全局优化的系统是成功的一个主要障碍。这类系统的例子包括目标管理（MBO）和预算系统等等。
5. 认为仅靠读书就够了
西门子医疗系统公司的前敏捷教练 Mike Bria 认为“DIY 式内部改进”是一个常见障碍。他说，许多人往往在读过一两本书之后，就盲目地相信自己“已经知道该怎么做了”，而事实证明一知半解往往是危险的。这类组织通常不愿意寻求外部专家的帮助，常常喜欢闭门造车。《测试驱动》的作者 Lasse Koskela 也提到一个类似的障碍，用他的话说 —— “不知道眼睛向外看”。
4. 个人绩效评估和奖励
某大型电子商务网站的培训师（因其要求略去了他的名字），提出个人绩效评估和奖励是他所发现的一个主要障碍。这种古老的做法会挫伤敏捷团队中的开发人员和管理者，阻碍团队整体绩效的提升，并强化命令控制式（command-and-control）的管理。
3. 不切实际的许诺
诺基亚西门子网络（NSN）杭州研发中心的敏捷培训师、一个大型研发团队的部门经理吕毅指出，“承诺竞赛”和不切实际的许诺是最大的组织障碍之一。不切实际的期望往往会导致抄捷径、持续救火、遗留代码等问题。在本书姊妹篇Practices for Scaling Lean & Agile Development 的 “遗留代码”一章中我们将对此做更深入的探讨。
2. 认为敏捷只与开发人员有关
敏捷推广专家 Diana Larsen 与《敏捷回顾》（Agile Retrospectives）的作者 Esther Derby 都提到了一个障碍，即“认为敏捷只与开发人员有关”。许多组织经常错误地认为敏捷和精益只牵涉到开发人员，而不理解成功的敏捷转变其实需要一个组织内的各个层次上，人们思维和行为方式的转变。
1. 银弹思维与表面实施
我们采访过的所有人几乎都提到了某种形式的“银弹思维与表面实施”是一大障碍。OTI 的创始人、大规模精益产品开发顾问、ObjectMentor 公司总经理 Dave Thomas 对这一问题和现象作了精彩的分析。他说，许多公司错误地将敏捷等同于高生产率（productivity），而非适应性（adaptability）。这一误解，加上受过有效培训的高层管理人员的缺乏，导致了认为“敏捷就是某种形式的银弹”的误解。而这又进一步地促使某些人相信，任何有意义的实质问题只要通过说一句“我们正在做敏捷”，并据此采取一系列所谓的行动就能获得解决，而不需要一个组织的领导团队作出深刻理解和相应的改变。具有讽刺性的是，由于这种做法既不会导致任何真正的改变，也不会获得任何真正的效果，最终这些组织将会放弃精益/敏捷原则，因为“它们不起作用”。
与此有关的另一个障碍是，一些人想当然地以为大型产品研发团体的敏捷改进不需要几年的时间，就能迅速获得显著的效果。而事实上，大型组织的显著改进往往可能需要花上 5 到 10 年的时间（在高层管理者的持续支持下）。
我们的两点补充
在发布了这份十大清单之后，我们决定再添加两个我们认为重要的组织障碍。第一个障碍是，一种突出员工个人而非真正的团队及团队合作的组织文化。有太多这样的团体，他们实际上由许多分离的、缺少凝聚力的个体组成，却伪装成一个团队，表面上实施了 Scrum，心里想的却是" Jill 做 Jill 的工作，Raj 做 Raj 的工作，等等"。这些组织中的开发团体无法以一个整体团队集体行动，开展彼此的结对工作和相互学习。
第二个障碍是，管理者与一线员工之间的隔阂。常见的情况是，管理层做出的改变对实际的一线工作没有产生任何影响（或至少没有正面的影响）；同样，一线开发人员所做出的决定，也往往不符合组织的方向。形成这种隔阂常常是因为，管理者没有到实际工作的一线环境中去"实地查看"（go and see） —— 有时候是因为他们已经丧失了这么做的技能 —— 而开发人员又不关心属于自己岗位正常职责之外的事情 —— 他们在自己的岗位上已经“退休”了。这种隔阂会导致浅表的敏捷和精益实施，结果是只在管理层面上发生了变化，而技术实践没有任何改变，或者只在开发层面上发生了变化，而组织本身没有任何改变。精益做法"实地查看"和"担当教练的管理者"（managers-as-teachers）可以帮助缩小这种隔阂。
以上来自诸多敏捷开发专家的回答，证实了我们已掌握的经验，表明我们所研究的话题是恰当的。本书“组织”一章中余下的部分将进一步探讨这些组织障碍及其应对措施。
