为什么转型困难

任何变革都是困难的。我曾经看到过一些员工因为公司医保套餐有变这等鸡毛蒜皮的小事情而吵闹。更大一些的变革，甚至可能更加痛苦。但是，有一些向Scrum转型的特性使其比其他变革难度更大。这些特性具体如下。

　成功的变革不是完全的自上而下或者自下而上。

　结束状态是不可预知的。

　Scrum是无处不在的。

　Scrum是截然不同的。

　变化来得比以往更快。

　最佳实践是危险的。

成功的变革不是完全的自上而下或者自下而上

成功的组织变革不能是完全的自上而下或者自下而上。在自上而下的变化中，强势的领导分享他对未来的展望，组织跟随他向目标迈进。可以想象，一个充满魅力、受人尊敬的强势领导，比如史蒂夫·乔布斯（Steve Jobs），告诉他的苹果团队，他们要主导计算机软件和硬件之外的数字音乐市场。他的声望和风格也许会给公司指出一个新的方向，但是仅仅这样做还不足以赢得如此卓尔不凡的成就。变革管理专家约翰·科特（John Kotter）认为：

没有任何一个个人，即便是像君主一样的CEO，能制定一个正确的愿景，和大量的人沟通这个愿景，消除所有的主要障碍，取得短期的成功，领导和管理数十个项目，进而将新的方法深深地扎根到企业文化中。（1996，51-52）

与之相反，在自下向上的变革中，一个团队或一些个人决定需要进行变革，就会着手促成其发生。一些团队采用自下而上的变革时带着“期望事后谅解”的态度。另外一些团队则炫耀自己是在打破规则。有些团队则仍然以钻空子的方式进行尝试，能钻多久是多久。

大多成功的变革，特别是向Scrum这样的敏捷过程转变，必须包括自下而上和自上而下两个部分。对此，Mary Lynn Manns和Linda Rising所见略同，在Fearless Change: Patterns for Introducing New Ideas一书中，她们写道：“我们相信引入变革的最佳方式是自下而上的，同时需要管理层在适当时候给予支持，包括基层和更高层的。”（2004，7）一个组织尝试向Scrum转型，如果没有公司高层的支持，他们会遇到基层无法克服的阻力。这常常发生在一个Scrum过程开始影响初始团队之外的其他团队的工作的时候。作为应对，中层管理者可能会为保护自己的部门而剔除Scrum带来的变化。移除这些类型的障碍和困难需要自上而下的支持。

同样，没有自下而上的保证，这个转型感觉像是在一个露天的墨西哥餐厅吹电扇一样，只是一股热风从上面吹下来。这时，个人可能会抵制安排给他的事情。自下向上的参与是有必要的，因为团队成员才是工作的主体，他们才知道如何使Scrum在企业内变得更有效。

成功实施Scrum的关键是结合自上而下和自下而上的变革相关要素。

结束状态是不可预知的

也许你读过一些关于XP（极限编程）方面的书，确定它是适合自己公司的正确方法。也许你参加过CSM课程（ScrumMaster认证课程），认为Scrum听起来不错。或者你也许读过一本关于其他敏捷过程的书，觉得它对你的组织来说很完美。

但是，十之八九，你是错的。

这些过程没有哪个像其发明者描述的那样百分之百地适合你的组织。所有这些过程，也许会有一个很好的开始，但都需要对它做适当的调整，使其更准确地适应于独一无二的组织情况、人员情况以及行业的情况。Alistair Cockburn赞同道：“有机会改变或者定制一个过程，使其更适合其本身，是团队成功实施其过程的关键因素。”(1)只有正确的创造活动才能帮团队找到正确的适合他们的开发过程。

你也许对Scrum应该怎样有一个清晰的愿景，你也许也可以让其他人获得同样的愿景，但是组织最终会是什么样子可能有所不同。事实上，甚至Scrum转型的“结束状态”这种提法本身就不对，因为这是一个没有终点的过程，需要持续的改进。

对希望通过依靠差异分析进而解决具体差异的传统方式向Scrum转型的组织来说，这就成了一个问题。如果我们不能预见到Scrum转型的结束状态，便无法确定当前状况和结束状态之间的所有差异。如此一来，差异分析驱动的变革就不奏效了。我们充其量可以做到确定我们现在的状态和改进后中间状态之间的差异。

确定这些小的差异之后，我们仍然需要面对如何解决这些差异的问题。准确预见人们如何应对敏捷转型过程中需要的许多小的变化是很困难的。团队协作专家Christopher Avery把组织比喻为一个生态系统：

生态系统是绝不可以管理的，我们只能干扰它，然后等着观察它的反应……我们无法知道有哪些动力在合力打造我们希望改变的这个组织，所以，只能拿一个我们认为可能产生一些影响的实验来驱动这个系统，然后静观其变。（2005，22-23）

所以，Scrum转型过程并不像我读过的一本传统的变革管理书籍（Carr, Hard, and Trahant 1996，144-5）定义的过程那样“阐述和定义消除‘现在状态’到‘未来状态’之间的差距所需要的整个变革过程，然后创建战术计划”。创建这样的计划需要跨越两个不可能跨越的障碍：第一，清楚地知道我们在哪里结束；第二，知道到达终点的具体步骤。因为无法克服这些不可能的事情，所以我们只能采取“刺激和观察”办法（Avery 2005，23），先进行尝试，看它是否能驱动我们逐步靠近中间部分有改进的状态，如果见效，我们就可以接着进一步尝试。对组织机构的这些刺激和促进并不是随意的，而是根据经验、知识和直觉精心挑选的，旨在驱动着组织机构成功实现Scrum转型。

Scrum是无处不在的

当变革孤立存在时，当它没有影响一个人所做的所有事情的时候，这种变革往往更容易引入组织中。考虑一个组织要引入一个非敏捷过程的案例，组织决定在应用程序部署到Web服务器之前，必须强制执行一个操作状态检查。这是一个相对孤立的变革。当然，会有一些开发人员讨厌新的流程，他们会抱怨，甚至会大声抱怨。但是，在提到它的时候，这不是一个普遍的变革。即使有人不喜欢这种变革，他们仍然可以继续做他们的工作。大多数工作都不受影响。

现在来看一个开发人员向Scrum转型的案例，这个开发人员要一次做一小部分工作，在每个固定长度的Sprint结束的时候，要完成一些内容。她可能需要为新写的每段代码编写自动化测试。测试驱动开发的情形下，她甚至可能采用交替的方式写测试代码和程序代码。结对编程的时候，她也许需要关掉耳机来做这些所有的事情。这些都是根本性的变化。这些事情不是那些只涉及到一天或一周内几个小时的事情，比如可能的代码检查。这种根本性的变化是困难的，因为它贯穿一切有关开发人员的日常工作。因为受影响更大，所以阻力会更大。

在另一个方面，实施Scrum也是无处不在的。敏捷对组织机构的深远影响将远远超出对软件开发部门的影响。在引入操作准备就绪检查的情况下几乎可以肯定不会影响财务、销售或其他部门。但是，在实施Scrum的情况下，这些部门都会受到影响。财务部门将不得不使公司资本运作和花费相关的政策与Scrum项目运作的方式保持一致，销售部门将考虑改变他们传达日期和范围的承诺方式，并可能改变他们的合同结构。由于转向Scrum会影响更多的群体，所以更有可能遇到阻力，遭致更多的误解。这些加起来，使得Scrum转型比其他变革更加困难。

Scrum是截然不同的

实施Scrum带来的变化除了遍及开发团队成员所有要做的事情，许多变化还会与其过去的培训内容产生冲突。例如，许多测试人员学的是他们的工作就是按照说明书进行测试。程序员所接受的培训是解决问题之前一定要先进行深入的分析，有完美的方案之后再开始编码。在Scrum项目中，测试人员和程序员需要忘掉这些行为。测试人员需要知道测试也和符合用户需求有关。程序员需要知道在编写代码之前并不一定需要有经过深思熟虑的设计（有时候甚至并不可取）。Abby Fichtner在她的Hacker Chick博客分享了她的想法，她告诉我她赞同这些调整对于程序员来说相当困难。

习惯于涌现式设计（emergent design）是困难的，它有种让你乱来的感觉。如果你正自豪地觉得自己是一个非常优秀的开发人员，总是做出细致、全面的设计，它就会让你的世界天翻地覆。你会说：“不，所有我考虑的事情使我非常优秀，但是现在这些同样的事情，却让我成为一个不合格的开发人员。”这真是不可思议。

由于过渡到Scrum要求人们使用他们不熟悉的方式来工作，有悖于他们的培训和经验，所以如果不是彻底抗拒变革，人们往往会犹豫不决。设想，以Terry为例，公司内部受人尊敬的一名高级程序员。他参加了一个一整天的实操性测试驱动开发课程，认识到它带来的价值。充满热情的Terry回到他的办公室，期望不要再做大量的前期设计，通过使用测试驱动开发让设计自然出现。这并没有像他想像的那样顺利。他给我写了一封电子邮件，诉说了他挫败的经历。

甚至让其他程序员尝试一下测试驱动开发都比我想象的困难。我尝试去推动它，作为一种可以摆脱我们习惯了的长期的前期设计阶段的一种方法。但是我痛苦地失败了。几个月之后，我让另外一些开发人员开始先写测试用例，因为先写测试用例本身是一个好主意。他们仍然无法丢弃长期的前期设计阶段。我又花了一年的时间来努力缩短这个过程，我们仍然可能把它变得更短。

变化来得比以往更快

早在1970年，Alvin Toffler就创造了一个术语——未来冲击（future shock）。是指当人们面对“瞬息万变”的时候感到的迷惑（1970，4）。人进行改变的能力是有限的，因此企业进行改变的能力也是有限的——要求人们在同一段时间内做太多改变，他们是无法承受的，毁坏性的压力和未来冲击产生的迷惑会随之而来。在许多企业中，员工多年来一直忍受着未来冲击的折磨。团队被要求用更少的人干更多的活儿。外包和分布式团队已变得越来越普遍。这些调整之前是迅速将应用程序转向CS（client/server）模式，然后是转向Web，再然后是转入基于服务的模式。这些再加上持续变化且日益加快的技术自身的变化——比如新的语言、新的工具、新的平台——就是未来冲击。所以，过渡到Scrum屡屡成为将人们推向未来冲击的变革就不足为奇了。实施Scrum无处不在的天性和导致人们工作和交互方式根本性变化，更容易面临触发未来冲击效应的风险。

最佳实践是危险的

对于大多数的变革，当一些人找到正确或者最佳方法之后，这样的做法被总结归纳为“最佳实践”，并分享给其他的人。对于某些类型的工作，收集和重用最佳实践对于变革工作有巨大的好处。比如一个企业，可能正在销售一个面向新客户类型的产品，找到了一种消除潜在客户异议的最佳实践。但是，在向Scrum转型的时候，收集最佳实践是危险的。

就像警报器会发出警报提醒船只绕开暗礁一样，最佳实践会使我们放松，进而停止进行持续改进的努力，而这正是Scrum中所必需的。大野耐一（Taiichi Ohno），丰田生产体系概念的创导人，写道“有一些事情称之为标准工作，但是标准是在不断变化的。相反，如果你认为这些标准工作对你来说已经是最好的，那么一切都结束了。”大野接着又讲：“如果我们把一些事情作为最好的可能方法，那么对于精益[持续增量的改善]的动力就消失了。”（1982）

尽管团队成员应该不断地与其他团队成员分享新发现的理想工作方式，但他们应该抵制那些鼓励将这些内容编成一套最佳实践的做法。有一个歪曲最佳实践的例子：公司决定，所有的每日站会都必须在上午10点以前开。我发现这是一个完全没有必要的命令。我完全搞不懂这个决定的目的是什么。但是，接受此规则的许多员工得到进一步的结论是“Scrum就是微观管理”。