不只是 LeSS

序言：为什么还要用其他的方法做大规模 Scrum？

本文来源于两个意图：

• 虽然敏捷社区对大规模敏捷的实施带来了令人耳目一新的方法，但在解决企业在大项目上的复杂性方面，这些模型似乎仍然有些匮乏。许多团队已经采取了一些最佳实践，将商业愿景中的需求分解为可运行的代码。但是产品负责人看上去非常孤立，他被充斥着含糊不清的利益关系的复杂项目环境所包围。此外，组织文化和领导力仍然没有得到应有的重视。
• 借鉴 13 年的敏捷项目工作经验教训和五年的研究让我相信，在已经获得成功的大规模敏捷项目上获取的实践经验已经足以建立一套可重复使用的实践了。这就是大规模 Scrum 的全面方法。它是在 LeSS 的基础上做了一定的修正，以便更好地面对大型项目的挑战。我特别注意项目内外的冲突。

特别感谢 Ben Linders，Peter Hundermark,，Siegfried Kaltenecker，和 Stefan Jäger 对本文进行了审校，并给与有价值的评论。

变革难题

组织如何采用新的方式运行大型敏捷项目，并且在过渡过程中，像 LeSS 和 SAFe 这样的模型又扮演了什么样的角色呢？

首先，让我们设定以下基本假设：

1. 组织的变革最重要在于组织文化的改变。
2. 组织变革的结果本身是不可预知的。

这两种模型都不是新的思想。他们是系统组织发展（Organizational Development（OD））的传统观点，慢慢地在敏捷社区变得越来越普遍（Leopold 2012, 部分 II）。通过系统的方法彻底地考虑把组织作为自组织。一些管理人员或许认为，只要选择好一个新的组织模型，就可以随时切换到这种模型上，这种想法只是管理人员的“控制的错觉”而已，系统理论的创始人，Niklas Luhmann 把这个想法变成框架，系统组织发展也正是基于此框架（Lhumann 2011，第 85 页）。按照系统组织发展的观点来看，变革是应该被激发的而且可以很好地获得引导（Königswieser 2008, 第 147 页），但不能根据计划，预先定义结果来创建变革。促进真正的变革需要信任，相信大家可以得到解决方案，而解决方案是他们的经理们不能提前所预见的。这种激励自主是发动组织所拥有的资源，并保证可持续变革的关键。

这就对组织上很多的决策者们提出了要求：他们必须准备好接受这个不确定成果。这正好与高管人员通常所寻求的相反：通常他们追求低风险的方式来实现短期目标。通常寻找大家都认为容易实现的目标。这导致了所谓的“变革难题”。小规模的组织变革可以减轻问题，方便地避免潜在的结构性问题。但由于长期的结构性问题依然存在，下一个问题即将来临，并且需要应用另一个快速解决方案。遏制组织的不健康程度是通过治疗症状，而不是运行专业的变革计划去解决潜在的根本原因。因此，不太可能发生什么实质性的变革。组织持续工作在低潜力价值的地方：它忙着收获短期目标，从而无法达到更高的水平。

基于这些假设，当我们做大规模 Scrum 的时候，那些如 SAFe 和 LeSS 模型会有什么样的价值？如果变革的结果不可预知，为什么还需要一个模型？依我之见，这样的模型可以帮助我们为变化过程中的不确定性找到方向。通过展示全新的方式工作，它们可以激发新的愿景。它们还可以提供有价值的、实用的原则，并且从中进行学习。当我看到 Spotify 如何工作时，

我喜欢这样的工作方式。（在去年的 Henrik Kniberg 访谈中（Charron 2013），谈到了更多有关 Spotify 如何将他们的愿景转化为行动的内容）。但是决定什么方向，对于采用模型组织中工作的人们来说，是他们的特权。他们真正的工作是：了解他们的强项，通过整合新的方法逐步演变。如果只是通过利用一些新的模型来减少变革中的不确定性，不可能达到可持续的变革。为什么组织犹豫要用一年的时间跳入到下一个时尚的模型？

SAFe 和 LeSS 模型理论出来的时间都比较短，都没有对组织长期影响的案例研究。然而这种假设可以从他们框架的性质，在过渡过程中从它们会指向什么样的方向中推断出来。就 SAFe 而言，它似乎给组织更大的自由度，可以按照他们喜欢的方式采用。它提供了灵活性，但也保留了很大的回旋余地来规避对抗不受欢迎的问题。SAFe 可以把管理结构用于现有的瀑布 Scrum（Water-Scrum-Fall）方法中（是第一批 SAFe 采用者用的方法，他们在 2014 年 7 月的慕尼黑敏捷世界（AgileWorld）上介绍了他们的案例）。那样可以很容易地避免这个问题，即为什么要使用瀑布式 Scrum 方法。SAFe 并不否定 Scrum 的流程，但它看起来也没有像 Scrum 那样具有变革的煽动力。

SAFe 这个框架名称是经过仔细选择的：它对经理们可能是一个比较安全的方式，他们可以在项目集和项目组合层面获得较好的结构。但它在以下方面的成效令人质疑，例如这个方法是否更具有生产力、有更好的客户导向、是否可以缩短上市时间等等。因此，敏捷社区对此反应不是很热烈也就不足为奇。就如 Ken Schwaber所说，“从统一软件开发过程 （Rational Unified Process（RUP））来的家伙又回来了。在重大失败的RUP 基础上，他们现在推广规模化敏捷框架（Scaled Agile Framework（SAFe）），试图把它作为简单的，可以用这个单一的解决方案满足敏捷组织中的所有情况。”（Elssamadisy, 2013）

WIBAS 是一家德国咨询公司，他们显然有点务实，把它放在一个分化的方式。 他们一方面给予了 SAFe 正面的评价：“从程序集和程序组合层面持续地思考”，同时他们断定，“在程序集层面使用了很多‘经典’的术语，这给转型需求戴上了一层面纱，让敏捷爱好者更难采用SAFe。

在另一方面，由Crag Larman 和Bas Vodde 创建的LeSS 看上去像从单一团队层面到多个团队层面项目自然而然的Scrum 流程改造（Larman 2010）。它详细地描述了如何构造和分解项目范围，并且如何在内部构造大型敏捷项目。在敏捷方法论中的开发阶段，这似乎是一个自然的演变步骤，因为它携带了原来的思想（查看Cohn 2010，第327 页）。Larman 和Vodde 也提供了在组织结构中会用到的实用的日常原则。LeSS 专注于价值流上的资源，邀请经理们再次成为劳动力的一部分( Larman 2014 )。

然而，LeSS 就如我感觉的一样，它很少留意组织如何处理持续改变和跨团队改进。有人可能会说 LeSS 在大规模项目中延续了 Scrum：它把 Scrum 的组织结构运用到规模化的大型跨团队项目。并且和 Scrum 一样，LeSS 方便地规避了项目的复杂性：它基本没有提到项目的环境问题，尤其是干系人和他们模棱两可的利益。不幸的是，这就是为什么多数大型项目失败的原因：交付的产品无法满足客户和干系人的期望。（Spielhofer，2011）

所以我相信LeSS 能够并且应该做得更好。下面的章节将根据Larman 和Vodde 的理论进行全面的方法讲解。与最初的假设保持一致，它将成功一个指明方向，组织可以使用它用来运行多个大型敏捷项目。

主要的挑战是什么？

在定义如何运行多个大型项目的解决方案之前，让我们从高层面来看，需要解决方案解决的主要挑战是什么：

挑战 1-团队之间的冲突：除了其他方面以外，项目还是人们所处的一个社区。任何社会系统，甚至是一个运行很好的项目，都会有一些内部的冲突。这可能是我们都经历过的。Scrum 提供了有效的方式去解决团队层面的冲突。Scrum Master 可以缓解一定程度上的直接冲突，帮助我们建立良好的团队。在大型项目中，面临的挑战随着团队的数量增加而变大，团队越多，团队间产生摩擦的机会就越大。

有人说 Scrum 延续了部落的发展，在进化的过程中使人类社会化。部落的结构可以在团队成员之间建立牢固的纽带，这当然是建立高效团队的资产。但如果团队太强调团队本身的成长则不利于运行多个团队：群体思维或部落主义都可能导致团队之间的冲突。

挑战2-项目环境的内在冲突：项目干系人，就是那些最终判断项目是成功还是失败的人，他们之中会产生摩擦。为了应对这种不和谐，了解深层原因非常重要。不幸的是，这有一堆各种可能的原因，而每一种都需要不同的处理，例如：

• 权衡利弊，什么对这个是最好的，什么又是对另一个最好的。一个市场计划也许会把产品 A 作为焦点。对于什么是对公司最好的，对利润和损失负责的产品负责人 A 可能和产品负责人 B 持有不同的意见。传统的奖金制度鼓励这样的思考方式，即把公司的目标分解成组织实体的目标。这样，他们更注重局部优化，其代价则是减少了对组织整体的改善。
• 干系人对于市场的洞察力不同，对于什么是对组织最好的方式也有不同的理解。
• 不是每个人都视公司的利益在个人利益之上。在争吵那些功能的背后可能隐藏着自己的规划。与内容相关的决定可能只是一场政治游戏的棋子。
• 其它。

大型项目往往会影响多个组织单位，基于这个事实，这些问题会加重。举几个例子来说，忠诚计划，合规项目，或市场活动就像热刀切黄油一样会切断组织的边界。因此，这些组织单位的关键人物的利益可能会产生变化，并且这些变化并不总是透明的。

项目环境在不断地运动中是不明确的。这似乎是避免大型项目充足的理由。它明确地促进了敏捷组织的愿景：创建很多独立的产品线与独立的团队，从而减少复杂性。不需要更多的干系人达成共识，取而代之的是由一个产品负责人负责利润和损失，他做这个决定，这样就够了。就像我从 LeSS 中所学到的那样，它作为组织的方向灯，指明了这个方向。但到了我们工作在真正的敏捷组织中时（这可能是为什么几乎没有真正的敏捷组织的原因 ）（Walton，2014），我们就需要应对这个复杂性。即使如此，如果我们把愿景放到现状中进行核实，我们可能发现我们不想完全消灭利益的多样化。通常总有个合理的理由，为什么不应该由一个人（产品负责人）做决定，而是在决策中也要聆听其他人的声音。例如，HR 从员工长期的角度或者关注市场对品牌整体的影响参与决策，作为公司的负责人，你想要这些声音消失吗？组织往往用内部的复杂性满足外部的复杂性，识别什么是有价值的，什么是日常开销并不那么简单。

对于以上内容，我将其称为大型项目的策略型挑战：

• 管理与项目有关的冲突。
• 管理与项目环境有关的冲突

在大型敏捷项目积极的愿景下，这种冲突是推动项目前进的动力，而不是阻力。

另外，以下是我称之为大型项目的主要运营挑战，例如：

• 保持项目在多个团队之间的透明，精确地评估项目的状态。
• 管理多个团队中之间的依赖关系。
• 把需求分解到团队层面。
• 持续关注项目目标，防止团队分散。
• 让多地点的多团队或离岸团队合作。

图 1

图 1 中提供了由 5 到 15 个团队参与的某项目的主要人力概览：客户和他们的需求（绿色），组织中可发挥能力的项目干系人（蓝色）；和利益与需求相关的团队（橙色）。当传统的项目建立时，这些利益者往往与项目经理相冲突，在这个三夹板位置上，许多优秀的人才也会被挤垮。

在下一章中介绍的方法就是为了解决这个内在的风险。用基本的设置来满足项目自然的动力，这个结构的设置将能力使用这种能力，而不仅仅是解决这个症状。

大规模 Scrum 项目新的指路明灯

一个积极的愿景是，在项目内外与这些动力合作去解决冲突而不是站在他们的一边。毕竟，阻力也可以被认为是可以提供交流的能量，而不是互相的争斗。然而， 事实证明这一点对于个人来说难度太大，他需要考虑太多不同的视角，而且有时候不同的观点也会彼此冲突。另一种解决方式是作为领导团队来面对这个复杂性，而不是一个人，这种方式参考了后英雄式领导的思想和“将管理层作为团队运动”（Kaltenecker，2011）理论。随着项目规模的增长，这一点变得更加重要，领导能力必须与项目规模成正比。

图 2

图 2 显示了三个主要的角色一起组成了项目的领导团队。

• 产品负责人（绿色）负责为客户创建优秀的产品。
• 项目环境推动者（蓝色）负责在不同的干系人之间权衡利益。
• 项目推动者（橙色）负责创造可以让团队展现自己创造力和生产潜力的环境。

产品负责人和 Scrum Master 在团队中的角色和实践与 LeSS 一样，运营挑战可以用结构来解决，并且 LeSS 提供了很多的结构。它深入的描述了功能如何分解到团队层面，并且他们的实施如何做计划。因此它也提供了合作模型，将组织内部的价值流从从商业愿景转换为经过持续集成和测试的代码。另外两个角色主要是解决策略方面的挑战。这三个角色在一起形成了管理铁三角，在项目内外形成了力量渠道。

所有这些角色都是基模。这个想法并不是说只要雇佣了这些角色就可以拍掌欢呼了。这个想法是要求我们在每个大型项目开始时问自己：项目内外我期待什么样的力量。一旦有了最初的源头，就可以创建包含这些角色的领导团队来解决这些挑战了。在这里列出一些成功的设置方式：

设置 1：

• 一名产品负责人。
• 一名项目经理，他的角色注重对外聚焦。
• PMO，他扮演的角色更像是公司内部的推动者，而不是经典的控制办公室。

设置 2：

• 一名产品负责人。
• 两名敏捷项目经理，一个专注内部，一个专注外部。

设置 3：

• 一名产品负责人，可以很好地管理这个环境。
• 一名项目经理，主要专注于内部，但有时候当处理棘手的干系人时会帮助产品经理唱白脸。

但这些敏捷的设置和传统的项目管理团队有什么区别？三大传统项目管理方法之一的 Prince2，也推荐项目领导组。根据 Prince2 描述，项目委员包含三个角色，分别代表客户（或者行政经理），用户和供应商或有特别要求的人员。

那么项目推动者和供应商代表之间的差别是什么？依我之见，差别主要在于这些领导者在日常情况下采取的立场。潜在价值在这里起到了巨大的作用，他们利用这些价值，价值就变成了他们的一部分。就如 Stacia Broderick 在她的著作《软件项目经理通往敏捷的桥梁》（Sliger 2008）中的所描述的，，这需要一个改造自我的真诚之旅，从命令和控制型的领导变成推动者。例如，项目推动者是否尊重团队的自组织，就会有很大差异。

这个理论同样适用于与干系人合作。项目环境推动者要试图创建透明的环境，彼此之间建立信任而不是在项目周围建立难以逾越的障碍。就如最初的假设一样，文化是任何转型中关键的因素，包括领导层文化。可以在“敏捷领导力模型”文章中找到更多有关领导层如何工作的内容（Spielhofer and Kaltenecker 2012）。

运行大型Scrum 项目的有益实践

下面选择了一些实践，对敏捷领导团队运行大型Scrum 项目有所帮助，敏捷领导团队的介绍如前所述。他们专注于解决项目的策略型挑战，也可以结合使用Larman 和Vodde 推荐的实践。本文选择了一些例子，描述了领导团队使用这些方法工作的方式。这并不意味它就是全面的，这样会超出了本文的范围。

持续反思

关于项目状态的任何评估都是不完全的，另外，它是持续变化的。因此，项目领导团队所控制的项目设立、发布计划和其它任何东西都应该是持续地进行调整适应的。在一个领导团队里工作而不是单兵作战会有很多好处：对同一件事，不太可能两个或者三个人有相同的盲点。另外，领导团队可以像Scrum 团队那样具有相同的创造力。为了利用好这一价值，查看持续反思的原则或者德文的_Reflektionsleberkäse_ 可以对我们有所帮助。

实践 1： 持续反思或****Reflektionsleberkäse

作为领导团队，腾出时间定期地反思这个项目。把自己从日常的工作中解放出来，从树林中走出来看到整片森林。比较在脑海中项目的不同片段。寻找一下你没有充分解决的那些挑战。

当这样做的时候，用比喻可能会比较有帮助。我有时候用的一个比喻是，雾天里站在船头上寻找冰川。冰川对我们的危险有可能是什么？当我们在铺设前行时有没有适当考虑这些危险？

在寻找冰川时，要在你们中间建立同样的审美文化，就像你和你的团队、干系人一起工作时候那样：聆听、接受不同的意见，并且，最重要的一点是给不确定性一定的空间。这冰川就是你现在看不到，但是你想通过你的雷达发现的。不确定性可能是一个巨大的资源，引导你进入未知的世界。把这种反思的会议作为一种仪式可能是比较有帮助的。

在一次 Scrum 转型中，一名经理朋友和我定期地一起散步，在我们吃午饭（午饭是传统的巴伐利亚香肠卷）的时候会反思困扰我们的那些问题。这个过程是辛苦的，但我们可以通过吃饭和散步的方式接受，并且称之为： Reflektionsleberkäse。

透明的力量

透明是变革强有力的引擎。如果你选择无视它们，那也很容易避免处理这些问题。但如果它们就在你的眼前，他们就很难避免了。一旦你意识到这个问题，就很容易变成你想去抓的痒并想让他消失。

在大型项目中，透明还可以帮助我们减少由于缺少信息或信息来源不同而引起的不信任。如果我们不知道正在发生的事情，我们就会倾向于想象在 IT 中发生了什么，在产品管理中发生了什么。研究表明， 在组织中用敏捷方法会让沟通变得更加清晰（Kaltenecker 2011）。有关更多敏捷项目中透明的力量的内容，可以在Christina Böhm 和 David Haselberger 所写的敏捷项目管理的透明度的研究中找到。

但是随着项目规模的扩大，维护透明度的任务就变得越来越难。当有8 个、甚至15 个团队在树林中全速前进时，就很容易失去对整个森林的观察力。并且干系人越多，让他们保持消息灵通越难。下面的一些实践可以帮助我们：

实践 2：建立共同语言

作为领导团队，定义简单的可以反映项目状态的报告。就和任何报告一样，这将是对实际情况超级简化报告。要确保报告是被所有团队和干系人理解和接受的，足够精确的反应项目情况。

这一报告的基本内容通常是燃尽图（参看 Peter Hundermark 的“更好地做 Scrum ”，第 60 页）。这个图表的价值在于可以帮助我们预测这个项目可能完成的时间范围。它是基于团队的速率和他们对未来工作的估算。因为这是团队的主观估计，最好的办法是对照真实的交付物多方求证。它给团队提供了外部尺度参考，如果团队接手了一个不熟悉的项目，尤其推荐这种方式。一些现实中的多方求证可以通过如下提供：

• 在产品开发中，找到类似范围的产品，可以作为开发的基准。
• 在迁移项目中，参考现有数据库和代码的大小及复杂度度量。
• 功能点分析。

不管报告中包含什么，如果双方接受，就变成了团队和干系人之间的共同语言。他们可以用这个语言来谈论项目现在进行到哪里，问题是什么。

干系人管理

如前所述，信息需要很好的传达到干系人那里。但是如果发生了一个严重问题怎么办？如果在干系人中他们的决策非常不一致怎么办?

实践3：管理干系人期望

尽管你的报告很好，但要记住，它只是对现实情况的一种简化视图。在敏捷项目中，报告可以帮助我们粗略的估计时间范围，什么时候项目可以比较现实地完成主要目标。然而，我们不知道，也不想知道要交付的范围细节。相反，我们想要给自己一些调整的余地。在敏捷宣言中说“响应变化高于遵循计划”。

这也不能总是满足干系人的期望，有些干系人想要根据预定的结果知道精确的交付时间。为了建立与干系人的信任，公开传达任何预测的不确定性可以有所帮助。干系人都有不同的商业背景，如果用他们可以理解的语言解释，有助于相互理解沟通。这是项目环境推动者的工作，保持信息顺畅流动。他或她从产品负责人那里接管这个职责，那么在这样的讨论中，从为客户创建好产品的角度出发，帮助产品负责人推动他或她的想法。

实践 4：把受影响的干系人变成参与干系人

公开表达问题是在大型项目中很自然的事情。除了把它暴露在日光中，几乎没有比它更好的方法来消除不详的威胁。问题就变成了机会，可以让我们的干系人参与到解决问题的流程中；为受影响的干系人提供信息以及能够让他们也做出贡献的方法。这就把他们变成了参与干系人：人们就会做出贡献而不是从方便有利的方面评论这个项目。从那时起，任何干系人的项目评估就会变成他们自己工作评估的一部分。对一个项目来说，还有比干系人对项目的承诺更好的事情吗？

就算干系人把问题和解决方案踢回给项目，公开它仍然可以得到项目最重要的资产：信任。

产品负责人和项目环境推动者要一起应用这个实践。推动者可以缓和这样的讨论（有的时候讨论非常激烈）。产品负责人可以专注在“让客户满意”，参见 Stephen Denning 的“激进管理的第一个原则”（Denning 2010，第 4 页）。

内部与外部之间的沟通

据 George Bernard Shaw 所说：“沟通 上最大的问题就是发生幻觉。”在敏捷的设置中，直接沟通可以对提问和重组产生多个沟通回路，从而避免了许多幻觉。但是在多个干系人和多个团队之间如何维护直接沟通呢？如果我们认同自组织是整个组织结构的DNA 的一部分的思想，那么沟通也必须是自组织的。然而，当环境变化的时候，例如当启动一个新的大型项目，顺畅的功能性沟通则需要花些时间才能逐渐形成，尤其是当项目内外的人们互相不了解甚至互相不信任的时候。给彼此互相了解和找到共同点给予足够的空间，可以促进项目沟通和解决冲突。

一个非常难以建立有效沟通的项目例子是在公司合并的时候，来源于不同的文化和相对立的利益冲突。对待这种项目，有一种不太友好的方式是完全压制，让一种主导文化完全压倒另一种，从经验上来说，这种方式往往会造成大量的间接伤害。下面的实践追求更多的合作途径。它可以用于在公司合并或者项目内外低信任度的其他情况：

实践 5：不要阻碍沟通，而是促进沟通

作为项目推动者，考虑用正确的时间和正确的设置，让关键的干系人能够与团队的代表讨论敏感的问题。要试图提供有利于讨论的安全环境。只要在约定的框架下约定的方向上辩论就可以。不要试图控制和评估参与者。如果讨论升温，要确保的是公平的争论，而不要涉入到战火当中。

用敏捷团队管理合并的项目，我们安排了一个拓展的工作坊，由合并 IT 公司的总经理和工作在这个项目上的所有团队代表参加。议程就是建立对状态的共同意识，并讨论手边的一些实际问题。作为领导团队，我们主要是作为引导者，对会议的时间、地点和议程进行周全的考虑。生动的讨论会增加经理们之间的信任，而且他们发现对于项目的看法也消失了。与此同时，项目的团队面对他们的经理们也表达了他们对项目的承诺。这种承诺就像看不见的合同一样具有持续的效果。总之，组织已经为努力找到共同的方式向前迈出了关键的一步。

我们能学到什么？

总之，本文中描述的全面方法为解决大型项目关键的挑战提供了一些设置和实践。这是从 5 到 15 个团队规模的成功敏捷项目中推论出来的，在设置未来的探险中，可以作为一个指路明灯重复使用的。它理解组织经常会有一些变革，并且一些变革需要推动。这个需求为领导力提供了空间，这是一种新型的推动式领导力，目的是形成推动项目前进内外的力量渠道。这个方法包含了 LeSS 作为有效的基本原则来解决运营的挑战。另外，它介绍了两个新的角色：项目推动者和项目环境推动者。他们和产品负责人角色一起形成了领导铁三角，可以解决在大型项目中通常遇到的主要的挑战和风险。本文进一步提供了一些实践方法，帮助领导团队日常工作的执行。

关于作者

Thomas Spielhofer 在 2001 年领导了第一个敏捷项目，在 9 个月内用极限编程的方法从无到有地建立了一个新的互联网银行企业，从那以后，他作为负责部门经理和顾问帮助组织引进 Scrum。他是澳大利亚的 Y Unternehmensberatung 公司的联合创始人之一，并且担任总经理角色， 在那里他是系统和敏捷教练。Thomas 对敏捷方法的好奇从未衰减，并从事编辑了敏捷项目管理平台一书。

参考

1. Bachl, Walter 和 Spielhofer,Thomas （2010） ，“用 Scrum 成功领导：案例分析”，敏捷项目管理平台。
2. Böhm,Christina 和 Haselberger, David（2010），“敏捷项目管理中透明的概念”，敏捷项目管理平台。
3. Charron,Todd （2013），“ Spotify 的大规模敏捷: 采访 Henrik Kniberg ”， InfoQ。
4. Cohn,Mike （2010），“Scrum 敏捷软件开发”,，Addison-Wesley。
5. Croome,David （2014），“ Scale 大规模敏捷实践”, 敏捷世界。
6. Denning,Stephen （2010），领导者激进管理指南，Jossey-Bass。
7. Elssamadisy,Amr（2013）， “ SAFe 是否已经破解了大规模采用敏捷的难题? ”, InfoQ。
8. Hundermark Peter （2014）,“更好的做 Scrum”， v3.02, ScrumSense – 不久就会在 InfoQ 上免费下载。
9. Larmann, Craig 和 Vodde, Bas （2010），精益和敏捷开发大型应用指南，Addison-Wesley。
10. Larman, Craig 和 Winn, Matt（2014），“ J.P. 摩根运用 LeSS 框架实施大规模敏捷”， InfoQ.
11. Leopold, Klaus 和 Kaltenecker, Siegfried（2012）， D_er IT__ 的看板 __,_ Carl Hanser Verlag. （英文版本将在 2015 年出版)
12. Luhmann, Niklas，（2011）， 组织和决策（第三版），VS Verlag。
13. Kaltenecker, Siegfried et al.（2011），“‘成功的敏捷领导者’执行研究汇总’”，敏捷项目管理平台。
14. Königswieser, Roswita 和 Exner, Alexander （2008），系统干预，（第九版），Schäffer Poeschel Verlag。
15. Sliger, Michel 和 Broderick, Stacia（2008），软件项目经理通往敏捷的桥梁 _,_ Addison-Wesley.
16. Spielhofer, Thomas （2011），“敏捷需求管理省事了，不是吗？”，敏捷项目管理平台。
17. Spielhofer, Thomas and Kaltenecker, Siegfried （2012），“敏捷领导力模型”，敏捷项目管理平台。
18. Walton, Helen (2014)，“敏捷组织：准备好革命了吗？”， InfoQ。

查看英文原文： More Than LeSS

感谢邵思华对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。