第01课：敏捷教练和 ScrumMaster 基本功四部曲（iPad 版）

概述

敏捷教练是一个职业。Scrum Master 和敏捷教练是同一职业的不同阶段。当一个人能带好一个 Scrum 团队时，他是一个 Scrum Master。当他能带各种不同类型的团队，并持续追求更好，他就是一个敏捷教练。

Scrum Master 职责的范围和边界相对确定，敏捷教练职责的范围和边界相对不确定。但从学习的角度，他们所需要的基本功是一致的。本课程中对这两个角色，在大多数时候不太区分。鉴于这两个角色既有相似处又有区别，大家在使用时对这两个名称的理解上又有变异，所以课程的名称中就把这两个名称并称，以求相对准确地表达这个课程所要服务的角色。就算是您所采用的敏捷方法不是 Scrum，依然可以从本课程中受益。

如同任何其他职业，敏捷教练有它的技能，也需要并且能够通过练习达到精通。我们可以通过四部曲的结构理解敏捷教练这个职业及其技能：

• 目的：任何一个职业，都有它存在的目的。这个目的包括职业产生的背景，工作的环境，以及所承担的职责。
• 储备：即敏捷教练所必备的基础知识。
• 技巧：即如何运用基础知识履行职责。
• 实战：即在一个典型完整的工作周期中，如何利用储备和技巧取得成功。

本章会介绍：

• 敏捷教练这个职业产生的背景
• 敏捷教练的工作环境
• 敏捷教练的职责
• 体系化的参考书目

敏捷教练职业产生背景

“追求更好”旅途的守护者

我们从敏捷的历史来看一下，敏捷教练这个角色是如何诞生的、这个角色对组织意味着什么。

敏捷方式可以追溯到1620年弗朗西斯·培根（Francis Bacon）科学方法的发源时期。更合理一点的起点可能是在20世纪30年代，那时候贝尔实验室的物理学家和统计学家沃特·阿曼德·休哈特（Walter A. Shewhart）开始使用计划-执行-学习-调整（PDSA）循环对产品和过程进行改善。

休哈特把这种反复渐进的开发过程教给了他的学员戴明（W.Edwards Deming），后者在二次大战后的日本大量使用了该方法。戴明将 PDSA 改造为 PDCA。丰田公司雇用了戴明来培训公司中数百名经理，并在他的经验之上创立了著名的丰田生产体系——这也是如今精益思想的最初由来。这种反复渐进的方式对于20世纪50年代的 X-15 超音速飞机的制造也是贡献巨大。

丰田模式的关键，以及使丰田有杰出表现的原因并不是任何个别要素，而是一个由各要素组成的 4P 体系：

• 长期理念（philosophy）：重视着眼于长期的思维，公司高层注重为顾客及社会创造与提升价值，这个目的主导了该公司的长期方法——建立学习型组织，投资于人员、产品与工厂，以及绝不松懈地坚持质量，以适应环境的变迁，成为高效的组织。

• 正确的流程（process）：正确的流程方能产生优异成果，流程是以低成本，高安全性与高昂的士气达成最佳质量的关键。

• 借助员工与合作伙伴（people and partner）的发展，为组织创造价值：丰田公司管理层的看法是，他们打造的是“人”，不是汽车。尊重员工的智慧和能力，并不断激励他们做得更好。

• 持续解决根本问题（problems）是组织型学习的驱动力：丰田模式的最高境界是组织型学习，丰田的持续学习制度重心在于辨识问题的根源，并预防问题的发生，持续改善。

此体系必须每天以贯彻一致的态度实行，而非只是一阵旋风。这个体系成功的秘诀是，经理即教练。培养深谙公司理念的领袖，使他们能教导其他员工。这是我们今天思考敏捷教练职责的最重要参照物。丰田的 4P 模式，也能帮助我们从根本上去思考什么是敏捷。

大野耐一是将丰田生产方式体系化的重要人物。大野耐一退休后，与其弟子创建了 NPS（New Production System），为其他企业服务。精益教练诞生，教练与经理分离。这也预示着在今天敏捷教练和管理者通常是分离的职位。

Scrum 的另一根植于日本的基础，是1986年野中郁次郎和竹内弘高在哈佛商业评论上发表的名为《新的新产品开发游戏》的文章。通过研究那些比竞争者更快发布新产品的制造商们，比如富士-施乐的复印机，本田的摩托车引擎，佳能的照相机，定义了以团队为基础的新的产品设计和研发过程。这种过程不是通常在产品开发中的“接力赛”——一组专家完成产品部分功能并将项目传递到下一组专家手中。这种方式被野中郁次郎和竹内弘高称作为“橄榄球”方式，“团队试图作为一个整体完成所有任务，将球传来传去。”

在1993年，Jeff Sutherland 面临一项似乎是不可能完成的挑战：Easel 是一家软件公司，需要在半年之内开发一款新产品来替代它的传统产品。Jeff Sutherland 通晓很多方法，比如快速应用程序研发，面向对象设计，PDSA 循环，专案工作等等。他希望在公司总部建立一个类似于专案工作的文化氛围，将组织分割和合并的好处结合起来。他开始学习任何和提高组织效率相关的知识。通过阅读上百篇研究报告和顶尖的产品管理专家面谈，他脑海中逐渐有了一些有煽动力的想法。

这中间有一个想法来自于贝尔实验室的关于 Borland Quattro Pro 团队的文章。该文章主张，每天短的团队会议能显著增加团队效率。而 Jeff Sutherland 的核心概念则来自于竹内弘高和野中郁次郎的“橄榄球”方式，虽然该方法更关注制造过程而不是软件开发过程。通过借鉴哈佛商业评论文章中的关键想法和进行一些特别的试验，Jeff Sutherland 创建了一种新的软件开发方法，归功于橄榄球带来的灵感，Sutherland 将这种方法称为“争球”（Scrum）。Scrum 方式最后确保了他准时完成了似乎不可能的任务，也没有超出预算，程序漏洞比之前版本还要少很多。Sutherland 随后就长时间和 Ken Schwaber 对该方法进行长期研究，并在1995年两人首次在公众面前发布 Scrum 的方法。

在2001年，17位自称“有组织的无政府主义者”在美国犹他州的雪鸟滑雪场会面，分享他们的想法。Jeff Sutherland 和其它 Scrum 的先驱也在其中。参与者们分享了互相竞争的几种方式：极限编程（XP）、水晶方法、自适应软件开发（ASD）、特性驱动开发（FDD）、动态系统开发方法（DSDM）。所有这些方式都是“轻量版”的框架，因为这些方法使用更少、更简单的规则来适应快速变化的环境。不少与会者都觉得“轻量”这个术语挺适用的。

虽然与会者不能在方法上达成一致，但是他们还是为这个运动取了个名字：敏捷。这个词是一位参与者提出的，他当时正在读《敏捷竞争者和虚拟组织：给客户更多的策略》一书。书中列举了100家公司的例子——包括 ABB， 联邦快递，波音，博士和哈雷戴维森，这些公司正在创建适应动荡市场的新方法。有了这个名字，参与者达成一致，发布了“敏捷软件开发宣言”，该宣言中突出了每个人都同意的4个关键价值。稍后在会议中，以及之后的几个月中，他们发展了12个原则，被称为“敏捷宣言背后的原则”。 从2001年开始，所有的开发框架，以及与之匹配的价值观和原则就被称作为敏捷技术。

同时，敏捷方法继续演化。在20世纪80年代后期和90年代前期，MIT 的研究学者们开始研究日本的制造体系，特别是丰田生产体系。他们借用了名词“精益”来描述改善效率的这套体系，包括消除浪费（muda)， 减少波动（mura）和降低负荷（muri）。虽然精益方法并没有在雪鸟会议上被表述成敏捷方法，但是精益和看板软件开发系统在后来被并入敏捷系统。在开始时候，一些纯粹的敏捷主义者拒绝承认精益方法。 但是精益宣传该方法能关注客户协作，最终更多的敏捷践行者开始接受精益，看板，还有混合方法（比如 Scrumban 和 Lean scrum），作为敏捷价值和原则合法的应用。

这些新方法论的创始人们是精通技术的管理者，和管理者中的思想者。敏捷宣言的17位创始人，是敏捷思想的传道者，可以被认为是最早的敏捷教练。他们所创造的这些方法的本质，不是一些死板的规定，而是在追求“更好”的旅途中，作为承载“更好”的载体。这些方法论的落地，以及作为这些方法论内在精神的追求“更好”，不会自动发生。

一种可能的逻辑是，由管理者来承担落实新方法论的责任。管理者可以转型为教练，重拾作为精益鼻祖的丰田的精神。对于管理者无法承担教练职责但又想追随敏捷潮流的组织，则需要专职的敏捷教练。

敏捷教练工作的环境

守破离的概念来自日本，大致可以理解为遵守、突破和脱离。这个概念在敏捷界被广泛运用，含义也会有所变迁。下面这个关于组织所处阶段的守破离，来自于 Scrum 之父 Jeff Sutherland。

组织的守的状态

• CEO 没有敏捷思维。以命令和控制的文化为主。
• 依据传统的管理层级结构产生项目组。
• 即使采用敏捷，也是跟风，流于形式，无法深入。
• 在这种状态之下的效率提升通常只能做到20%~30%

组织的破的状态

• CEO 改变管理者的角色。教练和支持的文化浮现。
• 管理者教导团队自组织和自管理。管理者成为领导者。
• 领导者为团队提供有挑战的排好优先级的目标。
• 消除组织债，创建可行的商业和组织计划，提供团队所需的资源。
• 识别和移除障碍，消除浪费和技术债，确保团队速率最大化。
• 确保产品负责人对交付的价值负责。
• 确保 Scrum Master 对流程改善和团队快乐负责。
• 确保团队对质量提升和技术债修复负责。
• 团队依据排好优先级的产品列表自我形成。
• 领导者在组织内驱动不同技能的虚拟实践社区，为组织提供能力建设。
• 领导者按需重构组织。
• 在生产力方面会取得200%~400%的提升。
• 示例公司：Spotify，SAP，Salesforce，Microsoft。

组织的离的状态

• 层级仍然存在，但主要是为技能培养服务。
• 团队自组织负责产品方向和组织重构。
• 领导者支持团队所需的技能。
• 群游使组织在压力之下更强壮。
• 产生500%~1000%的生产力提升。
• 示例公司：Valve，Zappos，Morning Star，Gore，Grindr。

这三种状态，跟建国方略中的军政、训政和宪政暗合，可参照理解。

瓶颈通常在瓶子的上部，一个公司最大的瓶颈是 CEO。作为一个敏捷教练，针对所处的组织形态，可以采取运用敏捷基本功加上变通的方法来开展工作。

至于团队，也会有三种形态。

无组织团队

• 从团队绩效方面看，是相对不高和不稳定的，时好时坏。迭代计划预测的靠谱度较差，速度也不高。
• 从团队动态和互动看，呈现出一种各自为政的状态，沟通不畅，合作困难。从会议看，目的不明确，流程不清晰，效率低，参与者沮丧。

自运转团队

• 从团队绩效看，呈现出相对稳定的状态，迭代目标承诺靠谱度较好，迭代目标基本能完成。
• 从团队动态和互动看，团队成员目标一致，有良好的沟通合作，在各项活动中，团队成员都能主动参与。会议的目的和流程清晰，没有 Scrum Master 的情况下，会议也能按照打磨好的流程自动运转起来。

自组织团队

• 从团队绩效看，在稳定的基础上，呈现出阶段性的持续提升，生产率和质量不断提高。
• 从团队动态和互动看，团队有更多高质量的互动，团队除了关心共同的目标，还关心持续改善和从根本上解决问题。呈现出上文中所说的丰田 4P 的一些特征。

敏捷教练所要做的，就是把团队从无组织状态带到自运转状态，再进一步带到自组织状态。这个使命的履行，本课程中敏捷教练和 ScrumMaster 的基本功可以帮到您。

敏捷教练的职责：流程与人两手抓

在设计本课程之前，针对一部分敏捷从业人员和经历者做了一个小调查，想了解他们对 Scrum Master 职责的理解。这个调查虽然样本较小，不具备统计意义，但依然可以帮助我们了解跟我们处在同样角色的人对这个问题怎么看。调查结果如下：

• 精通管理规则，精通业务梳理，极强的沟通协作能力，技术熟练，懂业务管理。
• 敏捷教练确保 Scrum 被正确的运用和贯彻，同时保护团队和引导新的想法落地。
• Scrum Master 是牧羊犬的作用，让团队在一个迭代中不受打扰，同时他应该对敏捷的流程、理念有深入的了解，具有较强的管理能力。

• 引导团队进行效率的提升，通过各种工具的导入，来实现项目目标。但是，究竟是否要像传统团队一样，也要引导团队进行项目交付，并解决依赖问题，这个要商榷。
• 保证团队资源，保证各个角色及职责协作，解决团队开发中的障碍，协调解决沟通问题，保证开发过程按计划进行。
• 指导 Scrum 小组成员理解为什么、知道如何参与 Scrum 实践的每一个环节，把控好 Scrum 实践的产出，为整个小组的 Scrum 迭代/计划结果负责。
• 基于对 Scrum 角色的了解，以及对项目和资源的认识，帮助 stakeholder 决定最佳的按照 Agile 路线来实施项目的教练。
• 培训和指导团队践行敏捷实践；关注项目的度量数据，及时带领团队调整，加速或稳步前进；关注成员的状态，激励督促团队前进；带领和辅导团队按照敏捷和精益的方式做事，打造优秀自组织团队。
• 牧羊犬守护团队，流程；教练，培训，引导团队，PO，相关人知识，技能；推动过程改进，促进变革；提升团队，组织效能。
• 在敏捷团队中推进敏捷开发模式和流程，是团队的组织者，保证团队资源，协调内外部关系，解决出现的问题。
• 帮助团队进行敏捷实践落地，梳理流程，减少外部干扰，鼓舞士气，提高团队作战能力。提高工作效率。
• 传播敏捷思想，指导团队，指导 PO，组织敏捷会议，排除团队干扰。
• 指导团队按 Scrum 方式运转，传播 Scrum 思想，指导敏捷实践，提高效率。
• 保证团队资源完全可被利用并且全部是高产出的。保证各个角色及职责的良好协作。解决团队开发中的障碍。做为团队和外部的接口，屏蔽外界对团队成员的干扰。保证开发过程按计划进行，组织 Daily Scrum，Sprint Review and Sprint Planning meetings。
• Scrum Master 是 Sprint 的负责人，Sprint 做得好不好的终责者。负责计划，执行 Sprint，并使团队团结及有自主创造能力。
• 搭建 team 架构，分配各个角色成员，开展 scrum 常规的事项，并让敏捷的理念深入人心。帮助团队更好的按照 Scrum 框架有效的运行，对团队遇到的问题和障碍提供帮助，协助扫清研发过程中的障碍，打造高效能的团队。
• 组织项目团队，承诺项目开发，回顾项目过程，总结项目经验教训，组织每日站会，制定 Sprint 计划。
• Facilitate everything and eventually retire，留下一个自组织团队，悄然离去，深藏功与名。激励团队，coach，team lead，life tutor。
• Scrum Master 应该是作为团队初步接触敏捷时作为流程与套路教授和规范。在团队逐步成熟后，Scrum Master 的职责可以旁落，而专职 Scrum Master 可以取消。

那么敏捷教练的职责到底是什么呢？

《敏捷教练》一书的作者之一，瑞秋·戴维斯（Rachel Davies）对敏捷教练的观点：

概括地说，敏捷教练帮助团队在工作中应用敏捷实践，从而帮助团队发展的更健壮。接受这些变化需要时间，所以没法通过“点到即止”的方法立即让它们生效。你需要与团队长时间呆在一起，并帮他们，让他们更加关注工作流程、关注如何更有效地协作。你对团队的目标是在你离开后，让他们能“自我指导”并且擅长应用敏捷。这样不会限制敏捷教练向组织引进敏捷，以及建立新敏捷团队。

Coaching Agile Teams 的作者 Lyssa Adkins 对敏捷教练的观点：

敏捷教练确实非常重要，因为现在有许多人在运用一堆蹩脚的敏捷工作方式。即使运用了，它们只是更快地产出了平庸的结果，我知道，那并不是他们运用所谓“敏捷”工作方式的主要意图。我认为教练是帮助团队取得惊人成果所不可或缺的组成部分，因为所有的成果都是人互相交互所产生的。敏捷框架中没有说明如何处理人与人交互的部分。为了使敏捷框架良好运作，它当然会提供可让其正常运行的结构和容器。但是在敏捷框架之外，还有很多事情要做，还有很多东西需要带给团队，针对不同的规则，需要给团队很多建议——如冲突管理、敏捷促进、教导及指引人、专业指导等等。

本文给出的敏捷教练的职责定义是：

• 贯彻一种工作方式，包括精益、敏捷和系统思考。
• 打造自组织团队，特别是要面对人（包括自我与他人）这个最复杂的实体。
• 以此来消除浪费，增加价值，达到组织的目标。

要履行这些职责，需要理解敏捷，这是本课程基本功的储备部分；要能够在组织中用敏捷影响他人，这是基本功中技能的部分；要体会真实环境中的敏捷运用，这是本课程基本功中的实战部分。

体系化的参考书目

敏捷是敏捷教练的代码

敏捷的历史是一场不断追求更好的历史，在这个过程中，先行者们为我们留下了众多可供参考和让我们无须重新发明轮子的书籍。

本节以类库、框架、架构，和编辑、编译、链接、运行的视角解析敏捷和敏捷教练，以及如何运用先行者们留下的书籍。

敏捷是一种代码，2001年2月，17人在美国犹他州的雪鸟滑雪场，解码和发明了这门语言，并贡献了敏捷基础类库。

敏捷基础类库

• Kent Beck 等的《敏捷宣言》（Manifesto for Agile Software Development）

敏捷框架类库

• The Scrum Guide（Jeff Sutherland & Ken Schwaber）
• 《解析极限编程：拥抱变化》（Embrace Change: Extreme Programming Explained ，Kent Beck）
• 《用户故事与敏捷方法》（User Story Applied in Agile Software Development，Mike Cohn）
• 《敏捷软件开发实践：估算与规划》（Agile Estimation and Planning）
• 《看板方法》（Kanban，David Anderson）
• Lean Software Development（Mary Poppendieck）
• Large Scale Scrum（Craig Larman）
• SAFe（Dean Leffingwell）

敏捷扩展类库

• 《新的新产品开发游戏》《场理论》（野中郁次郎和竹内弘高）
• 《硝烟中的 Scrum 和 XP 》（Scrum and XP from the trenches，Henrik Kniberg）
• 《Scrum 精髓》（Essential Scrum，Kenny Rubin ）
• 《用户故事地图》（User Story Mapping，Jeff Patton）
• 《Scrum 实战：故事、模型与成功秘诀》（Scrum Field Guide，Mitch Lacey）
• 《Scrum 敏捷项目管理》（Agile Project Management with Scrum，Ken Schwaber）
• 《Scrum 敏捷软件开发》（Succeeding with Agile Using Scrum，Mike Cohn ）
• 《精益创业》（Lean Startup，Eric Ries ）
• Discover to Deliver（Ellen Gottesdiener ）
• 《持续交付》（Continuous Delivery，Jezz Humble ）
• Design Sprint
• 《领导职责的十四条》（戴明）
• Retrospective: From Good Team to Great Team
• 《腾讯之道》（艾永亮）
• 《精益产品开发：原则、方法与实施》（何勉）

精益类库

• 《丰田生产方式》《大野耐一的现场管理》（大野耐一）
• 《以工业工程的视角考察丰田生产方式》（新乡重夫）
• 《改变世界的机器》（The Machine That Changed The World，James Womack）
• 《精益思想》（Lean Thinking）
• 《丰田模式》系列（Toyota Way of Working，Jeffery Liker）
• 《学习型管理》（A3 报告，Manage to Learn，John Shook ）
• 《学习观察》（价值流图，Learning to See）

引导与心理学类库

• NLP 神经语言程式
• 《世界咖啡》
• 《六顶思考帽》

管理与变革类库

• 《瞬变》（Switch，Chip & Dan Heath）
• Management 3.0（Jurgen Appelo ）
• How to Change the World: Change Management 3.0（Jurgen Appelo ）
• 《驱动力》（Drive，Daniel Pink ）
• 《重新定义公司》（How Google Works）

敏捷模式类库

• Scrum 本身就是个模式
• 《用户故事地图》也是模式
• Fearless Change， More Fearless Change（Linda Rising）
• 本课程中的 Scrum 子模式，例如故事泳道、一人天任务、随机一分钟项目经理 敏捷教练方法类库
• Coaching Agile Teams（Lyssa Adkins）

修身类库

• 《大学》《中庸》《论语》《孟子》
• 《王阳明全集》
• 《心经》《金刚经》
• 《圣经》
• 《超越自卑》
• 《人生五大问题》
• 《高效能人士的七个习惯》
• 《红与黑》
• 《基督山伯爵》
• 《悲惨世界》
• 《百年孤独》
• 《活着》
• 《常识》

而在设计敏捷工作方法的架构时，可以基于上面提到的敏捷框架中的一个或多个。可以使用的思维线索有：

• 软件开发的阶段：概念，机会，策略，需求，方案，计划，实施，验证，部署，维护，退役。
• PDCA
• 5W2H

在做敏捷工作方法的实施时，第一步是需求：

• 与关键人员交流，了解问题与目标
• 这一步要放下敏捷的代码，倾听了解问题与目标本身。

第二步是制定解决方案：

• 根据现状，参考敏捷方法，制定关键举措。
• 使用类库和框架，制定架构。

敏捷工作方法的编码就是用上面的各种类库和框架，生成适合组织和团队的可执行的敏捷方法，包括架构和详细实现。执行的环境是团队中每个人的大脑。

编辑，是把方案细化的过程：

• 把敏捷方法动作化，做好剧本。无剧本，不操作。
• 为每一次谈话做好充分准备。

编译，是与团队中所有人交流的过程，使所有人理解敏捷方法：

• 可以是讨论，针对某个具体变化的方案与执行。
• 可以是培训，介绍整体或某个环节的工作方法。
• 可以是一对一交流，让方法切实而不只是形式上发生。

链接，是处理与现状和与已有工作方法的冲突：

• 分析问题，解决问题。
• 调整“代码”

运行，是新方法的执行：

• 落实每一个动作，并检查调整。

编辑、编译、链接、运行会反复多次进行，跟程序员写代码没有区别。

敏捷教练和 ScrumMaster 的基本功，来自于众多大师的智慧和作者的实践，为我们提供了扩展的大脑。该体系已为您整理好，是按下继续前进按钮的时候了。