Scrum存在的头14年里，Scrum的实施主要是自下而上进行的。也就是说，一个开发团队可能开始使用了Scrum。它的客户会在一个月末就能看到可工作的软件。这个客户会欣喜若狂，以至于告诉她的伙伴经理。那个伙伴经理会问他的开发团队为什么不使用Scrum？这个团队于是也开始转变到Scrum。一个团队接一个团队，一个客户接一个客户，整个组织将使用Scrum改变自己并变得敏捷。就是这样开始了改变。
自下而上实施的最大优势是，在使用Scrum上，它能最大限度地减少命令和控制式的干预。在自下而上的实施中，项目中使用Scrum的人们也同样就是选择它的人们，所以他们十分有热情并渴望使用它。他们对作出调整让Scrum更好地为他们工作感到舒服。另一个优点是它的价值立刻能够向客户证明，这个客户然后会扮演一个内部推销员的角色帮助Scrum推广，这样一个客户、一个团队逐一地传播开去。
在过去18个月中，我开始看到自上而下Scrum的实施。这说明“C级”主管开始认识到使用Scrum所带来的竞争优势，并指导在整个组织范围内的使用。从能够确保这种改变发生和坚持上看，这种高层的支持是非常宝贵的。虽然与大多数这样的组织签有保密协议，我仍可以说出一部分使用自上而下Scrum实施的公司，包括第一资本公司、KeyBank银行、雅虎、Covad公司、西门子医疗和西门子电信。显然，对于组织的高层来说，Scrum的成功已经变得更加明显。这是个好消息。
自上而下的实施暗藏的不利因素是，Scrum像所有的敏捷方法一样，依赖于自我管理的团队——这与大多数自上而下的指挥正好相反。虽然管理层能够理解 Scrum的成功很大程度上是因为由做工作的人来决定如何工作，抵制干预性敦促可能仍然很困难，特别是当有人冒着风险进行自上而下实施时。刚开始实施Scrum的经理常常感到需要对成败负责，因而恢复到命令和控制的管理方式。
命令和控制的方式会带给 Scrum团队两方面的负面作用。首先，除非被告知做什么，开发人员习惯于等着做任何事情。结果，他们往往害怕采取主动，并常常责怪管理层阻止他们这样做。第二，管理层常常觉得如果不找出答案，而是等待开发人员自己找出解决方案，甚至包括让他们犯了错误，都好像是没有履行好自己的职责。
我最近在的一家公司，开发人员抱怨工程副总裁说他们不能写一个共同的持久层，所以不得不复制全部工作做了两个独立的垂直产品。当我跟副总裁核实时，他非常吃惊。他表示他都是为了重构，关于持久层甚至没有人问过他。然后我组织了一次包括开发人员、副总裁和他的管理人员在内的会议。我们发现即使管理层认为他们给予了自由的管理权力，开发人员在没有得到管理层具体指导的情况下，仍然害怕做正确的事。
改变从来不是容易的。关于自上而下的Scrum的实施，最近趋势的最大矛盾是高级管理人员有权在组织上作出改变，然而，指挥这些变化的发生却违背了自组织性。无论推动力是来自于上面或下面，Scrum要求的改变需要一个人一个人地、一个团队一个团队地发生。最终它会蔓延到整个组织。
作者：Ken Schwaber
Advanced Development Methods, Inc.
Certified: CSM, CSP, CST
Location: Boston, MA USA
英文原文：
http://www.scrumalliance.org/articles/1
