企业敏捷转型（20220609对话Jeff Sutherland笔记）

引子

世界变得越来越复杂，需要敏捷进行更快速的反应。

金句摘抄

• 敏捷宣言是个有历史意义的文件，是大变革的宣言，是广泛使用的产品，不是软件，不会有新版了。现阶段最主要的问题是如何实施敏捷。

• Ron Jeffries说，敏捷宣言的第二条，有关价值那条，最重要，我们真心如此（we     really mean it）：每个迭代结束，都是向最终用户交付价值。

• Scrum的本质（the thing about     scrum is to…）是让任何东西都可见！所有人都知道发生了什么、人都在哪里。

• Scrum可能始于软件开发，但它绝不是只能与软件开发挂钩。事实上，Scrum最重要和最有影响力的实施讲发生在软件之外。

• 告诉队员目标，而不是命令他们要做什么，这是对传统管理风格转变的最大挑战。

• 在敏捷组织中，我们希望牛人升官后，他们的技能还能继续发挥价值，不能让他没有时间做他擅长的东西了。

• 不要被惯例、老传统、老想法封印住了。（要有教练技能，去催化变革）

• 时代一直在变，硬件、软件互为师徒，完成轮换，现在是硬件的思维模式mindeset需要改变，硬件就是软件！

• scrum at scale，启动时要小，结果清晰，慢慢扩张

• 只有高层有正确的敏捷思维模式，敏捷才能持续下来，这需要十几年的时间（如微软）。

• 长期主义，持续的，环环相扣，长期思维，慢慢往那个方向靠。

• 中国管理团队参加Jeff的敏捷培训后，这些经理们讨论要创造自己的敏捷方法论，以便（提升敏捷的同时）继续微观管理和控制员工   （从Jeff的无可奈何的笑声中，国人应该了解这是多么犀利的批评、辛辣的讽刺、直击灵魂）。

• 中国最大的挑战，领导层是否有开放的态度，拥抱敏捷，绩效才能爆发。

• 让大家一起协作工作的能力，能让你的职业生涯无止境。

• 敏捷和scrum是福音，传教士的心态和精神，要多喊一喊。

• 利新易，破旧难，模块化先。

• 转型是组织变革、焦虑的同时心怀远方。

• Scrum的创立受到了Rodney     Brooks教授的iRobot自主机器人的启发，iRobot机器人使用反馈循环不断评估和响应其周围环境的方式，与预编程、命令与控制的思路绝然相反，iRobot的方法与Jeff关于迭代式开发、频繁测试和持续改进的思想相吻合。

目录

- 引子

- 金句摘抄 

- 暖场开胃菜

    - 重写敏捷宣言？- 

    - 敏捷宣言哪一条可以改？

    - 线上工作后，如何影响scrum？ 

    - Scrum master的成长之路

    - 如何估算项目

    - 非软件行业使用scrum在增加么？

- 国内大神们开场 

- 敏捷领导力主题

- 创新的速度是成功的首要因素

- 敏捷之后，管理到领导的巨大转变

- 敏捷要点 

- 改变工作内容

- Spotify的分会模型

- 别让敏捷转型失败 

- 启发敏捷的文学作品

    - 问题：30%的同事不愿意被改变

    - 问题：短期应急和长期战略

    - 问题：当事情出错时，会责怪别人

    - 问题：快速出其不意，保证成功 

- 践行SCRUM价值观 

- 嘉宾和Jeff互动环节

    - Sw & hw在应用精益、vsm的区别

    - 实施大规模敏捷的挑战

    - 中国本地化实施SCRUM的挑战

    - 竖井如何改成敏捷、跨职能团队

    - 敏捷教练，内部培养教练，进行转型

    - scrum应用，敏捷企业

- 嘉宾分享感受

- 完整笔记链接

*方框内容为chatGPT提供的辅助背景信息，是未经验证的信息

暖场开胃菜

*可能为2020左右的视频，也挺经典的，惜未找到完整回放

如果今天写敏捷宣言，你希望让那些人来写？

敏捷宣言的所有人，大部分人至今都是leading thinkers，牛人，当时在屋子里面写的8个人都非常关键。

如果今天要写敏捷宣言，要加什么新人呢？你们知道得比我更清楚。但是，今天的主要问题是如何实施敏捷！

30%的scrum团队、50%的敏捷转型项目没有成功，都是实施的问题。今天更需要有敏捷实战经验人才，市面上有很多敏捷方法，很多不管用。

敏捷宣言（Agile Manifesto）的原文如下：

We are uncovering  better ways of developing software by doing it and helping others do it.  Through this work we have come to value:

Individuals and  interactions over processes and tools

Working software  over comprehensive documentation

Customer  collaboration over contract negotiation

Responding to  change over following a plan

That is, while  there is value in the items on the right, we value the items on the left  more.

译文如下：

我们正在通过实践和帮助他人实践，探索开发软件的更好方式。在这个过程中，我们珍视以下价值：

个体和交互 胜过  流程和工具

可工作的软件  胜过 详尽的文档

客户合作 胜过  合同谈判

响应变化 胜过  遵循计划

也就是说，虽然右侧的条目也有其价值，但我们更珍视左侧的价值。

敏捷宣言的12原则

1. Our highest priority is to satisfy the customer   through early and continuous delivery of valuable software.        我们的最高优先级是通过及早、持续地交付有价值的软件来满足客户需求。

2. Welcome changing requirements, even late in   development. Agile processes harness change for the customer's competitive advantage. 欢迎变化的需求，即使在开发后期。敏捷过程利用变化为客户创造竞争优势。

3. Deliver working software frequently, with a     preference to the shorter timescale. 频繁地交付可工作的软件，尤其倾向于更短的时间表。

4. Business people and developers must work together     daily throughout the project. 商业人员和开发人员必须在整个项目中每天一起工作。

5. Build projects around motivated individuals. Give  them the environment and support they need, and trust them to get the       job done. 以有动力的个人为中心建立项目。提供他们所需的环境和支持，并信任他们完成工作。

6. The most efficient and effective method of conveying    information to and within a development team is face-to-face  conversation. 向开发团队传达信息的最有效方法是面对面的交流。

7. Working software is the primary measure of progress.        可工作的软件是进展的主要衡量标准。

8. Agile processes promote sustainable development. The     sponsors, developers, and users should be able to maintain a constant     pace indefinitely. 敏捷过程促进可持续发展。赞助商、开发人员和用户应该能够无限期地保持一个恒定的步伐。

9. Continuous attention to technical excellence and good  design enhances agility. 持续关注技术卓越和良好的设计有助于提高敏捷性。

10. Simplicity – the art of maximizing the amount of work     not done – is essential. 简洁 - 最大化未完成工作量的艺术 - 是必要的。

11. The best architectures, requirements, and designs emerge from self-organizing teams. 最好的架构、需求和设计来自于自组织团队的努力。

12. At regular intervals, the team reflects on how to    become more effective, then tunes and adjusts its behavior accordingly.        团队定期反思如何变得更有效，并相应地调整行为。

敏捷宣言作者

1. Kent        Beck: 美国软件工程师，Extreme Programming (XP)和Test Driven Development        (TDD)的创始人。

2. Mike Beedle:        秘鲁计算机科学家和企业家，敏捷开发先驱之一，是eXtreme Programming（XP）的创始人之一，于2018年去世。

3. Arie van        Bennekum: 荷兰软件专家和顾问，热衷于敏捷开发和Scrum方法。

4. Alistair        Cockburn: 英国计算机科学家和作家，提出了适应性软件开发的概念，也是Crystal方法的创始人。

5. Ward Cunningham:        美国计算机程序员，第一个维基的发明者，对面向对象编程做出了贡献。

6. Martin Fowler:        英国软件开发人员，作家，精通重构、持续集成和敏捷方法。

7. James Grenning:        美国软件工程师和顾问，专注于敏捷开发、测试驱动开发和嵌入式系统。

8. Jim Highsmith:        美国软件工程师、作家，精通敏捷方法和自适应软件开发。

9. Andrew Hunt:        加拿大软件开发人员和作者，《实用程序员》的合著者，精通敏捷开发、软件设计模式和TDD。

10. Ron Jeffries:        美国软件开发人员和顾问，Extreme Programming (XP)的共同创始人，精通敏捷方法。

11. Jon Kern:        美国软件工程师和顾问，精通敏捷开发和Extreme Programming (XP)。

12. Brian Marick:        美国软件工程师和顾问，精通敏捷开发、TDD和XP。

13. Robert C.        Martin: 美国软件工程师、作家，精通敏捷软件开发、软件设计模式和SOLID编程原则。

14. Steve Mellor:        英国计算机科学家和软件工程师，提出了面向对象分析和设计（OOAD）的概念。

15. Ken Schwaber:        美国软件工程师和顾问，Scrum方法的创始人之一。

16. Jeff Sutherland:        美国软件工程师和顾问，Scrum方法的创始人之一。【宗师泰斗】

17. Dave Thomas:        加拿大软件工程师和作者，《Pragmatic Programmer》和《Programming        Elixir》的合着者，也是Agile联盟的创始人之一。

敏捷宣言哪一条可以改？

2011年，敏捷宣言的团队再次碰面，近千名听众，最后听众提出上述问题。

Ron Jeffries说，第二条有关价值最重要，我们真心如此：每个迭代结束，都是向最终用户交付价值。

Jeff： 敏捷宣言是个有历史意义的文件，是大变革的宣言，是广泛使用的产品，不是软件，不会有新版了。

线上工作后，如何影响scrum？

要让人真的连接，并能协作工作。疫情前scrum就有支持远程的案例，疫情期间表现更加明显。

• 适用于任意规模，上千，2000-3000人

• 适用于任何行业，学校、儿童也在用

• 适用于远程工作，全球化、分布式，例如，有个团队，分布于加拿大、美国、俄罗斯，人员翻倍，效率不止翻倍。每个团队都有跨大洲的成员，没有单纯的本地团队。

scrum的本质（the thing about scrum is to…）是让任何东西都可见！所有人都知道发生了什么、人都在哪里。

甘特图有点用，但是不能起到协调分散在各处的人的作用。

2007年开始有很多提供“虚拟的办公室”的软件，每个人都在一个房间里，谁和谁在合作也看得见，你可以进他的“房间”，别人可以看到你和谁在一个“房间”讨论，他们也可以加入。

工具赋能远程工作，zoom比十年前的电话会议好非常多

游戏公司的老板：远程团队有时比都在现场更有效率，不会像在现场那样被频繁打断。就剩时差问题了。

Scrum master的成长之路

让初阶的人和高阶人在一起，受到培训。

慢慢发展到没有经理，只有sm处理所有问题，对sm要求会更高。

2016年培训变了很多。一家丰田关联企业找上门要培训服务：

• scrum的基本培训是不够的，因为sm没有得到精益领域的基本培训

• sm要知道精益，我们在scrum培训中增加了消除浪费的工具，

•     vsm，流程效率，根因分析，A3分析，基本的工具都要会用

2006年开始为一家资本公司服务，持续服务了十几年：

• 希望所有投资的公司都使用scrum

• 培训后，所有人都懂scrum，但不知道如何用scrum来一起协同工作

• 去年的书很重要，总结十几年的经验，共有8-10个高效团队的模式

• 没人仅在一个scrum团队工作，像结对编程一样去和人打交道，走出去，取得经验，交付结果。

第一步是知识

第二步要经验，知道该怎么做，要走出去，和他人一起工作。有这个想法，成为sm不难。

驾照知识第一步，新手需要知道基本的东西。新手要上路，变得有经验，而不是造成很多车祸。

在《A Scrum  Book: The Spirit of the  Game》中，"pattern"指的是一种可重用的解决方案，可以用于解决常见的软件开发问题。Jeff  Sutherland引入"pattern"的概念是为了帮助读者更好地应用Scrum框架，并提供一些特定领域的实践指南和最佳实践。

Scrum模式旨在描述Scrum框架的各个方面，并提供在实践中使用Scrum的具体建议和技巧。这些模式通常包括一个问题、相应的上下文和解决方案，以及如何实施解决方案的步骤。通过这些模式，团队可以更好地理解Scrum框架的核心原则，同时能够更好地应用它们来解决实际的软件开发问题。

总之，Sutherland引入"pattern"的概念是为了帮助团队更好地应用Scrum框架，并提供针对不同领域和场景的实践指南和最佳实践。

在《A Scrum  Book: The Spirit of the Game》中，有一些被认为是Scrum框架核心模式的模式：

• Sprint模式：用于规划、实施和评审Sprint。

• Backlog模式：用于管理产品Backlog，包括对Backlog进行分类、排序和估算等。

• Daily Scrum模式：用于在每天的站立会议上有效地协作。

• Sprint       Review模式：用于组织Sprint评审会议以获取有价值的反馈。

• Sprint       Retrospective模式：用于组织团队回顾会议以改进过程。

• Release模式：用于管理发布，包括如何规划发布、准备发布和执行发布等。

这些模式被视为Scrum框架的核心模式，它们涵盖了Scrum框架的各个方面，从规划到实施，从管理到改进。通过这些模式，团队可以更好地理解Scrum框架的核心原则，并将它们应用于软件开发过程中，以提高生产力和质量。

如何估算项目

要获得支持，就要明确估算。

现在有好的估算培训，有历史数据，一两个小时就能估算一个大项目，不需要一两周时间

团队要稳定，要有稳定数据。团队变化太大，估算没有用。

非软件行业使用scrum在增加么？

2006年jeff提出scrum时，就想着把scrum推广到软件行业以外的领域，绝大部分jeff的生意都不是软件行业，而是石油、硬件、汽车、火箭，scrum人力，scrum at scale(投资公司要的)

投资公司要求所有被投资的公司都要scrum，软件工程师很容易，他们提效很快，问题是公司的其他人要做到scrum

可以把软件相关的元素从srum中拿出来（让scrum更通用）

Scrum.org问卷调查: 很多人的业务不是软件业的客户，超过软件本身。scrum的主要市场不再是软件。

Jeff的老婆有杰作，2008写了篇IEEE论文，把scrum用在教堂，教堂组织实现敏捷转型了。往内部小的说，也可以是销售、营销等敏捷转型。

国内大神们开场

如何脱颖而出而非随波逐流

适者生存和持续进化的秘密是什么

如何掌握发展的主动权

商业大师、宗师泰斗有什么新的洞察、心得

【思】希腊神话主神十来个，国内敏捷的主神，基本上也到齐了？了解过几位，是够thinker这个级别的。

 敏捷领导力主题

我认为速度是决定任何公司竞争力的根本因素，特别是当涉及到任何技术时，创新的速度根本上决定了哪些公司会成功。

中国发展不仅仅是速度，而且是每天都有满足大众的新特性推出。

amazon每秒上线一个新特性

特斯拉每周提供20个新的软件、硬件功能，比传统汽车制造的更新速度快1000倍

2020年上半年，有3600多家非敏捷企业破产。拥抱scrum的上市公司、创新速度快的企业，在疫情期间，股票也会大涨。

创新的速度是成功的首要因素

敏捷转型，应用scrum at scale，可以发现公司有哪些地方需要agile，往往不是IT，而是供应链的其他地方（采购、合同、运输），

G.Tome, John Deere：Scrum可能始于软件开发，但它绝不是只能与软件开发挂钩。事实上，scrum最重要和最有影响力的实施讲发生在软件之外。

这些逆流而上、振奋人心的故事，背后是什么领导力在支持呢？

敏捷之后，管理到领导的巨大转变

• 跟上团队的步伐，团队移动很快

• 学会放手

• 不再微观管理

• 沟通目标和愿景，而不是告诉人们做什么

• 询问需要什么帮忙

• 团队的职责增加了

敏捷要点

• 1 团队要小。最佳5人团队

• 7人就变慢了。10人团队更慢

• 团队越大，延迟和失败可能性更大

• 2 要有愿景和目标，才能自我管理

• 告诉目标？不是告诉他们要做什么，这对传统的管理风格转变的挑战是最大的

• 释放团队的能力，赋权团队

• 让每个人都是多能的

• 管理应该支持团队形成自组织的能力

• Bosh有个CEO，取消所有管理者的奖金，给团队发奖金

• 管理者是导致公司运作变慢的原因

• 管理者倾向于push自己的行动

• 其实管理者要为整体的revenue负责。

• 3 Tesla、马斯克强调要在现场，观察生产线。

• 了解团队的问题是什么，并清除团队自己无法清除的任何障碍。

• Musk大部分时间在生产线，理解工人，解决问题，离开办公室，才能看到真正的办公场所的问题，需要走动，需要观察。

• 4 提供远景，支持团队，千万不要微观管理

• 管理者是团队的一部分，他们需要为团队绩效负责

• 硅谷CISCO有1000个scrum团队

• 从数据看，没有一个SCRUM团队是在改善的，有1000个sm，但是sm没有做好工作。

• 绩效没改善，sm要替换。

• sm要好好培训，让他们发挥作用

• 培训后，再没有改善，sm就要负主责，替换掉

• sm要催化变更，让产品增值

• 5 80%的问题是系统造成的

• 根本的错误是什么？

• 80%的问题是系统造成的，高层更要意识到这点

• 80%的问题是高层设置、组织造成的，只有高层能解决这些问题，高层才能改变组织和行为。

• 有些公司非常注重绩效考核

• Jeff问：每周做绩效考核，可否在半年内绩效提升一倍，公司销售可否增加一倍，一般大家都不信能达成这个目标

• Jeff建议怎么做

• 组成团队，目标绩效翻倍，你们自己看要怎么做

• 管理层为团队提供各种支持

• 包括胜任的sm

• 团队要想办法怎么去做

• 管理者需要更多的时间，去考察团队的行为，看看团队的障碍在哪（block）

• 管理层大多数时间是绊脚石，要忍住瞎指挥的欲望

• 要专注于改变系统，使不良行为消失。

• 6 理解不可能通过增加个人业绩而使得团队绩效翻倍。

• 问管理层：绩效评估，对每个经理人进行单独的绩效考核，如果每周都做绩效考核，每周都改进两倍，6个月后公司绩效可否改善2倍？管理层一般回答不可行。

• 对敏捷团队：如何在6个月内改善2倍绩效？提供一切条件，给个好的sm，一般团队可以达成目标。帮助团队改善更加现实可行，一般能达成目标。

改变工作内容

管理者，或者任何人，都应该思考的问题

• 我最拿手的是什么？

• 要怎样才能为公司提供我的最大价值？

• 我怎样才能更快乐？工资更高？

• 如何指导更多的人，让他们成长得更好

• 【思】领悟了之后，要把自己的job description改掉

• CTO花了8%的时间在高管会议上，他喜欢的的写代码，他的job     description改成：

• 80%的时间与团队直接协作、工作

• 8%的时间去和高管开会

管理层、升职、奖励机制是问题的来源，这个需要改变。

• 牛人都会升官，升官了之后他就没有时间做他擅长的东西了

• 在敏捷组织中，我们希望牛人升官后，他们的技能还能继续发挥价值。

• 作为经理，你有模范的技能

• 这些技能非常宝贵，你可以在某个scrum的角色中做出贡献

• 在这些角色中体现scrum价值和仆人式领导

经理们如果只是指手画脚，那他存在的就只是增加了管理成本，而不能积极为客户创造价值。他们的其他技能可能会萎缩，使他们没有能力帮助发展他们的团队，从而影响到团队成员的工作热情和工作稳定性。

团队需要很多数据，需要发声，说出真相，公开沟通，openness，相互尊重，经理需要真的倾听，成员要有勇气说出真正的故事。只有这样，团队才能梳理清楚要做什么，才能去冒险，去试验，才能改变现状。

管理者的价值观要根本上改变，团队的绩效才有可能有根本的变化。

Spotify的分会模型

如果你是个专家，例如QA

• 你雇用、培训一些QA队员

• QA队员参加到多个自组织的scrum团队中

• 你为公司制定QA策略，计划

• 你让QA队员认可这些策略和计划

• QA队员在日常工作中，具体实施这些计划

• 日常工作中，你并不管理QA队员

• 质量不好，要质问QA专家（chapter lead）

• 你的质量改进计划在哪？要做哪些行动计划？

• 你不再对每天的危机进行微观管理，

• 你的哪些行动计划、规划真的得到了落实

微观管理、危机管理不是在领导团队进步，应该让团队自我管理

别让敏捷转型失败

MIT斯隆商学院：53%的转型会失败，转型失败中67%的公司会倒闭。

• 1 自组织，自我管理

• 集中的计划会破坏自组织

• BMW，每年年底疯狂花钱，保证明年有够多的预算。在中国肯定也这样！BMW觉得这种集中年度预算会导致30%的浪费。

• 需要做敏捷预算管理，这样就能节省30%了

• 老想法，被限制做了，被传统老想法封印了

• 命令与控制，会毁坏团队

• 中国人喜欢command and control

• 中国的敏捷团队也很多，有些公司消灭了微观管理，他们会很成功

• 小团队，只有一份job description

• Rocket mortgage原来一个团队里有15份jd

•  后面改为小团队，只有一份job description

• 大家都要学，具备多种能力，不行就转走

• 如果绩效没改善，sm就换掉，和球队教练一样

• 产品客户不喜欢，就换掉po

• 这样速度能提高8倍

• 管理层需要知道这些本质性的问题

• 德国电信，花6个月做个大计划是不对的，改成：

• 先讨论sprint1要做什么

• 每周、每个迭代，在分析要做什么更好

• 发生了新的情况，反思，改计划

• 要有清晰的愿景，但是这不需要6个月的时间去做计划

• 团队自己想办法

• 团队的表现，将是超过所有个人的总和

• 自组织团队的绩效会好太多，指数级的差别

• 2 没有单点控制

• iRobot的联合创始人，教授，做出了自学习、自组织的机器人

• MIT30年，通过大型机、大型数据库来造机器人，都失败了

• 只有传感器、没有数据库，根据传感器的实时数据响应

• 没有CPU，每个脚都是独立的处理器

• 脑子里有神经网络芯片，初始化是空白的

• 机器人一开始像团面条，30秒后慢慢地像小孩一样，3分钟会学习走路，之后可以跑

• Jeff问教授，类比

• 传统上，有大型项目，每个开发者都很慢

• Jeff提问，是否可以给开发人员简单的规则，他们自组织，可否在1周内形成形成高效团队

• 基于这个思想，就是SCRUM

• 3 跨学科团队

孤立的活动，缺乏透明度，将使其陷入困境

【思】隔绝自己，将自绝了未来，要勇敢走出去，和他人需求结合在一起，和各类不同的人员打交道，开放，透明

• 4 新兴做法

如果你无法移除障碍，就无法摆脱平庸的人【思】开辟新赛道，突变、创新，培育能发挥特长的环境，才能摆脱平庸的人。如柯文哲仙人掌语，仙人掌在热带也能长好，但是拼不过其他植物，在沙漠可以。

• 5 成果只能在实践中产生

经验性过程，需要监视和调整，需要批判性思维。【思】到底有哪些传统的做法不再有效？早点承认失败，改弦易辙，才是上策。

• 6 团队绩效大于个人综合

能在更短的时间内以更低的成本生产出更多的产品、具有更高的质量，更高的客户满意度，为客户和产品提供更好的产品。

Rodney  Brooks是机器人领域的领先专家之一，为自主机器人产品的开发做出了重大贡献。他的一个关键成就是iRobot的自主家用清洁机器人Roomba的开发。

Roomba的自主性是通过传感器、人工智能和高级算法的组合实现的。该机器人使用多种传感器，包括红外线传感器和碰撞传感器，以便在移动时检测障碍物并避免碰撞。

此外，Roomba的高级算法使其能够绘制出周围环境的地图，并计算出清洁房间的最有效路径。这使得Roomba可以在不需要人的干预下自主地彻底清洁房间。

Brooks开发自主机器人的方法基于行为式机器人技术的原则。这种方法强调设计能够与环境互动并从经验中学习的机器人的重要性。通过专注于机器人的行为和互动，而不是试图编程它们执行特定任务，Brooks已经能够开发更灵活和适应性更强的自主系统。

总体而言，Rodney  Brooks在使iRobot的Roomba和其他机器人产品自主方面的成功证明了他在机器人领域的专业知识和解决问题的创新方法。他的工作为自主机器人领域的进一步发展铺平了道路。

---

Rodney  Brooks的自主iRobot产品和预编程机器人之间设计思维方式的主要区别在于它们处理机器人自主性问题的方法。预编程机器人被设计用于执行特定任务，它们的行为由一组预定义的指令确定。

相反，Rodney  Brooks设计自主机器人的方法基于行为式机器人技术的原则。这种方法强调设计能够与环境互动并从经验中学习的机器人的重要性。这些机器人不是被编程为执行一组固定指令，而是被设计为适应和响应不断变化的情况，使其在功能上更加灵活和多样化。

像Roomba这样的自主iRobot产品使用传感器、人工智能和高级算法的组合来导航和与其周围环境交互。通过使用传感器检测障碍物并计算完成任务的最有效路径，这些机器人可以在不需要人的干预下自主运行。

总体而言，Rodney  Brooks的自主iRobot产品和预编程机器人之间的设计思维方式的主要区别在于它们对灵活性和适应性的重视。虽然预编程机器人被设计用于执行特定任务，但自主机器人被设计为学习和适应不同的环境，使其在更广泛的应用中更加灵活和有用。

Jeff  Sutherland表示，Scrum的创立受到了iRobot自主机器人的启发。据Sutherland称，他对iRobot机器人适应并响应其环境变化的能力印象深刻，并看到了这种方法和敏捷软件开发原则之间的相似之处。

特别是，Sutherland被iRobot机器人使用反馈循环不断评估和响应其周围环境的方式所震撼。这种方法与他关于迭代式开发、频繁测试和持续改进的思想相吻合。

Sutherland还指出，iRobot采用敏捷方法在公司的成功中扮演了一定角色。通过采用协作、灵活性和快速迭代等敏捷原则，iRobot能够开发出更加贴近客户需求并能够更快地上市的产品。

总体而言，iRobot自主机器人如何激发Scrum创立的故事凸显了跨学科学习的重要性和从其他领域获得灵感的价值。它也强调了在软件开发和其他领域采用敏捷方法的潜在好处。

启发敏捷的文学作品

敏捷是不同的，你必须重新定位领导的角色，必须解决根本的问题

问题：30%的同事不愿意被改变

• 为GE Power的管理层做培训，培训50个管理层，傍晚Jeff和高管散步时，说：你知道么？你的30%的经理不想改变，他们将抵制你。你要怎么做呢？你需要策略，不炒掉他们，还能解决问题。

• 在被抵制的情况下，怎么推动变革

• Jeff：要学孙子，不战而屈人之兵

问题：短期的紧急情况，削弱了你的长期战略

忙于灭火，不灭火不行。光灭火，没有长期战略，忽视了目标，也不行。既要埋头拉车，也要抬头看路。

• 宫本武藏

• 长短剑结合，没有啥区别

• 短剑帮助长剑，要有战略思维

• 短期是帮助长期的战略

问题：当事情出错时，会责怪别人

• 冯 克劳塞维茨

• 他们错了！自己错了就掩盖。

• 拨开战争的迷雾，"战争迷雾"      指的是影响军事行动决策的不确定性、混乱和缺乏知识。它表明，尽管进行了仔细的规划和准备，但总会有不可预测的因素会影响战斗或战役的结果。

• 从混乱不堪中看到现实，很多人不明不白就被干掉了，被炒掉了

问题：应对对立力量的快速反应，保证了成功

• Colonel John Boyd

• OODA情境意识，高度机动能力

• 想干点啥，都会被反对时

• 认识到现实和情况，要快速行动，fast transition，

• 让反对力量感到困惑，因为你是从另外的方向应对的。对方困惑的原因是：对方认为现实中，你应该是从东边来，而你突然从西边出现，他们需要complete change才能应对你

• 打开了缓冲空间，agile window，在别人重新布阵堵死你之前，打开好多窗户，有了高度机动能力，这是一种很重要的敏捷思维。【思】数字化降维打击也在于此

OODA（观察、定位、决策、行动）是由美国军事战略家和理论家约翰·博伊德（John  Boyd）开发的决策模型。OODA态势感知指的是个人或组织有效观察、定位自己环境、基于信息做出决策并及时采取适当行动的能力。它强调了迅速准确评估情况、适应不断变化的环境以及保持领先于对手或竞争对手的重要性。

OODA模型包含以下四个步骤：

观察（Observe）：收集有关当前情况的信息，包括来自外部环境和内部环境的数据。

定位（Orient）：将观察到的信息与已有的知识和经验相结合，形成对当前情况的理解和认知框架。

决策（Decide）：基于形成的认知框架，做出决策以应对当前情况。这可以涉及对多种选择进行考虑，评估每个选择的风险和潜在结果。

行动（Act）：采取行动执行所做的决策，并监控行动的结果以及可能需要调整的情况。

这些步骤不是线性的，而是循环的，并且需要不断地观察、定位、决策和行动来应对不断变化的情况。

践行SCRUM价值观

干好SCRUM，前提是掌握所有的信息

• 1 Openess，开放

• 每个人都清楚所有的情况，才能做出更好的决策。

• 在敏捷的环境中，每个人都是leader，都要指导现实

• 开发人员寻找技术方案

• SM为服务团队，教练团队

• PO也是leader

• 经理变为leadership，设置愿景和目标

• 【思】 信息权力的影响在减弱，边缘化或排挤一个人变得越来越不可能，微观管理倾向的经理需要开放、民主

• 2 respect 尊重

• 需要尊重才能听到每一个人的声音，搜集到真实的信息

• 3 courage 勇气

• 想获得真实的数据，就必须勇于发生，这需要冒一定的风险，需要勇气

• 4 focus 专注

• 当每个人了解到问题时，他们才能集中精力制定一个解决方案

• 5 commitment 承诺

• 当所有人都同意一个共同的解决方案，承诺就会随之而来

约翰迪尔（John Deere）是一家领先的农业设备制造商，他们采用敏捷方法论来改进产品开发流程，提高协作、加快创新速度和缩短上市时间。通过采用敏捷方法，约翰迪尔能够打破不同部门之间的隔阂，培养跨职能团队合作和以客户为中心的文化。

约翰迪尔敏捷实施的成功案例包括：

• 更快的上市时间：采用敏捷方法，约翰迪尔能够更快地开发和推出新产品，从而缩短了产品上市时间。

• 提高协作：敏捷鼓励不同团队之间的沟通和协作，这导致了更高的效率和更好的问题解决能力。

• 增强客户满意度：通过更加关注客户需求和反馈，约翰迪尔能够提供更好地满足客户期望的产品。

• 增加创新：敏捷允许更快的迭代和实验，从而产生更有创意的解决方案和产品。

总体而言，约翰迪尔采用敏捷方法论帮助他们在产品开发流程中变得更加敏捷、响应迅速和以客户为中心。

---

在采用敏捷方法之前，约翰迪尔在产品开发过程中面临了一些挑战。他们采用传统的瀑布式方法来进行产品开发，导致不同部门之间出现了隔阂，决策速度较慢。他们的产品导致了长时间的时间领先和不总是与客户需求对齐。

为了解决这些问题，约翰迪尔开始在产品开发流程中采用敏捷方法。他们首先组建了包括工程、设计、制造和市场营销等不同部门代表的跨职能团队。这些团队以更为迭代和协作的方式共同开发产品，并在过程中考虑到客户和利益相关者的反馈。

敏捷方法的一个重要优势是它的持续改进和学习的关注。约翰迪尔能够及早并经常从客户和利益相关者那里收集反馈，并使用这些信息实时改进他们的产品。这使他们能够更好地应对市场需求和客户需求的变化。

敏捷还强调团队合作和协作的重要性。通过打破不同部门之间的隔阂，约翰迪尔能够改善沟通并培养跨职能合作的文化。这使他们能够更有效地工作，缩短了开发新产品所需的时间。

敏捷还帮助约翰迪尔更好地管理风险和不确定性。通过使用迭代方法，在投入大量资源开发产品之前测试和完善想法。这有助于减轻失败的风险，并确保他们的产品满足客户需求。

总体而言，约翰迪尔采用敏捷方法已经帮助他们在产品开发流程中变得更加灵活、以客户为中心和高效。通过打破隔阂、促进协作和优先考虑客户需求，他们已能够更快地成功推出新产品。

嘉宾和Jeff互动环节

Sw & hw在应用精益、vsm的区别

软件在提交代码之后的流程，才更像toyota精益要优化的环节，更容易自动化。code之前的环节，idea，需求、规划，架构，很主观，产生了规划文件、架构设计、源代码，这些要进行精益优化、vsm是难的。这两个阶段性的区别怎么处理？

Jeff回应：时代变了，软件、硬件互为师徒，完成轮换。

scrum的源头是lean，scrum是向最好的硬件公司学习得来的。20年以前，软件的更新就比硬件更快，所以我们需要调整，要敏捷。

现在情况又有变化，最好的硬件厂商，一些美国战斗机生产商认为，所有的硬件都是软件，一开始在CAD，后续是在CAE上模拟，可以了再投入生产。好多部件是3D打印的，也是软件控制的。现在是硬件的思维模式mindeset需要改变，硬件就是软件！

特斯拉，生产线上一周20个变更，多个团队设计同一个组件，新组件上线后，团队进行交替。

生产、VSM,、软件的区别和界限慢慢分不清了。

软硬件的区别变模糊，生产的车都不一样，车也要大量的自动化回归测试，产出的车子才安全。

案例，丰田欧洲，200人的团队，5年，由于复杂政治原因，一事无成，效率0.2%。Jeff将拆分团队，团队变小，团队20人，不仅是改善，还需要团队改变，组织架构变化，团队变小。

丰田感想：SCRUM不仅仅是改善，而且是革命性的组织变革。

软件创造所有东西，思维定势要改，硬件按照软件的速度来改。硬件要学习软件的组件化交付。

制造业sop之前和之后不一样，越来越像了。

Tesla，软件之前和软件之后，软件是所有步骤的成分之一，软件分量越来越重，软件做：检查，分析，质控，安全。

特斯拉为什么能在生产线上进行20次改变？多个团队如何设计相同的零件并快速发布，他们如何计划同一零件的不同团队之间的变更？

特斯拉可以在生产线上进行20次改变，是因为它采用了先进的制造技术，如自动化和模块化设计。这使得他们能够快速重新配置装配线，并实施变更，而不会影响整个生产过程。

为了使多个团队设计相同的零件并快速发布，特斯拉可能使用敏捷开发方法、清晰的沟通渠道和强大的版本控制系统的组合。这些实践有助于确保不同的团队都朝着共同的目标努力，并且变更得到正确跟踪和记录，以便无缝集成到整个项目中。

为了规划在设计同一零件的不同团队之间进行变更，特斯拉可能使用产品路线图和项目管理软件等工具来协调努力并跟踪进度。通过将复杂的项目分解成更小、更易管理的任务，他们可以确保每个人都在朝着相同的目标努力。此外，定期会议和检查可以帮助确保在开发过程的早期发现任何问题或差异。

实施大规模敏捷的挑战

不同敏捷团队，实施效果不一样。有些新组织是一开始就敏捷，有些需要经历敏捷转型。

扩张快，新人越来越多，越来越多的sm，但是他们的思维模式不一定对

scrum at scale，启动时要小，结果清晰，慢慢扩张

只有高层有正确的敏捷思维模式，敏捷才能持续下来，这需要十几年的时间（如微软），需要有恒心，有时候要换CEO。

rocket mortgage的例子：

SAFE，2500人增长到4000人，效率翻倍，但是还不够快，rocket认为还可以更快。前端，面向客户，改变最快。以前是Quarter release，现在是daily release。

要scrum @ scale，

• 每个团队都要实践scrum

• 每个人多技能

• 每个团队有sm

• 增效4倍

• 推广到全公司

John Deere的IT团队的SCRUM也做得不好，但是他们不是瓶颈。采购团队才是瓶颈，采购好了，采取改善IT的scrum。取得15倍的改进，关键不是IT部门。

微软的敏捷转型成功故事始于2000年代初，当时该公司看到了需要改善其软件开发流程。当时，微软在长时间的开发周期、延迟发布和缺乏创新方面遇到了困难。

为了解决这些问题，微软开始采用Scrum和Kanban等敏捷方法。它从小处着手，只有一些团队试验敏捷方法，但随着时间推移，这种方法被证明是成功的，并开始在整个组织中传播。

微软敏捷转型的关键因素之一是高层领导接受变革并投资必要的培训和资源的意愿。微软还密切与外部咨询师和领域专家合作，帮助指导其向敏捷转型。

尽管取得了这些进展，微软仍然用了十多年的时间才完成其敏捷转型。这部分原因是由于组织的规模庞大和其软件开发流程的复杂性。这还需要进行重大的文化转变，员工需要适应新的工作和协作方式。

总体而言，微软敏捷转型的成功证明了领导承诺、文化认同和持续投资于培训和资源的重要性。虽然这可能是一个漫长而具有挑战性的过程，但敏捷方法的好处最终可以导致更大的创新、更快的上市时间和改善的客户满意度。

中国本地化实施SCRUM的挑战

每个国家都有他特定的问题

美国：牛仔文化，谁都很强，个人主义，谁也不服谁，大家很难同步。

印度：不透明、不诚实，开头说得好好好的，最后一刻变卦。

中国：中国过渡微观管理年轻员工，micro management，开发人员非常好，管理的问题很严重。中国管理团队参加敏捷培训后，要创造自己的敏捷方法论，以便继续微观领导、深度控制员工。

中国最大的挑战，领导层是否有开放的态度，拥抱敏捷，绩效才能爆发

竖井如何改成敏捷、跨职能团队

• 竖井团队是传统

• 最重要的客户真的要什么，vsm是什么，怎么组织的？

• 案例，游戏公司

• 更新太慢，市场份额下降，游戏产品太多

• 看vsm，想法到上线要2年

• 减少产品，一个敏捷团队只关注一个游戏产品

• 有些团队发布周期从2年变成8周。

• 每个人都必须是、愿意是跨职能的，这能能极大消除竖井

• 设计师：设计做完之后，贡献什么？测试、编码

• 几百人的公司，3年scrum经验。

• QA经理，原来管住自己的测试人员。

• 测试串行执行，测试安排在最后做，来回交接需要好几周，

• 效率差25倍。1个小时能解决的事情，可能要花好几天（配置环境、复现，但是code改了，…）。

• 测试要加入团队，否则炒掉QA Manager

• vsm，是个有效的工具，能看到竖井，延迟在哪里？怎么提高效率

敏捷教练，内部培养教练，进行转型

Scrum master egg，sm自己就必须是coach，培养新人。

agile coach，toyota关联企业说，光培训还不够。

John Deere也内建了敏捷培训组织，内部培养。

类似six sigma bb

scrum应用，敏捷企业

如果企业都成功转型了，教练会失业么？

constant contact：

sm变成了能团结所有人的人，可以做bu的头

后面可以做高管的培训师，高管也经常换人啊，需要教练

让大家一起协作工作的能力，能让你的职业生涯无止境

敏捷最好的时代，业务，教育、政府，机会很大，创新机会很多

嘉宾分享感受

Jack Xu

scrum转型，激励，领导力，很大的前提是大环境做好，scrum才能好。

敏捷教练要懂运营管理，要能做事情 （不要清高），什么都要懂。

能干活的敏捷教练很不容易找。

领导也懂这些道理，各种利益、职位、历史、组织架构方向制约，领导可能认知到了，但是没有太多办法。

Lisa Wang

领导不支持，全白谈了，老版听懂了才行

关键是领导听懂了，领导才能保证转型成功

最好是敏捷教练拉着领导来听课

Glen Wang

敏捷逻辑，一个团队天生有多倍绩效的潜能。被压制住的原因是管理风格，这也是敏捷的开关。管理者要放弃命令与控制，转化成教练与支持，变成赋能的角色。

敏捷和scrum是福音，传教士的心态和精神，要多喊一喊。

TestOps 云层

往前走，测试到敏捷测试，测试教练角色有很多机会

不要有测试团队，测试人员应该分散到团队中，专搞QA没有前途

每个人都可以是qa，每个人都是Qa，po、开发等等

Deng Ying

Bosh，硬件领域，敏捷转型，有保守、有激进等不同做法。

敏捷团队，最佳5人，有的更多，团队怎么看

把大团队打散，组成全职能团队。

不要着急，先看到效率提升，或者如期交付就很好了。

要实现spotify的模式很难，团队之间横向难打通，还没到SAFE

Lisa Wang

利新易，破旧难

产品模块化，要解耦，团队不要绑定在一起

大家都要下刀

夏涛

开发、敏捷教练，转型咨询师

转型是组织变革

不仅要懂scrum的硬的东西，还要软技能，软的部分很重要：管理，绩效、团队配置、敏捷转型是组织变革

不支持敏捷的人，怎么接触，怎么转变这些抵制者。

组织变革管理，运营管理，对做好敏捷转型很重要

Lisa Wang

Registered Agile Coach课程：敏捷教练课程，传授的是教练、引导、变革，引导工具，带团队，教练，忍住自己给direction的心，要有这个专业技能。

云加速 Oliver

Above DevOps and Agile

产品线，打通vsm，底下是敏捷还是devops、自动化

中国领导喜欢hiarchy，micromanagement

放权，小团队，sub team， scrum team，silo取消

今天课后，云加速自己增加了信心，看见是第一件事，车同轨、书同文地看见

不是看每日构建数、缺陷逃逸率，是看产品的流的质量，打通，看flow，而不是看局部的metrics，从flow看出具体哪个环节出了问题

Glen Wang

vsm促进管理民主

联邦制

灵活自治，领导还有掌控感

数据要能看到每个团队的状态，怎么投钱。管住往哪个方向走

领导管做什么

Lloyd Wu

做的事情越来越游戏化

族长，族长会

游戏就是及时反馈

旧的、传统组织存在的问题：如果没有人告诉他要做什么，他不敢随便乱动。

敏捷强调：自组织、自管理

Eric

设计背景

团队协作，纵向、横向协同的工作方式

怎么找到T型多种技能的人，这种人才很稀缺

T型人才有擅长，对新事物充满热情

不要用有限的人生经验去评判无限的可能

思考好了，充分准备，试验的成本其实不高

向上管理，manager到leader能力培养和转变

目标一致，路各自走。

焦虑的同时心怀远方

Lisa Wang

招人，关键是mindeset要open，i.e 马斯克自学，钻研学，比专业人士还高很多。

sm要coach的：长期主义，持续的，环环相扣，长期思维，慢慢往那个方向靠，例如，不是在一个sprint就完成跨职能团队，而是让让团队越来越跨职能

TestOps云层

勇敢承诺，勇敢学。同时，熬过创业期很难。要慢慢花时间才能做起来。

Lloyd Wu

专家和大师访谈，精彩都是q&a部分

冻土层怎么解决，只要解决了，组织转型问题不大。

敏捷没有新的内容，最基础、最核心的十年前甚至更早时间就定型了

敏捷这个领域的实践越来越扩大，不仅是机械式的框架、架构，还包括文化、团队、组织发展等核心

期待后续更精彩的活动

Lisa Wang

感谢！小伙伴，新老朋友，会议后勤，

Fei Chen

Jeff是真神，每次都能学到新的东西，希望多看两遍视频

笔记说明

Jeff Sutherland和国内敏捷专家一起谈论了敏捷转型。作为社区搬运工，我鼓励大家再观看几次视频回放，并尝试做笔记，专注学习，避免“碎片化统合起来没有整体价值就是虚假繁忙”。社区举办了三场活动，都值得仔细品味。

网盘链接

OneNote及PDF格式的完整笔记链接：

https://pan.baidu.com/s/1zaRvJnzpWcQyqZMuPX1SHw?pwd=dnl6