花时间投资自己 Nivi: 如果您必须从事“普通的工作”，则要承担责任以建立您的专业知识（special knowledge） 我们遇到一个常见问题：“我如何找到时间开始对自己进行投资？我有工作。”
您必须花时间开始.
只有开始了（行动了）才知道下一步做什么。 “您将需要花费时间才能开始。要么是学习，要么是储蓄。最好是在一个尚不知道如何培训人员并且学徒制是唯一模式的企业中。”
Naval：尝试学习人们尚未完全知道如何教书的东西。如果您正在一个新的且迅速扩展的领域中工作，那可能会发生。这在环境很重要的领域也很常见，在这些领域中，细节很重要，并且总是在变化。投资是这些领域之一；企业家精神也是如此。
对于从硅谷开始的年轻人来说，创始人的参谋长是最令人垂涎的工作之一。最聪明的孩子会跟随企业家，并做他或她需要他们做的一切。 在很多情况下，这个人是完全不合格的。拥有多个研究生学位的人可能正在洗洗CEO的衣服，因为这是目前最重要的事情。 同时，该人参加最重要的会议。他们对所有的压力和戏剧，筹款平台和创新一无所知，这只能归因于房间。
刚从大学毕业的沃伦·巴菲特（Warren Buffett）希望为本杰明·格雷厄姆（Benjamin Graham）工作，以学习成为一名价值投资者。巴菲特提出免费工作，而格雷厄姆回答说：“你被高估了。” 这意味着您必须做出牺牲才能接受学徒训练。
用最陡峭的学习曲线找到工作的一部分
如果由于需要赚钱而无法在学徒模式中学习，请尝试根据自己的工作进行创新。承担新的挑战和责任。找到学习曲线最陡峭的部分。 您想避免重复的工作量，这只是等待时间，直到您的工作自动完成。
如果您是咖啡店的咖啡师，请弄清楚如何与客户建立联系。弄清楚如何创新您提供的服务并使客户满意。经理，创始人和所有者将引起注意。
培养创始人的心态
对于任何创始人而言，最困难的事情是找到具有创始人思想的员工。这是说他们足够在意的一种奇特的方式。 人们会说：“嗯，我不是创始人。我没有得到足够的照顾。” 实际上，您是：通过建立创始人的心态而获得的知识和技能使您成为线下的创始人；那是你的报酬。 您几乎可以从任何职位上受益匪浅。您只需要投入很多。
立即承担责任
Nivi：我们已经讨论了责任制，判断力，专业知识和杠杆作用。如果我从事的是“普通”工作，那么我应该关注的是专业知识吗？
Naval：审判需要经验。建立起来需要很多时间。您必须将自己摆在可以行使判断力的位置。那将来自承担责任。 在您表现出判断力之后，社会才能为您提供杠杆。您可以通过学习诸如编码或与媒体合作等高杠杆技能来更快地获得它。这些是未经许可的杠杆作用。这就是为什么我鼓励人们即使在晚上和周末也要学习编码或制作媒体的原因。
划重点：写代码或制作媒体（如文章、视频、音频等）是非常重要的能力
因此，判断力和杠杆作用往往稍后出现。问责制是您可以立即采取的措施。您可以说：“嘿，我负责这件事，没人管。” 当您承担责任时，您也会公开将自己放在切菜板上，因此您必须做到。 通过对其他人不知道该怎么做的事情负责，您可以建立专业知识。也许它们是您喜欢做的事情，或者自然倾向于做。
如果您在工厂工作，最困难的事情可能是筹集资金以保持工厂运转。也许那就是老板总是要强调的。 您可能会注意到这一点，并认为：“我擅长平衡支票簿，并且对数字有很好的理解；但我以前没有筹集资金。” 您愿意提供帮助，并成为业主解决他们的筹款问题的助手。如果您天生有才干并承担责任，则可以让自己处于快速学习的位置。不久，您将成为继承人。
尽早找到自己感兴趣的事物，并让您承担责任。不用担心短期补偿。当您厌倦了等待补偿并放弃补偿时，就会收到补偿。这就是整个系统的工作方式。 如果您承担责任并在他人无法解决的知识边缘解决问题，那么人们将在您后面排成一列。杠杆将到来。
专业知识技能可能是短期的，也可能是长期的
专业知识有两种形式：短期和长期
如果您一跃成为世界一流的机器学习专家，并且凭借着真正的兴趣而到达了机器学习领域，那么您将做得很好。但是从现在开始的20年后，机器学习可能会成为第二帽子。世界可能已经转移到其他地方。这就是短期的知识。 如果您擅长说服他人，那么这可能是您一生中就掌握的技能。说服他人总是适用的，因为说服人们总是很有价值的。这是长期的知识。
现在，说服是一种通用技能，可能不足以建立职业。正如斯科特·亚当斯（Scott Adams）所写，您需要将其组合在技能栈中。您可以将说服与会计以及对半导体生产线的理解结合起来。现在，您可以成为最佳的半导体销售人员，然后成为最佳的半导体公司首席执行官。 长期的专业知识通常无法教授，并且永远存在。短期的专业知识来去去去；长期的专业知识的保质期往往比较长。
技术是找到那些短期技能的好地方。如果您可以从外部引入更通用的专业知识技能，那么您将获得财富。
技术是获取专业知识的知识前沿
Nivi：推特里还有其他关于该主题的推文。第一：“技术行业是获取专业知识的好地方。前沿始终在前进。如果您是真正的智力好奇者，那么您将比其他人先获得知识。”
Naval： 丹尼·希利斯（Danny Hillis）表示，技术尚无法解决的一切。技术无处不在。汤匙曾经是技术。火曾经是技术。当我们弄清楚它们是如何工作时，这种技术就消失了，并成为我们日常生活的一部分。 从定义上讲，技术是知识界。从科学和文化的角度来看，我们还没有弄清楚如何大量生产或有效创造，还没有弄清楚如何将其商业化并提供给所有人。 技术将永远是一个广阔的领域，在这里您可以获取对社会有价值的专业知识。
Nivi：这是来自推特的另一条与问责制有关的推文：“公司不知道如何衡量产出，因此他们衡量投入。以使您的输出可见和可衡量的方式工作。如果您没有责任心，请采取其他措施。”
Naval：激励机制来自农业和工业时代，投入和产出紧密匹配。您投入某些时间进行的工作可以可靠地代表您将获得什么样的输出。
如今，工作已经变得非线性。一个好的投资决策可以使一家公司赚1000万美元或1亿美元。产品的一项良好功能可能是产品与市场的契合与完全失败之间的区别。 因此判断力和责任感就变得更加重要。通常，最好的工程师并不是最努力的工人。有时他们一点都不努力，但是他们可靠地在适当的时间发布了这一关键产品。这类似于完成该季度公司大笔订单的销售员。 人们需要能够分辨出您在公司成功中所扮演的角色。人们对别人给予过多的信任极为敏感。您总是想得到荣誉。聪明的人会知道谁负责。
对于这种类型的问责制，有些工作也太远离客户了。您只是一台机器上的齿轮。
咨询就是一个很好的例子。作为顾问，您的想法将通过组织内的其他人传达。您可能看不到高层人士；您可能隐藏在屏幕后面。您要权衡以换取自己的独立性。
承担责任，你就要变得脸皮厚
有责任心时，如果一切顺利，您将获得更多的荣誉。当然，不利的一面是，当事情出错时，您会遭受更多的伤害。当您伸出脖子时，您必须乐于受到指责，牺牲甚至受到攻击。 如果您是那种在高责任心环境中壮成长的人，那么随着时间的流逝，您最终将变得厚颜无耻。你会受伤很多。如果你失败了，人们会攻击你的。
和学徒一起扩展专业知识
Nivi：一旦掌握了一些专业知识，就可以通过培训自己的学徒并将任务外包给他们来扩展知识。
Naval：例如，我进行了不错的投资并找到了创业公司。我本可以继续这样做并赚钱。相反，我与他人共同创立了Spearhead，以训练有前途的创始人成为天使和风险投资人。我们给他们一本支票簿以开始投资。
这是一个学徒模式。他们以他们正在寻找的交易来找我们，我们帮助他们仔细考虑。该模型比我的个人投资更具可扩展性。
专业知识来自工作，而不是课堂
在Spearhead，我们领导班级向创始人教授有关投资的知识，并且我们还举行办公时间，讨论他们带来的具体交易。
百万年薪之间的对话（自由职业者访谈录） 一开始的标题并不叫这个，而是“百万年薪敏捷教练”的采访。几个标题之间审视过后，还是喜欢现在这个。因为我现在也是百万年薪哦！因此我们来看看2个百万年薪的人之间的秘密吧。
李小波 李小波，资深敏捷教练，极限编程学院高级培训师，自由职业者，3个孩子的爸爸。“成为百万年薪敏捷教练”知识星球球主。
自律、爱家、成事、利他
自由职业访谈 为什么会想到“百万年薪”这个标签 Q（Bob）：为什么会想到“百万年薪”这个标签？
A（李小波）：成为自由工作者之后，没有稳定的工资，所以我会记录自己的每笔收入，也包括知识星球的收入等。在自由职业第一年，工作了179天，统计的总收入为103万（哇！恭喜小波老西）
Q（Bob）：你的知识星球主要写哪些内容？
A（李小波）：我会记录自己的职业心得，并为星球内的伙伴解答敏捷中的困惑、问题。欢迎大家订阅《成为百万年薪敏捷教练》
Q（Bob）：能说一下 ThoughtWorks 这家公司吗？
A（李小波）：在社区活动中，很多的分享者（如王宇、乔梁、钱安川等）都是来自于同一家公司（TW）。于是我很好奇这究竟是一家什么样子的公司，我能不能加入？ 2015年经过曲折的面试后，我成功加入这家公司。后来离开创业了一段时间后，再次以培训师的身份加入TW。在 TW 的这段时间中，个人成长很大。
Q（Bob）：刚才你有提到社区，能说一下（敏捷）社区对你的帮助吗？
A（李小波）：可以说社区完全改造了我。从个人、朋友圈、生活及工作。（小波老西对于社区的评价非常高呀）一开始工作时，我只是一个 Team Leader ，在Bob的影响下，参加了敏捷之旅的组织、RSG的组织；并慢慢再社区中开始演讲，产生影响力。
划重点1：小波老西的自由职业者成长路径： Team Leader -> 参与（敏捷）社区（组织者工作） -> 演讲，产生更大影响力 -> 成为自由职业者。
如何参与敏捷社区组织工作？ 私下联系 Bob Jiang 即可
Q（Bob）：能给想成为自由职业者的朋友们一点建议吗？
A（李小波）：成为自由职业者，可以是2个关键步骤：1. 培养自己专长领域的培训（或演讲）能力，这样可以很容易切换赛道；2. 参与社区，并留意社区中的渠道公司（多是培训公司）。
划重点2：社区为王
总结 李小波，小波老西，非常自律的一个人。因此最后小波老西送给大家一句话：
自律带来自信，自信才有自由！
[Youtube视频]() [B站视频]()
什么是Scrum Scrum 是用于开发和持续支持复杂产品的一个框架。其中包括 Scrum 的角色、事件、工件，以及把它们组织在一起的规则…
Scrum (名词): Scrum 是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付尽可能高价值的产品。
Scrum 是:
轻量级的 易于理解的 难以精通的 Scrum 是一个过程框架，自上世纪 90 年代初以来，它就已经被应用于管理复杂产品的开发上。Scrum并不是构建产品的一种过程或一项技术，倒不如说，它是一个框架， 在此框架 中您可以使用各种不同的过程和技术。Scrum 让您的产品管理和开发实践的相对成效更加清楚地显现出来，因此您可以去改进它们。
Scrum指南 从Scrum指南中我们可以快速总结如下：
Scrum是一个过程框架 Scrum框架用于开发复杂产品 Scrum框架帮助人们解决复杂的自适应难题 Scrum能帮助人们高效交付尽可能高价值产品 Scrum框架中可以使用各种不同的过程和技术 因此，Ken Schwaber 曾经说过：
Scrum 就像你的丈母娘，不断的指出你的问题。
由此也不难看出，Scrum框架的核心在于不断暴露问题。即它是一个暴露问题的反馈框架。
下面我们来看看Scrum框架中具体包含什么内容。
Scrum 框架 Scrum框架是3个角色，3个工件，5个事件，5个价值观（即3-3-5-5）
3个角色 Scrum的3个角色分别是：
产品负责人（Product Owner）。产品负责人负责最大化产品和开发团队工作的价值。对产品负有最终责任，生杀大权。产品负责人可以决定先做什么，后做什么。 开发团队（Development Team）。开发团队包含了各种专业人员，负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。只有开发团队成员才能创建增量。这里所说的开发团队，和我们平时所说的有区别。这里的 开发 指的是产品开发，不是写代码。那么开发团队就会是自组织的跨职能团队。 Scrum Master。Scrum Master 负责根据 Scrum 指南中的定义来推广和支持 Scrum。Scrum Master 通过帮助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。这个角色没有翻译的中文。但他绝不是项目经理，也不是 team leader 。Scrum Master更像是一个团队的教练。 3个工件 产品待办列表（Product Backlog）。产品待办列表是一份有序列表，其中包含产品需要的一切可能的东西，也是产品需求变 动的唯一来源。产品负责人负责管理产品待办列表的内容、可用性和排序。 Sprint待办列表（Sprint Backlog）。Sprint 待办列表是一组为当前 Sprint 选出的产品待办列表项，同时加上交付产品增量和实现 Sprint 目标的计划。Sprint 待办列表是开发团队对于下一个产品增量所需的那 些功能以 及交付那些功能到“完成”的增量中所需工作的预测。 增量。产品增量是在Sprint内开发团队交付的所有产品待办列表条目的综合。增量必须是符合团队定义的“完成的定义”（Definition of Done） 5个事件 Sprint。也翻译做冲刺，是Scrum的核心，也是一个容器。Sprint是一个时间盒（固定的开始和结束时间），下一个Sprint会紧随上一个Sprint，在这之间没有停顿。Sprint由Sprint计划、每日展会、Sprint执行、Sprint评审及Sprint回顾组成。 Sprint计划。一个Sprint中准备做的所有工作是在Sprint计划会议中完成的。这份计划是整个团队（产品负责人、Scrum Master和开发团队）共同完成的。Sprint计划最主要完成两件事情： 在这个Sprint中要完成什么产品待办列表条目？（What） 如何完成这些条目？（How） 每日站会。开发团队15分钟同步进度并每日调整的一个事件。在每日站会上，每个团队成员回答以下三个问题（基本的，可以根据情况增加新问题）： 昨天，我为帮助开发团队达成 Sprint 目标做了什么?
什么是虚拟引导 虚拟引导（virtual facilitation），顾名思义，不是线下面对面的引导，而是采用线上的方式进行的引导。 虚拟引导，也叫作虚拟会议引导。
如果想成为一名优秀的虚拟会议引导者，你需要精通以下三个领域：
必须知道你正在使用的虚拟会议平台的功能； 应该理解和熟练使用引导优秀虚拟会议的原则； 应该有一个能够使参与者在虚拟的环境中保持专注和高产的参与策略工具箱。 本书通过12章的内容为你提供了实现上述三个目标的路径和各种策略。那些熟悉《引导的秘诀》和《卓越会议的秘诀》的读者将会看到，在这两本书中所描述的具有威力的引导技术是如何进行调整和精简，以适应虚拟环境的。本书分为四个部分，分别介绍了虚拟革命、虚拟会议、应对挑战和虚拟会议示例。经过学习和实践，你将会得虚拟困境所带来的问题的答案，成为高效虚拟会议的组织者和实践者。 – 《虚拟引导的秘诀:在线会议引导的实操指南》 by Richard Smith（理查德·史密斯） [美]Michael Wilkinson（迈克尔·威尔金森） (ISBN: 9787115438454)
虚拟引导中的“坑”（陷阱） Bob 上周参加了 Pepe Nummi 的虚拟引导工作坊，收获颇丰。不敢藏私，在这里把虚拟引导当中可能会遇到的问题整理了一番，分享给大家。
虚拟引导中的“坑”（陷阱）分类如下：
准备不足 引导指令不清晰 培训师风格 参会者的参与不足 不自信 与主题无关 准备不足 准备不足不仅是说虚拟引导，其实对于每一次引导（或培训）都需要事先准备。 而事先的准备会包括以下内容：
工具的熟悉 引导结构（框架）的设计（可以参考 Pepe老师的 CSA结构 - Clarification, Solution, Action） 引导工具的选择（比如力场分析、投票、me-we-us等） 事先演练（dry run） 要提问的问题 只有把以上内容都想清楚了，提前准备充分，才会避免一些意外的发生。
另外针对意外情况，还要有备选方案。
引导指令不清晰 指令不清晰是引导中非常常见的一个问题。比如有人给出的指令是简短扼要，而有人会尝试说了2分钟依然没有提到重点。 所以在准备环节中，可以邀请1-2位小伙伴，进行演练。
先写下你的指令（及要提问的问题） 说给小伙伴听 问问反馈，听懂了吗？哪里有问题 改进自己的指令 一个好的引导指令大致有如下特点：
不要随意发出指令，每个指令都要完成特定的目的 一个指令只做一件事情。如下面邀请小伙伴在白板上写下你的名字…… 尝试用不同的语言描述指令，或者举例示范说明指令 一个指令结束后，要和伙伴确认是否有疑问。（随机抽取一个伙伴的名字提问，忌问全体） 带有时间说明。如下面我们有2分钟，做这件事情…… 用简练的语言，避免口头禅。如那就是说，可以吗，等等 尽可能把指令写到ppt上 部分观点参考于知乎文章
如何定义自由职业 自由职业 = 自由 + 职业
自由职业是一个组合词，很多人会第一眼看重的是自由，这里我要强调的是职业。
职业就是你（作为个人）的产品，也就是你生存下去的根本。
比如有人是程序员，那么你的产品（产出）是代码；有人是写手，你的产品（产出）是文章。
而自由职业并不是每个人都适合。要看每个人的追求是什么。
有的人追求稳定，有的人喜欢探索；《穷爸爸富爸爸》中有一幅图可以很好的解释职业（如下）：
我们每个人的职业可以分在EBSI四个象限：
E(mployee) 职员，这里适合追求稳定的人 B(usiness) 创业，这里非常刺激 S(elf-emplyed) 自由职业，这里也很刺激，介于E和B之间 I(nvest) 投资，这里每个人都应该要做 德雷福斯模型 而每种职业的晋级（发展）基本遵循德雷福斯（Dreyfus）模型。
新手 高级新手 胜任者 精通者 专家 1. 新手 新手最大的特点是，需要指令清单。告诉我怎么做，最好是一步一步的指令。
2. 高级新手 高级新手不想要全局思维。他们会局限于某个部分，而无法看到全局。
3. 胜任者 胜任者能够解决问题。胜任者通常是非常主动，且足智多谋；善于解决问题。
4. 精通者 精通者可以自我纠正。处于这个阶段的人会有很强的独立思考能力，可以自我发现（或通过朋友同事的反馈发现）不足，并及时纠正。
5. 专家 专家凭直觉工作。
– 以上资料摘选自《程序员的思维修炼》第二章（作者：Andy Hunt）
自由职业的6项必备能力 美国现有的职业者中大约30%-40%是自由职业，而中国很快就会成为下一个美国。
无论从收入还是职业发展的情况看。
作为一名自由职业者，必须掌握以下技能才能很好的生存下去：
写作 营销 连接（网络） 英语 财务管理 精力管理 1. 写作 80%以上的自由职业者会时不时的进行写作。可能是推广产品，可能是个人经验分享，也可能是个人的思考。总之是要进行写作输出的。 如果你想要成为自由职业者，那么从现在开始就要练习写作。
种一棵树最好的时间是10年前，其次是现在！
前言 业务敏捷可以定义为一个组织重塑自我并快速适应环境变化的能力。克劳斯.利奥波德在他的书《Rethinking Agile》中提出，人们需要优化交付客户价值的流来实现业务敏捷。通过优化流，你迟早会注意到需要组织结构做什么样的调整来加以支持。
首先，关键是理解敏捷的真正含义，就像敏捷宣言中构想的那样，它并不是组织交付客户价值的速度，而是组织以低成本快速响应变更的适应性。（参阅《Scaling Lean & Agile Development》中 _Be Agile一章）。利奥波德对于组织变革还有这样一个观点：在持续地关注系统优化目标时，人们会注意到那些阻碍改进的因素。然而通过系统思考，长时间在实地的观察和实践，对现存系统动态的反思，人们也可以预见到那些阻碍快速适应能力的相对明显的现存组织障碍。在这个故事中，一个组织学习并最终看到影响大规模适应性的组织障碍，它经历了漫长而痛苦的过程。更糟糕的是，很多管理层试图保持传统管理现状而仅仅将事物标记为”敏捷”，而不是去预见 - 或者愿意去预见 - 相对明显的障碍并在一开始就进行必要的变革。简而言之，这个过程恰恰反证了LeSS中的关键导入原则（“对于产品团队，要在一开始就建立LeSS的组织架构，这对导入LeSS非常关键”_）以及由此带来的后果。
所以，接下来的案例说明了，如果组织没有在一开始进行合适的组织设计，会发生什么情况。从开始的传统组织架构和管理方式入手，可能混有一点伪Scrum元素，LeSS要求的组织设计_也许_会浮现。但这将会是一个更长、更危险的旅程，因为它可能不会带来导入LeSS所预想的好处。为什么？因为一旦没有立即采用新的组织架构，那股保持组织现状的强大力量极有可能会获胜（参阅拉曼组织行为定律）。
本案例的关键”反事实”洞察：如果你想开始业务敏捷的旅程，期望减少过程中的许多痛苦，并快速获得LeSS所预期带来的适应性上的提升，一定要在导入LeSS的开始阶段就建立合适的组织结构，就象LeSS规则所倡导的那样。
开始之前的评注 LeSS就是（多团队的）Scrum，Scrum就是单一团队的LeSS。（参阅原则：大规模Scrum也是Scrum）。为了让本案例中的描述更加准确，我还是会澄清哪些是Scrum指南中的规则，哪些是LeSS指导方略中的规则。在参与这个案例的过程中，我受到less.works网站的积极影响，参加了Bas Vodde和Craig Larman的LeSS实践者课程，并花费了大量时间阅读最初出版的两本LeSS书籍。可惜的是那时第三本书还没有出版。在这个案例中，我阐述了我们尝试过的LeSS实验，并且也会关联我们遵循的LeSS原则、规则和指南，尽管那时并不知晓。
简介 下面的案例涵盖了我从2015年2月到2016年9月在一家公司Sys的IT组织做外部教练的时光。Sys是一家来自德国的从事软件行业的跨国公司。因为我已签署保密协议，所以不能在此公布公司的真名和其他相关的公司信息。时间回到2014年底，Sys着手用一个平台来变革公司软件销售方式，取代现有各种外部合作伙伴平台。这个平台的诞生标志着Sys迈入电子商务新途径的里程碑，不仅重新思考了如何直接地向客户销售软件，还重新定义了卖什么（例如，除软件以外的数据）和怎么收费。
这背后的想法是创建一个网上商城，客户可以通过最小的交互，从Sys或是其他第三方软件发现、尝试和购买软件、内容和数据。目标是通过电子商务产品”SAP Hybris Commerce”来提供像亚马逊一样的简单流程，同时涵盖多样的产品部署（就地部署和云解决方案），支持不同的支付方式（信用卡和PayPal）。 2011年，我曾在负责所有内外部平台的Sys IT部门工作过，这些平台跟Sys商店很像，那时我们整个部门开始将瀑布模式替换成Scrum。在用（单团队）Scrum的方式搭建了两个平台之后，我离开了这家公司，去支援其他客户的敏捷之旅；在2015年的早期，我又重新加入Sys来支持这次重要的旅程。
变革之前 系统架构 在我加入的时候，有四个团队并行工作，研发新功能或者增强现有平台，并用固定的时间表合并代码，然后进行好几周的集成测试和验收测试。系统格局是一个复杂的三层结构，包含基于Spring框架的主要J2EE应用程序平台SAP Hybris Commerce，用于存储数据的SAP Hana 数据库，基于SAP PI服务器与SAP ERP和SAP CRM的同步，还有额外的第三方服务用作分析、处理信用卡支付或用户生成内容的集成。 变革之前的组织结构 图3是组织结构。有三个开发团队，两个在欧洲一个在美国，并行工作在系统的不同部分。还有一个架构团队，负责新特性的软件整体设计，以及一个测试团队，在不同团队的代码合并之后进行集成测试。此外，另有一些后台开发（SAP ERP/CRM）专家、DevOps专员和UI专家，他们没有加入任何研发团队，而是建立了自己的团队。欧洲的团队成员（随机地）分布在德国、波兰、西班牙、爱尔兰和保加利亚。这是因为Sys只有六名公司正式员工，其他所有团队成员均来自于专门从事SAP Hybris研发的第三方供应商。 除了技术团队，还有一个超大的业务组织来支持软件的研发和运营。在第一层，经理们带领一个小团队来进行特性的优先级排序、编写蓝图、执行用户验收测试并启用功能。在第二层，又有一个团队专门负责整个产品组合、需求排序以及业务方用户验收。在第三层，是由三个项目集经理组成的项目集管理，一个来自业务（Sys Digital），一个来自Sys IT，还有一个来自Sys Education的项目总负责人。另外，还有一个支持项目集管理的项目和质量管理办公室。为了跟踪研发和业务的进度，每周还有工作流周会，干系人状态周报，以及从项目办公室汇集到管理团队的书面项目集更新。 痛苦的最后期限和变革的必要 当我在2015年2月底加入时，平台基本上已经可以使用，只差正式宣布。各团队还在冲刺最终官方发布日期：2015年5月5日。到时候公司会在美国举行有史以来最大的会议，首席数字官会当场向公众演示这个平台。所有正在研发的功能都是官方需要发布的功能，所以，项目办公室制定了一个看起来能在5月2号发布所有功能的严格的项目计划。该计划包含了研发阶段、系统集成阶段，用户验收测试以及回归测试，就像我们通常说的瀑布模式。
在三月的最后两周和整个四月项目进入一个动荡期。时间表正渐渐延期。当并行工作在不同功能的团队将他们的代码合并到主代码仓库后，很多之前已经测试通过的功能不再能使用或者表现异常。不停修复这些问题又带来新的问题，并且还经常突然接到必须立刻实现的新需求。在此之上，之前从未考虑过的安全问题和负载测试现在也必须解决。管理层变得十分焦虑，每个人不得不工作更长的时间来尽量满足计划。在四月的最后两周，还建立了一个”作战室”，所有的经理、团队负责人和架构师都在这个房间从早到晚不停的清理障碍以保证发布的所有准备工作都做好。最后，开完数不清的升级会议和成百上千小时的加班之后，团队终于能够在大会的第一天发布平台的新版本。
经过了如此痛苦的发布，对管理层来说，毫无疑问现有的研发方式已经不能支撑公司的雄伟目标，那就是销售指数级增长，能快速尝试新的商业模式和推出完全不同的产品。Scrum作为一个敏捷研发框架，专注于首先交付最高业务价值，持续关注透明性、检视和调整，这些都建立在基于经验过程控制的理论之上，它成了一个自然而然的选择。然而要导入Scrum或者LeSS都被认为极其困难，不仅仅是因为组织层级设置和对分散在不同地方的各种技术专家的依赖，还受到巨大营销渠道的影响，即每年有两次不可更改的作为大里程碑的重要峰会。
引入变革 作为一个偏好大规模Scrum的经验丰富的敏捷和Scrum教练，我被要求建议”研发部门”应该如何改变工作方式以应对当前的挑战。 我的挑战因此是（1）让所有人都意识到为了应对挑战_不只是研发部门而是整个组织要改变_；（2）帮助参与者_通过理解为什么_来拥有变革背后的想法，而不只是跟随我的想法遵循我的建议而已。 在一次上层管理者（包含Sys首席数字官）的会议中，我展示了从和业务和研发代表的对话中收集到的关于挑战的总结。它包括：
业务挑战（摘录）
单个特性和产品能力的优先级不明确 _明确标注_已完成的工作在后期出现问题 技术挑战（摘录）
可用性和基础设施问题（性能，端口关闭等）妨碍了日常运行 整个部署流程耗时太长。常常缺少某些部分（模版，后处理等） “架构师”们忙于做构建流程、合并代码、以及基础设施的建立/配置这样的手动任务 使用各种分支而不是基于主干的开发，导致代码合并的工作量巨大；并且质量很低，有许多缺陷/问题 测试数据的的创建是一个非常耗时的过程并深受知识缺口的影响 在准备这个会议的过程中，我还收集了管理层的整体改革目标。基于与管理团队成员一对一谈话和访问，我总结了如下几点：
边境安检系统：LeSS与离岸开发 背景 背景与客户 SITA创建的产品可帮助全球各地政府确保边境安全。我们正在创建的产品是用于自动化边境的解决方案，以在不影响安全性的前提下优化前往各个国家旅行者的流程。该产品是这样构建的，获取前往相应国家的所有旅行者数据，根据可用的监视列表对每个旅行者进行筛选，并针对被政府机构（例如，警察、移民等等）用系统标记的旅行者采取并记录必要的行动。
原文链接
开始 2010年SITA赢得了一项为期18个月的大合同，以创建和实施边境安全系统。该系统包括高度安全的数据中心和部署在该国所有口岸的软件解决方案。
Frank West（产品交付总监）聘请我为内部顾问，来帮助他们采用敏捷的工作方式。
双方之间的合同是构建整个系统（产品和数据中心），并在18个月后以一次性的方式进行部署。但是软件开发总监对这种方法感到不安，因为过去他多次在一次性交付中吃过亏。这次的情况尤其如此，因为该系统非常复杂并且由许多未知数组成。因此，他想（再次）探索敏捷的工作方式，并雇用我来帮助他以迭代、增量和自适应的方式交付该系统。
我加入时，SITA的组织结构非常等级化，划分成独立的职能部门。看起来像这样：
业务团队存在类似的结构，主要由项目经理、销售顾问和业务解决方案架构师（主题专家SME）组成。
向Scrum过渡（但不是LeSS） 我们从为期三天的研讨会开始，了解敏捷宣言、敏捷原则及Scrum。从正确的教育入手至关重要。我们想确保建立一个长期的学习型组织，因此我们将重点放在激发与提供适当的教育方面，以实现更多的协作、迭代和增量式的工作方式。我提供了Scrum概述的培训，然后我们讨论了如何组建开发团队。在与开发团队和管理层进行了大量讨论之后，我们提出了如下的团队结构：
对我们而言，从一开始就建立适当的结构非常重要，以确保我们创建真正的团队，同时牢记“文化遵循结构”，这是“拉曼的组织行为法则”的第五条的一部分，因此我们首先创建了两个跨职能的Scrum团队。这些团队由SME、BA、开发人员、测试人员和架构师组成。尽管我们的确是由一组专家组成的团队，但每个团队成员只有一个头衔即“开发人员”。对团队的承诺和期望是他们将不再担任专家，整个团队将朝着Sprint目标努力，并选择实现Sprint目标所需的下一个任务。
我们的主题专家（SME）人才是边境控制流程和航空业的高技能领域专家。
我与弗兰克（Frank）讨论过，我们不需要项目经理，但他还是坚持要求保留两个人（项目经理和解决方案架构师）来管理公司报告和一些售前活动。他们俩都对要出售给客户的产品有很好的领域知识。
弗兰克（Frank）明白，将来我们不再需要这两个“角色”，但是他建议保留这两个人的角色，在目前将有助于我们跟销售团队就一直在开发的产品保持同步，以便让他们不要将其作为单独的“项目”出售。弗兰克要求他们两个都与销售团队工作，并且他们也定期与产品负责人工作，以了解我们产品的进度，以便他们可以相应地为我们的潜在客户提供建议。
我们继承了组件团队 从总体上讲，整个解决方案是从航空公司收集每位乘客的数据，并根据观察列表对每位乘客进行筛选，以了解是否有不受欢迎的人试图访问该国。该解决方案主要分为两大部分：数据获取系统（DAS）和风险评估系统（RAS）。所以团队也是按这一结构来创建。Black团队（每个团队用颜色来命名）负责获取数据，Green、Blue和Purple团队负责风险评估（译者注：与作者确认最开始只有Green团队）。因此我们从组件团队开始，当时看起来很“合乎逻辑”。
从组件团队到特性团队 最终，我们意识到组件团队在团队之间引入了许多不必要的依赖与移交，这导致了迟来且昂贵的反馈，在整体回顾中我们也讨论了这些反馈。使用这些反馈，我们开启了以避免不必要的依赖的从组件团队转向特性团队的对话。在对话期间我们还意识到，如果我们不尽快转向特性团队（跨团队管理依赖关系将是一场噩梦），将来很难有效地添加更多团队，因此我们开始讨论创建特性团队的方法。
在对话期间，团队还提出了组建特性团队的如下问题：
并非每个团队都有实现下一个优先级条目所需的技能和知识 跨不同架构组件的特性实现的设计可能会变得混乱 特性团队可能会卡在设计决策上 所有这些都是重要点，因此我们决定从一个特性团队开始（“*指南：过渡到特性团队*”），而不是大张旗鼓。我们创建了一个特性团队，并要求他们端到端地交付特性。我们遵循XP（极限编程）的建议，为每个组件引入了“组件牧羊人（Component Shepherd）”作为导师，以避免最初出现任何技术故障。
“组件牧羊人”的主要作用是指导特性团队改动相应的组件，并在团队进行改动时提供利弊对比。所有牧羊人都更像旅行者（“*指南：旅行者*”）那样工作，因此他们大部分时间都可以自由地辅导和指导多个团队。团队逐渐地（9-12个月）积累了多个组件的知识，从而很少再需要“组件牧羊人”的指导。
过渡到LeSS Scrum的实施对我们最初的两个团队工作良好。我们提供的最初产品收到了客户的良好反馈，从而引起了其他潜在客户的极大兴趣。我们的潜在客户喜欢我们交付的特性，但他们也希望产品中有许多新功能。一旦有更多的客户注册了我们的产品，我们就决定增加更多的团队。
我们没有多团队合作的经验，因此开始探索可用于帮助我们的资源。我们发现了两本书，分别是Craig Larman和Bas Vodde撰写的《*精益和敏捷开发大型应用指南*》和《*精益和敏捷开发大型应用实战*》。对于我们的案例，它们看起来像是完美的指南，尤其是关于大规模Scrum框架2（现为巨型LeSS）的概念，因为我们预计将来会增长到大约20至30个团队。
这些书籍在提供有关规模化（以及由此对组织提出的挑战）的准则方面如此丰富（现在仍然如此），以至于它成为我们在整个过程中进行规模化的指导力量。我们开始定期探索这些书中的想法，并进行了一本书中的许多“*尝试和避免……*”的实验。
多地点的离岸开发 尽管我们强烈推荐在同一地点办公，但我们在当前办公室的物理空间仍然受到一些组织上的严格限制，并且需要与位于不同时区的客户进行互动。当我们要求管理层（执行委员会）提供额外预算（主要是更多的团队）时，他们要求我们与位于印度和基辅的现有离岸合作伙伴进行合作，以确保我们在多个时区都有团队存在（主要是中东和澳大利亚）来吸引和支持我们的新客户。
我们接受了挑战，但有一个条件，即一旦选择供应商，我们将像在英国一样进行面试和组建团队，而不是接受下一个可用人员或团队的典型离岸模式（“*避免……外包商说，交给我们吧，我们为您做到敏捷*”）。我们还决定在每个地点都有一些位于同一地点的团队（“*指南：在LeSS中组织多地点办公*”），以确保团队之间能够相互学习，这只有在同一地点的团队中才有可能。我们还将把离岸团队带到英国至少进行4次Sprint（“*尝试……离岸之前先在一起进行几次迭代*”）。
我们以为在管理方面会遇到困难（基于过去的类似经验），但是令我们惊讶的是，在开始离岸供应商选择流程之前，我们的管理层和离岸合作伙伴都毫不费力地达成了一致。我认为他们了解过去离岸团队的加入一直很痛苦。但是当他们意识到我们一直在以新的工作方式交付成果时，他们允许我们尝试与离岸团队合作的方式。
我们办公室内的多地办公体验 我们与团队讨论了多地办公的试验，并确保不会对他们的工作产生任何影响。因为他们也知道我们需要更多的团队，并且对物理地点有很大的限制。尽管大多数人都有多地办公的经验，但这不是我们最近的（检视和调整）工作方式。在对话中，一名团队成员问，在敏捷环境中与多地的团队合作感觉如何？由于我们都没有与多地敏捷团队合作的想法，因此团队中的一位成员给了我们一个想法，即我们在其它地点加入新团队之前，先要经历多地环境的挑战。她建议“为什么不将现有的一个团队搬到另一楼层，而仅使用电话或Skype与另一团队进行沟通，即 没有面对面的交流，看看这带来了什么挑战。我们非常喜欢这个想法，它与书中的一项实验一致（“*尝试……即使位置靠近也按多地思考*”）
一个团队在下一个Sprint搬到的另一楼层（幸运的是，我们在那层上有一个可以容纳团队的空间，但只能用2周）。很快，我们可以看到，即使他们位于同一栋大楼且只有一层之隔，团队也意识到了多地办公向他们施加的挑战。尽管他们已经合作了很长时间，但是无法看到他们，只能通过电话、电子邮件和Skype进行交流，他们还是因此失去了紧密的物理协作（例如白板会议）。
这是一个很好的实验，可以为即将到来的“离岸团队”建立“现场”团队的同理心（这就是他们一开始的看法）。
离岸合作伙伴的选择 我们访问了三个地点（印度两个，基辅一个），并受到了所有人的热烈欢迎。
这些人都从大量的Powerpoint演示开始，介绍了他们的“敏捷”能力和已交付的“敏捷项目”的经验。 很快就很明显，他们对敏捷工作方式的大多数理解都是“错误的”。一次又一次的演讲，很明显这些团体要么是在大肆宣传，要么是对他们所说的“敏捷”一无所知。我们认为他们在“创建Powerpoint幻灯片”方面要熟练得多，但通过交付迭代和增量的软件来交付持续的价值呢？不见得行。
我们想知道为什么他们对敏捷的工作方式没有这么了解。毕竟，这些公司可以访问所有内容（培训、书籍、聘请顾问和教练等以帮助他们）。我真诚地问了他们的一位经理，以便从他们的角度来理解这个问题。他的回答非常有趣且提供了有用的信息，帮助我们了解了离岸IT公司的工作方式。总而言之，离岸公司不向客户提供咨询服务。他们的商业模式通常围绕以低廉的成本提供人员，并与客户期望他们工作的方式保持一致。因此，他们不会真正地投资任何新事物，直到成为主流，并且客户希望他们对新事物有所了解。
在拜访了所有离岸候选人之后，我们意识到这将是一个漫长、痛苦而又令人兴奋的旅程。因此基于跟他们的经历，我们建议仅从印度班加罗尔的那个团队开始。按照《精益和敏捷开发大型应用实战》（“*尝试……更少的地点*”）一书中的实验，我们不想从多个离岸合作伙伴的多个地点开始，以创建不必要的复杂性。
“商业部门”推动我们同时使用这三个地点。但是，当我们向他们解释了多个地点及多个合作伙伴的负面影响（沟通、协调失灵、语言和文化差异、与其中一个地点的签证问题等）之后，尤其是在敏捷开发环境中，我们被允许先选其中一家，但他们还是期望将来可以用所有的三个地点。
除了上述提到的多个离岸地点的负面影响之外，我们还希望保持组织的简单性，并继续我们*成为敏捷(be agile)*而不是*做敏捷(do agile)*的旅程。我们已经在Scrum和Extreme Programming工程实践方面有了一个良好的开端，我们希望增加更多的团队，但不增加任何不必要的协调、离岸管理等开销，以保持以客户为中心。基本上，我们希望通过消除客户和团队之间任何不必要的复杂性来简化组织，从而扩展产品的开发规模。在成功试验两个地点（英国和另一个地点）之前，我们致力于避免不必要的、人为的管理多个地点的复杂性。我们深知与离岸IT公司合作会带来不必要的开销，例如与项目经理、现场协调员、离岸项目经理、多个时区等打交道。
当我们自己试图简化组织设计保持以客户为中心时，我们理解了为什么“商业部门”会迫使我们选择这三个地点。高层迫使他们将新工作移至离岸地点以降低成本。他们表现得像一个会计师（还是一个很好的会计师），却不了解其行为的整体系统含义。简而言之，这是经典的*局部优化*。
我们部门的业绩在整个组织中引起了积极的反响。我们的成功故事（高质量的产品、满意的客户、提早交付和持续交付、更多的业务等等）也触及到产品开发外部的各种人员（例如HR、商务等），他们对我们不同的做法感到好奇。我们邀请商务部门的人员与我们的团队会面，以便向他们解释我们的工作方式。这与LeSS的采用规则有关：“*对于产品组以外的大型组织，请使用现场现地（Gemba）来采用LeSS演进，创建以实验和改进为准则的组织。*”。访问我们的时候，他们惊讶地看到我们在部门内创建的可视化效果。他们可以轻松地查看我们的产品待办事项列表（墙上的故事地图），每个团队的Sprint待办事项列表（白板上），构建的统计信息（构建状态，缺陷数量等），监视器等，以及在地板上合作（主要是人们一起工作的噪音）（译者注：在地板上合作指的是大家走来走去，面对面的沟通）尽管来自非技术部门，但他们的反应是您为什么不采用这种方式工作，这是如此明显。他们还真心想帮我们跟离岸供应商协商一个更低的价格，如果我们愿意直接与10多个团队工作的话。我们礼貌地拒绝了，并意识到我们还有很长的路要走，以使我们的组织精益化和系统化思考。他们显然看不到增加10多个团队相比于1个团队来说的系统影响。他们只是从自身降低成本这一局部优化目标来看，而没有意识到这样做可能是增加了总体成本。
我们与离岸合作伙伴约定的条件之一（在我们决定与他们合作之前）是我们寻找“长期合作伙伴关系”，而不是临时的项目方式（“尝试……将离岸组织视为内部合作伙伴 ”）。实际上，这意味着：
我们将采用相同的工作方式（如Scrum和XP中的工程实践）和 相同的团队组成（跨职能和自我管理）。 我们还提供了帮助，以Scrum、XP和精益思想为基础，让离岸管理人员理解和适应工作方式，这样做我们实质上是忽略了组织边界。我们说过，我们将在最初的3-6个月内提供一名教练，以帮助他们建立和完善对精益思维和敏捷工作方式的理解。这位敏捷教练的费用不需要他们承担，因为我们将这视为与他们建立长期可持续伙伴关系的投资。
巴伐利亚汽车制造商的LeSS转型 背景 Valtech德国公司是选中的供应商，以帮助其应用敏捷开发来创建宝马集团的新*BMW i*汽车的直销流程。这需要新的IT支持系统，所有这些系统都已嵌入到现有的IT环境中，其中80多个系统会受到影响。有一个跨越许多项目的大型项目集来创建新的支持系统。
其中一个项目是新的统一销售平台（USP）系统。USP从头开始实现，集成了30多个外部系统接口。*BMW i*推出的其他合作伙伴项目，仍沿用非敏捷过程模型。因此，跨项目的共同里程碑、报告和协作成为一个挑战。
经过2年多的开发，USP按时发布，并具有很高的质量和客户（比利时-荷兰-卢森堡市场）满意度。
阶段1：在多个特性团队之前 2012年2月，USP在充满挑战的环境中开始开发：
时间压力大，因为上线日期已经确定 直销业务流程仍在讨论中，尚未定义 因此，USP产品的范围还不清楚 大多数参与者不熟悉宝马集团的业务、销售流程及敏捷方法 USP项目嵌入在传统的项目集（*BMW i*项目集）管理系统中 由于上述情况，USP项目决定使用Scrum和敏捷工程实践，来尽早和持续地获取有关产品进度和组织进度的反馈。敏捷开发从一个Scrum团队开始。这个团队建立了合适的敏捷开发流程，搭建了合理的开发基础架构，找到了与业务部门的协作模式，并为敏捷开发奠定了坚实的基础。
这个最初的团队评估了所需的工具，搭建了开发环境和持续集成系统，尝试了不同的Sprint长度，并实现了第一个业务功能，验证了新组织是否可以正常工作。
从第一个Sprint开始，USP团队在每个Sprint结束都演示了可运行的和经过测试的软件。
后来，团队增加了一些人，这些人以传统的职能和组件团队的结构进行了组织，这代表了更广泛的*BMW i*项目集中使用的标准模型。
在USP 1.0版本之前团队一直在使用这种结构。
阶段2：转变到多个特性团队与LeSS 当前的组织结构对发布1.0版本来说已经够用了。不过，作为教练我们预见到，对于下一个更大的版本，这种组织结构的扩展性不好。团队需要更灵活（敏捷），因为优先级和需求经常变化。团队需要能够从产品待办列表中选择不同的条目，并交付完整的端到端特性。此外，还需要减少特性的周期时间以缩短“上市时间(time to market)”。
在先前的组织中，团队只能做一种类型的功能或特定的组件工作。这限制了更改产品待办事项的优先级和团队灵活地“转到新工作”的能力。而且，专家小组间的交接和延误，延长了平均周期时间。此外，还增加了协调和集成的工作量和问题。
因此，根据我们的建议，团队同意重组为多个特性团队并同时采用LeSS。
我们的目标是创建五个新的跨组件和跨职能的特性团队。
由于现有的商业合同和项目集的政策，USP项目组无法完全重组为特性团队。例如，有一个UI设计治理小组负责整个程序的UI一致性。还有一个测试管理团队，负责协调项目集范围内的跨项目测试活动，并为整个项目集提供报告。这个团队不做测试工作；测试工作仍由实现团队自己完成。不过，测试管理团队对（实现团队）“未完成（undone）”的部分做出了贡献，例如组织外部公司做渗透（安全漏洞）测试。此外，按照项目集政策，这里还需要一个项目管理团队，汇报给上层的（传统）项目集管理团队并负责人员、设施和设备管理。
图 1: 阶段2的USP项目的组织结构 自设计特性团队工作坊 我们还达成一个共识，即通过*自设计团队工作坊*（LeSS实验之一），重组为特性团队。
团队花了3轮的时间（每轮20分钟）形成了符合愿景的组织：所有特性团队应能够独立处理所有利益相关者/请求者的产品待办事项。
在组建新团队后，他们创建了新的团队名称，找到了自己的团队空间，选举了Scrum Master和“首席”开发人员（由于政策原因，这仍然是必需的角色）。
整个团队的自设计工作坊大约持续了三个半小时。 有关自设计团队工作坊的详细信息，请点击此处
团队建设工作坊 自设计团队工作坊是一个很好的开始。但是在自设计团队工作坊结束时，有一些新成立的团队，他们必须应对新的动态。根据LeSS的说法，向特性团队的转变是对旧系统的重大更改。该项目组面临着两方面的扩展。一方面是跨团队协作，按照一个产品待办列表的优先级与所有团队合作。在LeSS环境中，Sprint仪式和同步会议覆盖了这一方面。第二方面与团队内的可用知识有关。所有团队都让团队成员了解不同的组件。这体现了团队中的一个瓶颈，因此这种情况是扩展的障碍。为了在系统层面上进行改进，需要改善团队内部的知识共享。另外，项目管理团队的目标是尽快使这些新团队重新发挥作用（尽快开始工作）。因此，项目管理为每个团队提供了进行额外的团队建设工作坊的机会。本次工作坊的目的是降低社交障碍，启动知识共享措施，寻找工作协议并在团队挑战中反思团队动力。
工作坊日程：
时长 主题 00:05 介绍、日程 00:10 破冰练习 00:30 团队知识模型 (agile world 2013) 00:45 一致同意的措施 00:30 团队愿景和团队章程 00:50 团队挑战 (室外) “有毒废料Toxic waste” 00:10 结束和反馈 03:00 社交：午饭或晚饭 {: .
