敏捷转型中管理层的认同和支持
敏捷转型是一种涉及管理层的组织级变革。我们常说管理层的认同对于敏捷是否能取得成功很关键，缺少管理层的支持，敏捷转型就可能会遇到巨大障碍。公司中管理层支持敏捷有很多不同的方法。
Arijit Sarbagna在《规范的Scrum（prescriptive Scrum）》一文中讨论了在敏捷转型过程中管理层的认同和支持的重要性：
假设我们正在以敏捷方式开发项目，最初采纳敏捷不是自上而下的，而是徒劳的“自下而上”。在这种情况下中，很可能我们就会错失了“管理层认同”这个关键因素。缺乏管理层的支持，打造自组织团队的良好意图很可能会走进死胡同。作为ScrumMaster或者敏捷教练，我们需要花费大部分的精力来说服管理层（或者客户），而不是实际上的指导团队。
根据Arijit的观点，对经理而言支持自组织团队非常困难：
（……）管理团队遭遇决策的困境，在团队成为“自组织团队”过程中应该留有多少回旋余地。这很搞笑方，我们不得不跟管理层解释敏捷是如何工作的，为了使敏捷有效，管理层应该相信敏捷。有时我们必须要提醒管理层，如果我们不信赖员工，即使瀑布式开发也不会成功。信任是成功的支柱，围绕着信任我们补充了工程实践。
Arijit建议经理不应该强制实施Scrum：
但是，如果我们正在处于规范化Scrum困境的话，比如很可能管理层会指导团队，敏捷应该怎么做（或不应该怎么做）——这些人可能从未实施过敏捷而只有理论知识——那么这只会让事情变得更糟，或者变成“失败的故事” 。
相反，Arijit建议“宣扬和鼓励理解敏捷的人，从而拥抱实践”。
Zvonimir Križ写过一篇文章《亲爱的经理，我们已经敏捷了（dear management, we’re already agile）》，文中质疑缺少管理层的支持是否是采纳敏捷的真正障碍。这个问题可以理解为，当关注于实践而不是敏捷原则的时候，实施敏捷的唯一方法就是自上而下：
从诸如Scrum之类的实践直接开始敏捷可能使人们相信，敏捷“旅程”需要深层的组织变革。当然组织变革需要管理层的支持。另一个更有趣的原因是瀑布式开发本身。为了更加精确，瀑布式开发需要大量的前期规划（upfront planning）。这也是我们大脑中的一种思维惯性，为了成功，所有事情——包括敏捷转型——都应该详细规划。此外，管理层需要如此大量的前期规划和重大决策。
Arijit建议敏捷转型还可以采用自下而上的方法：
有时候人们忘记了自下而上的敏捷转型是合理的。
每个人应该都知道采用敏捷原则不需要依赖管理层。（……）你可以现在就开始。不需要任何理由！
我们曾采访过Jeff Sutherland，他在《敏捷做了对的事，但方向却错误（agile done right and agile gone wrong）》一文中提到了领导力和团队。Jeff在Google Plus上分享了这次采访，他提到管理层可以采取如下做法来支持敏捷：
这和管理层的认同无关。而是与敏捷管理层如何敏捷、领导以及展示变化相关。在某些大型公司内，会有由高级管理层组成的Scrum团队。他们不会赋予团队执行Scrum的权利，而是自己也在执行Scrum，并且希望团队和他们一样执行Scrum。
在敏捷转型过程中，中层管理者该如何支持呢？Em Campbell-Pretty写了一篇文章描述这个问题《对敏捷教练与中层管理者沟通的建议（advice for agile coaches on “dealing with” middle management）》。文中说明了为什么管理层的认同如此重要：
和开发团队一起工作时，中层管理的认同非常关键。对于敏捷转型工作，中层管理者可以是良好的动力也可以是克星。如果团队认识到管理层不支持敏捷，那么在试验和冒失败风险的时候他们还会觉得安全吗？我曾见过有些组织尝试敏捷转型，而管理层仍然是传统思维。对于团队而言，这将是毁灭性的问题，如果团队相信敏捷的价值观如透明性，那么他们就会因为暴露事实而受到管理层的谴责。
针对如何解决来自中层管理者的阻力，Em Campbell-Pretty给出了如下建议：
有些管理者慢慢发现敏捷对他们有威胁。实施敏捷很可能意味着改变，没有人喜欢改变。在这种情况下，或许可以考虑一下Dennis Stevens和Mike Cottmeyer的建议（Agile 2013大会上的“不要谈论敏捷”），而不是迫使顽固的经理实施敏捷。相反，我们应该关注于业务目标，以及如何帮助管理层达到他们的目标或减轻他们的痛苦。
通常组织里的中层管理者也同样处于困境。根据Em的文章，敏捷教练应该负起责任，寻找方法和中层管理者一起工作并支持他们的工作：
中层管理者其实并不容易，实质上他们就像“三明治里的肉”，处于组织的高级管理者和普通业务人员之间。中层管理者的责任大于权利的情况司空见惯。这可能非常令人沮丧，并且让我怀疑命令与控制管理风格的盛行，是否是大型的官僚组织里中层管理者丧失权利的直接后果。中层管理者的注意力从组织繁文缛节的沮丧转移到改善员工的生活上，对于管理者和团队都是一种回报。不要忘记，中层管理者和其他人一样，倾向于能为我带来什么好处（WIFM——what’s in to for me）。中层管理者必须明白敏捷会如何帮助他们获得成功。
Mike McLaughlin写了一篇题为《耐心的敏捷教练（the agile coach on patience）》的文章，文中他谈论了敏捷转型对于中层管理者的影响：
许多中层管理者在放手控制权上似乎都有一段困难时期。他们觉得还是需要插手。微观管理了许多年，可能有数十年，要想打破这些实践很困难。即使在团队授权的重要性方面中层管理接受过很多培训，但是在脑海里，他们仍然不确信团队是否可以完成工作，因此还是继续执行微观管理。
对中层管理者和团队而言，采取自组织也很困难：
（中层管理者）有效地阻止了团队发展成自管理、自组织的团队。结果就是，团队继续按照中层管理者的指导行事，或者得到授权才会做事。我把这个现象叫做中层管理者陷阱（Middle Manager Trap）。中层管理者继续制定决策，并一直质疑为什么敏捷团队不能自己负责任。这是一个恶性循环。
Mike建议中层管理者可以展现对团队的信赖，并留给团队转变为自组织团队的时间，从而支持敏捷转型。
能够实现180度大转变（leap of faith）、信任、委派、耐心，实际上是一种对于他人的投资。对于一个新成立的敏捷团队来说，可能要花一段时间才能获得良好的投资回报（ROI——Return On Invest）。过了这段时间后，团队或个人可能还是比较纠结。偶尔的小错误是可以接受的。因为我们需要长远地考虑。
Brian Erwin给领导敏捷转型的高管们写了一封公开信《致引领敏捷转型的管理层的公开信（an open letter to executives leading agile transformations）》。他建议管理层应该相信员工都很诚实，且能够努力工作，他还建议管理层可以通过环境来支持敏捷转型，从而帮助员工完成工作：
管理层需要打造一种组织环境，在这个环境下对于员工来说采纳敏捷的阻力最小，而不仅仅是采用和强制实施一些如Scrum、极限编程或看板等敏捷方法。
Brian的公开信里还包含了一套帮助高管打造环境的行动计划。其中一些建议如下：
在组织里开始展现你所期望的行为。造势最有效的方法之一就是先改变你自己和你的行为。实际上你不能强迫别人改变，但你可以鼓舞他们改变。（……）
不要在团队级别强制实施一种方法。不要强迫团队实施Scrum或其他方法框架，要把敏捷落地（……），通过移除组织障碍来提供和展现你个人的支持与承诺，还有你的立场。（……）
投桃报李。（……）如果你打造了一个环境，鼓舞员工奉献一切，视公司如家，并且通过投资员工展现出他们的价值的话，那么你的组织会有更大的可能性长期赢得市场。
