Scrum并非战无不胜，但每一次的失败，原因往往相同。Scrum能让问题迅速暴露，只有看到问题，才能解决问题。任何工作偏离轨道，都要马上亮起红灯，一个冲刺接一个冲刺，一个改善接一个改善，朝着目标前进。
当然，正确的模式意味着存在有错误的方法，或曰存在着反模式，并非每次实施Scrum都能成功，它也可能会失败。有趣的是，Scrum失败时，失败的原因往往是相同的。
再次强调一遍，Scrum的目的就是让问题迅速暴露出来。暴露问题通常会很痛苦，有时这种痛苦使组织难以改变。
几年前，金姆·安泰洛刚开始在Scrum公司工作不久，到我们合作的一家大型汽车公司去参观，参观后给我打来电话，反映客户表现不好，掌权之人没有权力，公司陷入无休止的诽谤和争吵之中，似乎安于耗费一个月又一个月的时间争论应该做什么，但实际上根本无所作为。我永远也忘不了这个电话。
“J.J.，不要恨我。”
“为什么？”
“Scrum在那里根本行不通。”
然后，金姆开始告诉我阻碍公司成为敏捷企业的因素，以及所有这些因素不太可能改变的原因。
金姆是对的。
所以Scrum公司终止了与那家公司的关系。我们只能提供帮助，不能强迫人家实施Scrum。
多年来，我一直在列出这样的问题，它在公司里反复出现。我发现知道不该做什么和知道该做什么一样重要。以下是这些反模式以及应对之策。
领导者不要半途而废
Scrum实践所需的组织变革是巨大的，要有不同的人力资源实践，不同的报告结构，不同的角色。要在整个组织中实现Scrum，需要高管层有强大的领导力。如果不建立新的行事方式，使之成为公司的工作方式，改革可能在瞬间土崩瓦解，公司最终非但无法身手矫健，反而会弱不禁风。
举一个个人的例子。我父亲在创建Scrum公司之前，在一家名为患者守护员(Patient Keeper)的公司工作。该公司为医生和医院制造手持设备，医务人员可以通过这些设备完成大量工作，比如开药、安排实验室测试、查看测试结果等。手持设备还能允许管理层收集财务数据、收取服务费用和提交保险索赔，也深受管理层喜爱。
在患者守护员公司，我父亲是首席技术官。他会见了首席执行官，谈到将如何使用Scrum来经营患者守护员公司。“很好，”首席执行官说，“但我厌倦了团队告诉我事情已经‘完成’。唯一重要的‘完成’就是收到医院的付款，没有悬而未决的问题。”
接下来，他们花了两年时间来建立这样的能力。最终，使多家医院每一次冲刺都能实况转播。如今，这种能力被称为开发运一体化(DevOps)，工具都是开源的，而且在云端就可以下载。但当年他们不得不从头开始构建这项技术。
技术构建完成后，首席执行官说，他们现在可以改变每周优先事项了。每周一下午，他都召集产品负责人和Scrum主管们，一起检查交付进度，修改需要修改的地方，为需要资金的内容提供资金，并重新定位造成麻烦的客户或竞争对手。人们说首席执行官就像产品负责人团队的Scrum主管。首席执行官让首席产品负责人来负责领导工作，只在出现问题时进行干预，消除障碍，包括改变出现问题的管理层。我父亲说，患者守护员公司就像一艘古老的英国战舰。产品负责人每周都会移动大炮，对准敌人开火。下一周，对准另一个目标。不到一年，患者守护员公司已经打遍天下无敌手。他们的工作主要是在一家又一家医院卸载竞争对手的产品，最后，他们的收入在一年内增长了400%。
后来，家父决定全职培训人们使用Scrum，遂创建Scrum公司。父亲留下的负责人让团队像时钟一样，每一个冲刺都准时培育出新的医院。两年后，那位负责人离职，首席执行官聘用一位不懂Scrum的工程主管来顶替离职者。不到一个月，团队就无法交付了。首席执行官告诉新来的人，如果再这样，你就要被解雇了。同样的情况再次发生，首席执行官决定亲自接管这个部门，并重新执行瀑布式管理模式，交付过程变得又漫长又痛苦。收入下降一半，患者守护员公司一瘸一拐，坚持走了几年，方才寿终正寝。这是一个伟大的公司因旧习惯而破产的好例子。
杰夫认为，原因不仅在于新工程主管个人不理解Scrum，还在于他们不理解组织需要不断改进以保持速度。杰夫在患者守护员公司倒下前一年看到了该公司的危机，并警告他们修复问题。但是管理层只是希望Scrum能继续工作，如果Scrum不能继续工作，他们认为那也不是管理层的错，是工程师们的错。然后，当然，工程师们纷纷跳槽。
这种情况我见过几次。一位高管将新东西投入某个业务部门，甚至整个公司，但没有来自高层的支持。一旦此高管晋升到另一个部门或跳槽加入另一家公司，新的工作方式就会分崩离析。领导层经常对此感到震惊。让同样的员工做同样的事情，怎么突然之间其工作方式就不起作用了呢？之所以会这样，是因为无论在组织层面，还是个人层面，都没有将向Scrum的转变内化。然而，他们领导的员工很少对管理风向的变革感到惊讶——改变并不鲜见，员工早已见怪不怪。
意欲最有效地实施Scrum，必须从高层领导自身的转变做起。高层领导全力以赴，在公共、财政和运营方面把自己的组织转变为一个能够在加速变革的新时代运作的组织。Scrum必须自上而下，成为完成工作的默认方式。不要只是反复说要怎么做，要反复付诸实践。如果每次不同的主管进来，你的工作方式都有所改变，那你并没有真正改变，你只是假装在改变。
不是为我，是为完成工作
Scrum通常从一个部门开始，通常是一个有严重问题的地方。这个团队开始快速进步，先声夺人。领导层就认为问题已经解决，太棒了，但公司的其他业务并未改变。领导层不断加码，提出要求、订单和项目，犹如向办公室中投掷手榴弹，完全不考虑此举可能造成损害，不考虑新任务是否应该完成，不考虑新任务与人们正在做的其他工作孰轻孰重，不考虑新任务是否能够完成。在拉开手榴弹引线之前，领导者务必深思熟虑。
组织的其他成员，包括领导层，都需要改变思考工作的方式。几年前，我们合作过的一家大型石油公司，正在更换其安全报告设施。这是一件大事，他们尝试多年，一个又一个项目统统宣告失败。最后，他们说服来自公司不同部门的两位雄心勃勃的高管，让二人再试一试。完成这项工作至关重要，两位高管也将其视为一次机遇。只要解决这个棘手的问题，天下非我等莫属。
其中一位高管得到一本《敏捷革命》，确信这是他们真正完成工作的唯一方法。一些Scrum公司的同事和我飞来，培训他们的员工，并成立了一批Scrum团队。一开始非常顺利，进展迅速。但之后不断遇到一个症结：另一位高管。这位高管虽然为得到的结果欣喜，在思想上却转不过弯来，不明白改变自己行为的必要性，继续用过去的方式管理团队。
Scrum非常善于揭示问题。很快就清楚了，这位高管的决策是个问题，拖慢了队伍的速度。令我惊讶的是，她最终明白了这一点，也确实改变了。但改变需要把问题和行为的代价暴露出来。
最终，工程准时完成，二人都得到晋升。一开始邀请我们合作的那位高管利用这一成功回到老板那里，据理力争，说Scrum不应该只用于软件项目，应该用于所有项目，无论是挖井、安装石油钻塔，还是通过管道泵油。Scrum会给他们带来优势，不能不用。于是，他们开始推广Scrum。
不过，她所做的第一件事就是确保领导们明白自己必须做出怎样的改变。
结构债务，不要太过精益
精益原则非常棒，基本上相当于丰田生产系统原则的西方译本，意在消除系统中的每一个浪费。精益企业研究院将精益原则列举如下：
价值：产品的价值需由最终用户确定。
价值流：为每个产品确定所有步骤，尽可能消除不创造价值的步骤。
流动：使创造价值的步骤按紧密的顺序进行，使产品能够顺利流向用户。
拉动：随着流量的引入，让用户在需要的时候从中获取价值。
完美：明确价值后，识别价值流，去除浪费步骤，实施流通和拉动；再次开始这个过程，并继续下去，持续改善，直到达到完美状态，在没有浪费的情况下创造完美的价值。
企业正确应用精益原则后，将极大提高价值交付的速度，消除价值交付的浪费。
问题是，如果舍弃太多，过度精益，就会从根本上削弱创新力。我见过几家公司，在生产一种产品时速度惊人，所需人员很少，令人钦佩。但是，除了生产正在生产的产品之外，公司没有做其他事情的空间。
他们专注于“持续改善”，即专注系统或团队的增量式改变，一点点持续改善。这很好，但他们只关注当前的过程，当前的做事方式，没有考虑这是否仍然正确，甚至根本没有考虑这样做对错与否。丰田生产方式的一个关键方面是“突破性改善”(kaikaku)，即彻底变革，允许改变整个业务：新产品、新策略、新工具。这可以是对市场力量的回应，比如苹果手机一经问世，突然间，每个人都不得不使用智能手机。但这也可以由内部驱动。通常，随着改善的渐进式改变，小步骤的进步会趋平，不再有进步的余地。所以要实施一个项目来改变一切，创建空白写字板，翻开新的一页，无论你想怎么称呼它，总之，要寻求根本的变革。
但如果机构过于精干，如果将员工裁减到刚刚好的规模，到了绝无懈怠的地步，也就没有时间和资源去创新了。我认识的一家公司成了苹果手机某个关键部件的唯一供应商，生产的部件数以百万计。后来，苹果想要不同的东西，需要用全新方法进行生产。由于已经使系统变得非常精简，结果供应商花了好几个月才适应彻底改变的生产方法。知道吗？苹果公司已经选择与另一家供应商合作，因为后者行动更敏捷。
适度精干的公司是好的，但如果精干得太过分，会使公司最终丧失应变能力。
别按照工具告诉你的方式工作
有很多Scrum工具，即管理待办事项并跟踪工作进度的软件。我每周至少会收到一次这种新软件。这些年来，我自己用过4种不同的工具。每种工具都有自己的怪癖：有的工具希望你估计每项任务需要花费多少时间，有的工具能够生成你想要的报告，有的需要与系统进行笨拙的交互才能使其工作，有的必须在5个不同的屏幕上勾选对话框才能得到你想要的东西。
我看到一些团队根本不考虑实际状况，不管工具的要求是否荒谬，就束手束脚，极力按照工具要求的方式来推行Scrum。工具是按照某种工作方式设计的，很有可能与你的需要有出入。
应对策略如下。我知道你可能需要使用一些工具，但在使用该工具之前，在墙上贴一些便签，进行几个冲刺，找出特定团队如何工作最高效。可以是一些简单的事情，比如你如何表明某些东西已经准备好，要显示给产品所有者。或者，是否有基于其他团队工作的依赖关系，你需要以某种方式使其可见，以便他们知道什么时候阻碍了你的工作。
只有完成这些之后，才可以求助于工具，使其按照你的工作方式工作，忽略工具的特性。有些特性你可能本来不打算使用，但更适合你的团队，不妨试试这些性能。记住，让机器人为人工作。
怎么做很重要，拜物教式Scrum
瓦努阿图是由大约80个岛屿组成的岛国，因以下几个原因而闻名遐迩。它是最早受到海平面上升影响的国家之一。詹姆斯·麦切纳在其1947年出版的《南太平洋故事集》一书中描述过这里。这本书激发了罗杰斯和汉默斯坦获得灵感，创作出音乐剧《南太平洋》。瓦努阿图的几十座岛屿散布在800平方英里的大洋上，其中一个岛屿叫塔纳岛。在塔纳岛，2月15日是约翰·弗拉姆日。约翰·弗鲁姆是岛民心中的弥赛亚，将用货船载满财富，来拯救这里。欲知此事的来龙去脉，且听我慢慢道来。
第二次世界大战之前，这个岛国被称为新赫布里底群岛，是整个世界宏伟格局中无足轻重的地方之一。突然之间，全球冲突使这些小岛变得非常重要。美国海军抵达后，海军工程营在丛林中开辟道路，修建机场、基地和兵营。最终大约有40万军队驻扎在那里。部队带来货物，数十万吨军供物资简直是一场盛宴，如同海啸般席卷岛国。于是约翰·弗鲁姆的形象诞生了：“我叫约翰，来自美国，想要一块糖吗？”
后来，战争结束，美国人离开，放弃了基地和机场，将似乎源源不断地降落在简易机场或在码头卸载的货物也带走了。约翰·弗鲁姆形象却融入当地的宗教，成为将货物运回的弥赛亚。为召唤约翰·弗鲁姆归来，岛民在丛林中仿造了简易机场，上面有灯光，有一座由木头或树枝或岛民能收集到的当地材料建成的指挥塔。岛民相信，只有热烈、正确地表演这个仪式，约翰·弗鲁姆就会回来。我一点都没有瞎编。
今天，他们仍然在胸前画上“USA”字样，手持木枪，模仿军事队形跳舞，宣称约翰·弗鲁姆会回来的，他们甚至为此创建了一个政党。见鬼，就在不久前，一位信徒还曾短暂担任过驻俄罗斯大使。“拜物教”在过去和现在都是真实存在的。
这种拜物教式的仪式化运动也可以发生在Scrum中。我曾经见识过。人们只是走过场，装样子，奉Scrum指南为圣典，似乎相信Scrum的唯一目的就是Scrum本身。我在五彩缤纷、灯火通明、看起来很有趣的“Scrum室”中游走一番，问团队是否在完成每一个冲刺并有所交付。闻听此言，人人皆面露不安之色。
我们有一家大客户，是一个拥有大约5万名员工的公司，他们决定，既然要做Scrum，就把所有曾经是项目经理的人都召集到项目管理办公室，让他们统统成为Scrum主管。
新皈依的项目经理们带着真诚的信念和热情，对Scrum的拥抱有点过于强烈，使其变得怪异。他们去上课，去读书，去参加会议，学习如何玩敏捷游戏，大谈特谈做服务型领导的真谛，然后开始工作，搞活动，在托盘里盛满便利贴，就像祈祷约翰·弗鲁姆归来的岛民一样，把仪式和哑剧错当成行动。
没有人听取这些新的Scrum主管的意见。在会议上，他们完全被忽视。他们的建议被置若罔闻。他们本人被视为无用的附属物，空耗时间、空间和金钱，却毫无成效。
发生这种情况的原因是，照字面理解，他们的工作描述不外乎“促进Scrum”。仅此而已，没有人期望他们做其他事情。他们是会议管理员，全都对Scrum知其然，不知其所以然。
他们似乎没有领会到Scrum是一种完成任务的方法。是的，人们的生活将会更好，有望互相尊重。我也希望人们的工作更有趣，但正如我之前所说的，Scrum主管存在的唯一理由是速度，他们却没有意识到这一点。
我问Scrum公司的麦考尔·巴格特如何改正教条式Scrum时，他告诉我：“Scrum主管必须成为团队中的专家。”麦考尔是一名教练和培训师，客户的Scrum主管需要帮助时，我会找他出面。
“要成为成功的Scrum主管，”他说，“必须不断沟通。沟通很复杂，说起来容易，做起来难。”
麦考尔说：你必须利用数据和团队沟通他们的工作情况和表现。如果一个团队没有进步，必须向他们展示他们的速度，他们的冲刺承诺，他们是如何工作的，并征询他们的意见，问他们可以如何改进。必须观察他们提出的每一个改善意见，向团队反馈，问他们：“嘿，这样做是否有效？”
Scrum主管还必须观察对话的进展情况。麦考尔说，这与团队成员或产品负责人的思维模式截然不同。好的Scrum主管不关注团队讨论的事情是否正确，而是关注团队是否以正确的方式讨论事情。正确的讨论方式会加快工作进展。
以下几个问题是麦考尔评价Scrum主管的依据：团队是否在不断改进？团队开心吗？团队开心是基线。Scrum主管在促进公司进步吗？如果Scrum主管在消除阻碍团队前进的障碍，则最后一个问题很容易回答。Scrum主管工作的本质是消除减慢团队速度的因素。消除减慢团队速度的因素不仅有利于Scrum主管自己的团队，而且可能会帮助很多团队，甚至公司本身。
不要只是走过场。仪式不是现实。
不要做按菜单点菜式的Scrum
Scrum非常简单，共分3种角色、5种活动、3种工具、5个价值观。各个要素都很重要。要实现所追求的生产力的根本改变，必须同时具备以上所有要素。各个要素是相互关联、相互加强的。我们经常看到团队缺少一个或多个要素，或者在某些要素方面表现不佳。
Scrum公司被要求评估Scrum实施状况或实施一项Scrum项目时，这些要素就是我们的着眼之处。我们经常看到很多团队，没有专门的团队成员，或者没有全职的产品负责人，或者缺少其他一些基本元素。我们推荐建立一个可见的表格，记录所有团队以及Scrum的每个元素是如何被实现的(以及实现得怎么样)。
我们通常把表格展示在白板上，使每个团队的状态一目了然。在表格中，我们显示他们是如何做的。他们做得好吗？他们在改善吗？形势在走下坡路吗？
在每个团队中检查这些信息，可以快速掌握Scrum在公司中的状态，也使得Scrum的障碍显而易见。Scrum主管可以用它作为障碍列表的基础，予以优先考虑。最好每次冲刺都这样做。项目走上正轨后，甚至可以在每次活动结束后做，不会花多长时间。唯其可见，才可以迅速采取行动，解决问题，而不是等到3个月后才发现团队因为没有良好的待办事项清单或因为跳过待办事项清单的优化，不能按时交付。
目前，可能并不是所有这些元素都一直保持良好的状态。没关系，从现在开始，一步步慢慢提高。见鬼，哪怕你只能努力实现每日立会，仅仅这一点就能让事情变得可见，并且有所助益。然后，就可以开始逐个处理其他要素了。
但所有这些要素都很重要，都有影响。需要纪律和专注，需要不断检查、微调和试验，才能面面俱到。
有一家全球领先的农业设备制造商在这方面做得相当出色。实施Scrum初期，他们只做其中的几件事。从每日立会始，然后添加冲刺计划，再后来添加冲刺检查。负责领导在多个国家的8个研发中心转型的人并没有急不可待地敲桌子，他只是每周不停地发邮件，告诉大家这样做或那样做的好处，实施这个模式或那个模式。变化是缓慢的，渐进的。但在18个月内，他们的速度加快了8倍。更重要的是，他们正以快得多的速度将原型产品推向市场。他们通过正确执行Scrum，交付了真正的价值，但成功是通过一天天稳扎稳打获得的。
不要外包
大多数与我们合作的大型组织都进行大量的业务外包。在一些公司，承包商构成劳动力主体。顺便说一句，我觉得这样做愚蠢至极。但是让我们把重点放在业务外包实践中的Scrum部分。有人经常会打电话来说：嘿，能给我找50名Scrum主管吗？需要明天就上岗工作。
我想我可以找50名Scrum主管，而且明天就可以上岗，并因此赚很多钱。但我认为把Scrum这样的核心竞争力外包出去是非常糟糕的想法。如果真想使企业重生，Scrum将起关键作用，使你知道做什么，怎么做。倘若把怎么做外包出去，就不会使知识内化。
我不是说你不应该报名参加培训和指导。你可能需要，但也要确保自己的员工接受培训。你们需要有独自进行Scrum的能力。在Scrum公司，我们弘扬一种信仰，就是要建立能够组建、指导、维护和加速自己团队的真正伟大的公司。我们的工作就是辅助所服务的机构建立这种内在的能力，使之不再需要我们的扶植。我告诉我们所有的教练和顾问，我们的工作就是把永久的变化抛在身后。但是，最重要的是，我们一定会离开。
Scrum是一个非常简单的框架，但在石油天然气公司实施Scrum与在银行或研究实验室实施Scrum情况大不相同。当然，它们之间存在共性，但每个组织，就像每个团队一样，都有自己的文化、思维和行为方式。正如一种尺码不能适合所有人一样，一种方法也不能适用于所有情况。
不要租用能让公司变得伟大的人才。要培养让公司变得伟大的人才，让培养人才成为你所做一切的一部分。
顽固的障碍
几年前，我在硅谷访问了一批新的科技、社交媒体和互联网巨头。我在其中一家科技巨头公司做了演讲，然后问在座的各位，你们最大的障碍是什么？什么情况最能拖慢你们的速度？什么妨碍让你们抓狂？
一个勇敢的人站起来说，部署的工作不断积压，排起长队，已经8天了，还在增加。我们却被告知要构建更多的产品功能，而不是去修复交付中的瓶颈。
我问房间里的人这是不是真的。大多数人点头赞同，有几个人鼓掌。
我问在座的Scrum主管，是否让管理层看到了这个问题。他们说，报告过，但被告知不要作声。
6个月后，这家著名的大公司(我不能说出这家公司的名字，因为进入公司大楼之前，他们让我签署了一份保密协议)因为产品交付的速度不够快，解雇了首席执行官。
看出问题容易，但解决问题难。有时要花很长时间才能修复一个非常棘手的问题。然而，必须着手做些事情来解决问题。如果不这样做，员工就会知道你没有认真对待。
我鼓励领导团队做的是设置一个看得见的障碍告示板，放在人们常来常往的显眼之处，首席执行官的门口就是不错的地方。在告示板上，应该标明障碍相应的级别，附上负责解决每一个障碍的经理的照片，并显示从提出障碍到解决障碍已经过去多少天。倘若不能在首席执行官门口的告示板上面找到障碍，你就要亲自去追踪障碍。
一次，一位老朋友打电话给我。当时他正与数十名记者和编辑致力于一个遍及全国的重大新闻项目，他被难倒了。事实上，整个项目都陷入僵局。他们有些事情需要批准，但批准一直没有实现。副总裁很忙，要么不回复邮件，要么说告诉Scrum主管我很快就会处理，但是我现在有一个非常重要的会议，必须马上参加。
我告诉我的朋友用便利贴，把所有需要完成的工作都贴在墙上，让告示板显示那张不动的便利贴是如何阻碍其他工作的。然后拿出手机，拍张照片，不仅发给当事副总裁，还发给其他各位副总裁。要友善，要彬彬有礼。但是每一天都要这样做——嘿，只是要确保您知道我们仍然受阻，非常感谢您在这方面的帮助，完全理解您日程繁忙。朋友花了3天时间，问题才算解决。
解决出现的问题，或者至少开始修复问题，向人们展示你正在如何修复问题。这样，你就可以清楚地展示你让公司走敏捷路线的决心。
专注于有效的东西，你的生死取决于产品负责人
产品负责人是团队与外界之间稳定的接口，要负责很多事情，也要为很多事情担责。他们决定市场需要什么，以及团队交付产品的顺序和速度。
但事实是，有时这份工作不被重视。或者公司将职位名称从业务分析师改为产品负责人，但不更改职位描述，换言之，除了称谓的变化，其他一切照旧。或者公司找来一位非常忙碌的经理说，嘿，你现在也是产品负责人了，但是继续做你原来的工作。或者有高管坚持要做产品负责人，但没有时间与团队互动。或者把高级技术人员任命为产品负责人，但是高级技术人员同利益相关者或者用户之间缺乏互动。如果用一贯的方式做事，就会得到以往一贯的结果。优秀的产品负责人是用Scrum制胜的关键。
Scrum公司的首席产品负责人帕特里克·罗奇这样描述产品负责人的作用：“你正在带领一支探险队进入未知世界，成功与否将取决于你的计划，生存与否取决于你激发周围人创造力的能力。你难免遇到大麻烦，这是一个需要承担严重后果的角色，也是令人兴奋的角色。”产品负责人责任重大，此言不谬。
让一群出类拔萃的人做着出类拔萃的工作，速度非常快，但做出的东西却不被认可，或者做事的方式南辕北辙。这是我所见过的最悲哀的事情，不妨举两个例子。第一个例子是诺基亚公司。短短数年，诺基亚公司就从行业霸主沦落为无关紧要的公司。他们有十分优秀的Scrum团队，身手敏捷，甚至还组建了诺基亚测试团队，来测试各个团队是否真正敏捷。测试团队专门探究如下问题：你的冲刺时间有多长？有产品负责人吗？有燃尽表吗？有按照优先顺序排列的待办事项清单吗？
如果你所做的只是按照选项打钩，就可能产生误导，任何测试都不例外。诺基亚有非常优秀的Scrum团队，交付速度之快令人难以置信。当然，苹果手机上市之后，诺基亚出类拔萃的Scrum团队以难以置信的速度交付的产品却成了不被市场认可的东西!这是因为产品负责人对市场的重大变化反应不够快。诺基亚之败，错不在团队，错在产品负责人判断失误。
第二个例子。我与一家金融服务公司合作，帮助他们在云端完全重建交易系统。他们希望能够升级防欺诈保护系统，因为罪犯更新了实施欺诈的方式，而且更新的速度比他们快。他们面临相当高的风险，因为他们有数百万的客户和数千万次的交易，这只是每天的交易次数，如果重建不能在那个夏天的特定日期推出，他们将不得不支付给第三方供应商一大笔钱，让供应商代理他们处理交易。这笔款项数目高达数千万美元，堪称高得出奇。
推动这个项目成功的真正关键是一群杰出的产品负责人，他们毫不动摇地专注于在正确的时间获得正确的待办事项清单，不允许积压工作。产品负责人对每个冲刺负责，并不定期地把整个项目的燃尽图发给我。燃尽图几乎完美地倾斜到他们必须命中的日期，最终他们如期完成任务。到黑色星期五，新系统完全投入运行：每秒可处理600项交易，50毫秒的响应时间，超过99.9%的系统开机运行时间。现在他们可以无缝地改变防欺诈模式，这一项目每年为他们节省3800万美元。同时，他们停掉了第三方供应商，一年又节省4000万美元。这就是称职的产品负责人所能做的事情。
优秀的产品负责人可以从根本上改变组织的轨迹。记住，产品负责人必须果断，能够根据不完整的信息快速做出决定；必须知识渊博；必须对相关领域和市场足够了解，以便做出明智的决定。无论是对团队，还是对客户，他们都必须随叫随到，对团队和客户各投入一半时间是一个标准的经验法则；如果做不到这一点，他们可能是利益相关者，而不是合格的产品负责人。他们必须被赋予行动的权力，拥有做出正确决策的自由和权力，并在决策时得到领导层的支持。最后，他们必须负起责任，因为无论团队做什么，成功与否都与他们息息相关。
懂得什么必须发生，什么不必发生
戴夫·斯莱特是Scrum公司的低语者，负责培训产品负责人，属于那种说话温和、作风彪悍的人。戴夫见过很多公司死于产品负责人，所以开发出一个工具包，帮助解决这一问题。在这里我想分享的是我认为作为一名产品负责人最重要的部分：决定不应该做什么。
戴夫设计出一套练习，他称之为“校准图”，我称之为“痛苦之墙”。首先，让产品负责人离开房间(毕竟，他们只需要花50%的时间和团队在一起)，去写下希望团队做的最重要的事情。产品负责人离开后，让团队成员写下团队实际在做的事情。最后，将产品负责人和团队集合起来，比较所写的内容。戴夫说，大多数时间，团队都会考虑事情的优先级，但他们正在做的事情中有很大一部分是低优先级的，是没有人真正希望做的事情。
戴夫指出，解决办法很简单。要教会产品负责人用不同的方式来考虑待定项，明确在特定的时间需要什么，戴夫称之为最低交付量。待办事项清单写得正确时，产品负责人和团队成员所写的内容会完全一致。这个练习通过强调一个标准来推动团队一致性，验收标准专门用来回答一个简单的问题：“我知道什么时候该完成什么事。”
正如戴夫所解释的，这个测试“不会告诉团队他们必须做什么”，而是向团队明确“他们不必做的事情”。决定不做什么远比决定做什么重要。只做现在需要做的，只做本次冲刺需要做的，不要眉毛胡子一把抓。
数据不在乎你的意见
我在商界经历过的最奇怪的时刻发生在一个不起眼的办公园区，这里简直是建筑师们平庸能力的缩影。身临其境，你难免心生疑问，想知道建筑师们是否会对自己乏味的能力感到特别自豪。
不管怎么说，在这座平淡无奇的建筑里，有一间平淡无奇的会议室，只是因其空间阔大而引人注目，有30多名高管坐于一张巨大的马蹄形桌子周围，开年度计划会议，决定明年要做什么项目。我很想看看他们怎么做。
一位高级副总裁把一个电子表格投影到墙上，上面有一堆项目，没有真正按优先顺序排列，只是他们觉得必须做的事情，他们称之为“大石头”。高级副总裁环视一下房间，每个人都有成摞的文件和打开的笔记本电脑，电脑上是各式电子表格，不时有助手在各位高管耳边窃窃私语。高级副总裁说：“是这样，我们在未来一年里有50万小时的工作时间，其中包括雇员和承包商在内。萨拉，你已经拿到列表上的第一项。你认为你需要多少小时？”
莎拉查阅了文件、笔记本电脑，咨询过助手：“2.5万小时。”
另一位副总裁插话说：“2.5万小时够用吗？问题很棘手。”
“好吧，那就定为3.5万小时吧。”
会议就这样进行。对于给出的数字，没有给出任何理由。除了在会议室里胡乱猜测之外，没有做任何有意义的估算。顺便说一下，在过去的一年里，有12块“大石头”，他们不多不少，只完成了其中的1块。
我知道，且不论为完成这3.5万小时的工作，需要多少人，组建多少团队，更不论团队是否分布于世界各地，只要会议一结束，莎拉的团队就要为名单上的第一个项目做准备了。无论估计准确与否，都要为这3.5万个小时安排预算、要求和日程。
我的同事乔·贾斯蒂斯给我讲了一个更荒谬的故事，我们不妨称之为一种“独特的”关于项目和预算的决策方式。乔当时在与一家全球制造商合作，被邀请参加来年的规划会议。规划会议在一艘游轮上举行，没错，就是在游轮上举行。结果会议变成了一场豪饮派对。“就这样，这些醉醺醺的人一边在游轮舞厅里饮酒，一边决定明年的工作重点、预算，以及谁负责哪个项目，”乔告诉我，“简直太疯狂了。这背后没有任何理由，没有逻辑，没有数据，只有一群醉醺醺的高管。”要知道，这群醉酒者正在敲定的是高达数亿美元的预算!
知道吗？上述两家公司可谓竭尽全力，力争把事情办好。问题出在他们没有运用恰当的数据。
Scrum创造大量的数据：速度、过程效率、幸福度等。但光有数据还不够，必须使用数据，了解团队的速度。让负责做一项工作的人评估该项工作，一个冲刺接着一个冲刺，实时跟踪进度。如果工作开始偏离轨道，你很快就会知道，能及时纠正。
金姆·安泰洛开始在一家跨国制造公司工作时，他们内部条块分割非常严重。每一位副总裁都把自己负责的一部分业务当作自己的领地来管理。这导致公司的不同部门独立地多次制造完全相同的产品，而且不告诉其他部门。公司工作缺乏优先顺序。金姆开始与公司领导层进行合作时，发现有2000种不同的产品正在开发中。均摊下来，每个员工大约负责两个产品。
为了避免重蹈覆辙，他们组建了产品负责人团队，认真审视自己在做什么。他们把产品数量降到大约200种，由20个产品团队负责。这个级别的产品负责人团队实际上是一群首席产品负责人的产品负责人，每个人的团队中都有多名首席产品负责人，每个首席产品负责人又都有自己的产品负责人团队。这样，一个大组有3个级别的首席产品负责人。
这些产品负责人每周聚集一次，了解工作进展状况，讨论发生什么会改变事情的优先顺序。每个季度，决定哪些项目将得到进一步资助，哪些不会。对于每一个产品，他们都深入研究，根据Scrum团队提供的数据，分享他们的推测，判断可以交付什么产品。他们只能得到当前一个季度的资金。几个月后，他们必须回来展示学到的东西，明确接下来要解决的问题，认定可以推出产品的时间。只有这样，才能得到更多追加的资金。
有时候，他们会认识到他们真的不应该做什么，或者认识到一个原本认为不重要的产品变成了真正重要的产品。因为他们是迭代地、连续地在一年的过程中进行投资，而不是在年初对将要发生的事情知之甚少时确定所有的项目投资，所以，如果开始出现问题，他们可以迅速扭转局面。他们能够根据实际结果预测，而不是盲目猜测，在非常高的级别上改变优先级。他们使用数据驱动决策，而不是根据意见来驱动，这使得整个组织的优先级划分变得简单易行。
让我再举个例子，看看透明度能为你做些什么。我们与一家大数据公司合作过，该公司的首席执行官掌管几个项目，分散在许多团队中。具体讲，有几十个团队。团队要做一堆事，她想知道团队在一个特定项目上的速度，而不是团队的速度。她要解决的问题是团队多快能完成这个特定项目。
我们告诉她，这不成问题，她所要做的就是把各队的估计数字加起来。“但是你不能在各个团队之间比较和估算速度。”首席执行官说，“你就是这么告诉我们的。”当然，我们这么告诉过她，但关于全盘估算我们知道什么？它是错误的，所有的全盘估算概莫能外。但就此公司而言，我们有足够多的团队来进行评估，通过比较，差异就会浮出水面。
他们给相关待办事项贴上“重中之重项目”标签，让各个团队进行一个个冲刺，获得团队之间的燃尽图。因此，她每周都能看到团队在以多快的速度完成这个特定的项目。
为了讨论，让我们假设他们在几周内每周燃耗掉这个重中之重项目的20%～25%。燃耗率看起来很好，他们很有信心按时交货。但是奇怪的事情发生了，首席执行官一周一周跟踪观察，数据在一段时间内都很好，然后在几次冲刺中急剧下降。发生了什么情况？毕竟，探明异常是首席执行官的首要任务，所以我们进行了调查。结果发现，另一位高管为团队安排了其他优先事项，减缓了团队在重中之重项目上的速度。
因为首席执行官在预期发布日期前几个月就了解了情况，所以可以采取行动，让曲线回到正确方向。她第一次觉得自己可以真正掌控自己的组织，知道所关心事情的现状。她不需要状态报告或PPT不停地说项目处于绿色状态，直到截止日期前两周左右，项目状态却突然亮起来红灯。她不需要意见，也不需要精心制作的报告，她有数据。
使用Scrum，可以获得大量数据。可以做实验，并快速查看结果。经验系统不断地检查和适应：探索、响应、评价、探索、响应、评价。无论是团队级别还是企业级别，实时完成这项工作都很重要。在某种程度上，这是一张安全网。你不会在一个长达一年的项目上冒数亿美元的风险，你只是在冲刺。随着条件的改变，可以随时改变主意。
大多数组织的经营状况很糟糕，糟糕有糟糕的好处。最大好处是很容易迅速改变，能产生巨大的积极影响。我之前讨论过，但我想把相关内容放在一处，以便易于您找到。这些措施几乎可以在一夜之间从根本上提高团队的开发速度。
小团队：3～7人的团队是理想的，团队越大，减速越显著。
稳定的团队：把项目交给人，而不是人交给项目。
参考过往的工作量来估算目标：只承诺上次完成的工作量。
专注的团队：让团队切换任务，会降低速率。
每日立会：每一天、同一时间、同一地点。
中断缓冲区：要有应对意外的计划。
清晰的待办事项清单：明确需要完成什么。
良好的内务管理：一旦发现缺陷立即处理，绝不拖到第二天。
蜂群模式：一次只做一件事。
彻底完成：在每次冲刺结束时，工作都被全部彻底完成。
合作：每个人都应该听到彼此的声音。
如果这些方面你全都还不具备，可以从其中一个开始。一点一点，一个冲刺接一个冲刺，一个改善接一个改善，朝着实现这些目标前进。可能有些情况你无法控制，无法实现所有的目标，不过没关系。
如何做你所做的事情很重要。如果决定不做某件事，就需要知道决定的代价，代价常常是不可见的。但你必须看清世界的本来面目。因为如果看不到问题，如果不能谈论问题，如果不能质疑问题，就不能解决问题。
我真心希望你能解决问题，我希望人们生活在能够充分发挥潜能的世界里。一旦你完成了从接受到行动，从被动到强大的转变，你工作的世界将不再和以前一样。我想生活在这样一个未来，在那里，对人类潜能的浪费被视为不必要的悲剧。我想对我们正在创造的东西感到惊讶。
你可以做到。你的决定是一种选择，未来并不是一成不变的。
回顾
当心反模式。你有没有听人说过“我要找出一份最糟糕的做法清单并加以遵循”？当然没有。并不是每次实施Scrum都能成功，它可能会失败。有趣的是，Scrum失败时，失败的原因往往是相同的。
按照菜单点菜式Scrum的问题。是的，即使是糟糕的，或者部分的Scrum也可以提高生产力，但效果有限。Scrum非常简单，共分3种角色、5种活动、3种工具、5个价值观。各个要素都很重要。为了实现所追求的生产力的根本改变，必须同时具备以上所有要素。各个要素是相互关联、相互加强的。
领导力。意欲最有效地实施Scrum，必须从高层领导自身的转变做起，全力以赴。Scrum必须自上而下，成为完成工作的默认方式。因为如果不建立新的做事方式，并使之成为公司的工作方式，改革可能会在瞬间土崩瓦解，公司最终非但无法身手矫健，反而会弱不禁风。
要数据，不要意见。Scrum会创造大量数据。但光有数据还不够，必须学会使用数据。你可以做实验，并快速查看结果。经验系统在不断地检查和适应：探索、响应、评价、探索、响应、评价。
不要外包。不要租用能让公司变得伟大的人才，要培育人才。让培育人才成为你工作的一部分。倘若把怎么做外包出去，就不会使知识内化。
待办事项清单
√确定你或你的组织目前采用了多少反模式，把它们写在便利贴上，贴到墙上。只有消除反模式后，才能移除便利贴。