2. 以为敏捷只是开发人员的事

    专业导师Diana Larsen和《敏捷回顾》一书的著者Esther Derby认为这是一个很大的障碍。通常，企业会错误地认为敏捷只是开发人员才需要学习的东西。他们不明白要向敏捷转型需要企业各层都在观念和行为上做出改变。

    1. 功能较多药和表面现象

    几乎每个人都认为功能较多药和表面现象是企业的主要障碍。OTI创立人Dave Thomas对此侃侃而谈。他说，许多公司错以为敏捷赞同于生产效率，而没有认识到其适应性。再加上一些没有经验的领导人，往往会导致敏捷就是一剂功能较多药这一错误想法的产生。于是，许多人觉得只要说说"我们在做敏捷"再做做表面工作，就可以解决掉一些很重要的问题，而领导团队也不会采取一些深层的、有意义的措施。更讽刺的是，因为这些行为无法产生有意义的改变和实际结果，因此这些企业最终会放弃精益或敏捷，因为他们觉得"一点作用也没有"。

    与此相关的一种错误想法是，在很短的时间内，比如仅仅几年的时间就可以使大型生产部门得到显著的提升。而实际上，大型企业的显著提升通常需要五年甚至十年的时间--这还是在领导团队的持续支持的前提下。

    在这份列表之前，Larman和他的团队也有他们自己对企业障碍的认识。他们认为，第一个障碍是个人代替团队及团队合作。许多个人组成的小组伪装成团队的样子并且表面上在做Scrum，但是他们心里想的却是"Jill做了自己的那份工作，Raj没有越职"，诸如此类。这些企业需要以团队的方式行动，结对工作，共同学习。

    第二个障碍是管理人员与前线工作人员之间的鸿沟。最常见的是，管理层做出的决定对实际工作没有产生任何影响（或者说，至少没有积极影响）。与此相似，前线人员做出的决定却与企业的方针无法吻合。这个鸿沟是由于管理人员没有对工作环境进行"实地考察"造成的（可能他们已经丧失了这种觉悟），而工作人员又不能积极地考虑"本份工作"之外的事。这就导致了表面敏捷和精益的产生：仅仅是管理层发生了变化而技术实践上没有任何改变；或者只在开发层次上发生变化，企业中却没有任何改变。"实地考察"和"管理者即指导者"的精益实践可以解决这种问题。

    从敏捷开发专家得来的反馈证明了Larmen他们想法和经验是正确的。

    这份十大管理障碍的列表也引来网友和专家的热评，Luis Xavier Baena表示赞成：“最大的障碍绝对是‘功能较多药与表面现象’，他们会说‘对，做吧，但是不要打扰我’。而且这个问题很难解决，因为你必须勇于面对那些给你发薪水的人，而这些人的看法实际上毫无价值。所以很不幸，我目前还不知道有没有较好的方式让那些靠自己的劳动过活的人能够敢于向CEO提出问题而不用担心自己的工资单。现实是，很少有Scrum实践者那么勇敢，不担心自己的薪水。只要管理层一天不给出实际的支持，那么你就无法控制这种情况，它只会像一种潮流一样慢慢淡去。而如果刚开始的时候即是这种状态，那么利益相关人及团队就必然无法避免以上这些障碍。”

    Vetrivel Shanmugasundaram留言道：“我曾经见过软件供应商在接受敏捷摆脱传统的软件开发模式的过程中遇到文中提到的障碍。大部分情况下，软件开发团队会在接受敏捷方法的同时继续使用他们传统的过程。这样团队就会在每日站立会议之后再举行一个状态会议、在跟踪待办事项的同时还要列一个详细的计划、短期回顾后还要进行过程审核。这会极大地影响团队的士气，因为他们会觉得敏捷给他们带来的只有负担。”

    Juan Banda则认为：“在我看来，第2条可以扩展为‘认为敏捷只是开发人员和质量工程师的事’，或者更广泛地说成‘敏捷只是技术层面的事’。我之所以列举出质量工程师来是因为我曾经在一些企业中看到，虽然开发人员相信并且在实际中应用了Scrum方法，但是质量工程师却坚持使用旧的规则。此外，从传统的管理方式来看，是该使用容易评估的指标来监督团队的时候了。而这本身又会造成另一种障碍。”

    Nicholas Cancelliere分享了自己的经历：“就我亲身经历而言，我遇到过的最大障碍就是：表面接受、以为这只是开发人员的事、缺乏训练以及个人业务评估。我以前在一家公司工作的时候，他们的业务部门希望能在特定的时间内完成某些功能，但是无法对其进行优先分级，结果他们只是猜测应该在什么时期完成什么功能。并且，他们从不编写需求的验收标准，通常只是说‘怎样’去执行一项功能而不是描述功能的具体内容。简单来说就是他们陷入了表面敏捷的陷阱，所以命令与控制的方式继续保留了下来，而‘仆从式的领导’就变成了让人忌讳的词。他们会说他们用的是敏捷方法--但是他们是有选择地使用。结果就是，一切都如以前一样混乱。”