有很棒的Scrum Master，也有糟糕的Scrum Master。 还有伟大的经理、开发人员、测试人员、销售人员、邻居，也有糟糕的。人就是人–无论他们的职业或生活角色如何。 Scrum Masters也是人。就像每个职业一样，大多数人会随着时间和经验的增长和进步。有些成长比其他成长更快。
您是否有因为Scrum Master尚未消除障碍而继续困扰您的团队的障碍？还是团队内部或团队外部的沟通不畅，并且阻碍了您完成工作的能力？也许您觉得您的团队陷入了困境，而您的Scrum Master似乎对此无能为力。如果您的Scrum Master不是您希望的那样，您会怎么做？
首先，希望您的Scrum Master不断成长。请记住，您在某些时候也是开发人员的新手或测试人员的新手。早期，您可能编写了糟糕的代码，却错过了关键测试。了解您的Scrum Master最终会更好地指导Scrum的采用和成长，自我组织以及障碍的消除。但是这需要时间，就像您成为当今的开发人员或测试人员需要花费时间一样。
接下来，向他们伸出援助之手。你是怎样做的？这里有六个想法：
在出现问题时大声说出来 在地毯下隐藏问题根本无济于事。透明度是高绩效敏捷团队的主要优点。但是在提请注意问题时要谨慎。有些事情最好私下提出，特别是如果这对于Scrum Master来说是一个缺点。
鼓励您的Scrum Master 优秀的Scrum Master经常鼓励其团队。但是谁鼓励Scrum Master？当您发现Scrum Master为团队提供了帮助时，请让他们知道很感激。是的，这是他们工作的一部分，但我们每个人都需要时时给予鼓励。
与Scrum Master头脑风暴 花一些时间思考可能导致问题的原因，并与他们合作提出创新的解决方案。没有人能回答所有问题。两个头脑总是比一个头脑好。
别装作自己懂 有时沟通不清晰，或者需求没有明确定义。单纯基于假设前进是危险的，并可能造成障碍。Scrum Master可能不得不花费不必要的能量清除障碍。保持谦卑，提出问题，并确认您的假设。
请您的Scrum Master教您特定主题的团队或对其进行更新 促进个人成长的最大动力之一是必须向其他人传授有关该主题的知识。
最后，加紧引导 Scrum团队没有明确的”领导者”，Scrum Master也不是团队的”领导者”。敏捷团队正在自我组织。团队通常需要朝着正确的方向努力，但是让团队成员加强并领导sprint活动的各个方面是可以的（实际上更可取）。
完美的Scrum Master不存在。但是，您猜怎么着 - 您也不完美。因此，下次您要抱怨Scrum Master时，请后退一步，尝试了解他们在Scrum Master旅程中所处的位置，并伸出援助之手，使他们继续前进。Scrum Master将受益，团队将受益，您的工作关系将得到改善。这是双赢的局面。
关于作者
德怀特-金登 这是敏捷联盟社区博客文章。所代表的观点是个人观点，仅属于作者。它们不代表敏捷联盟的观点或政策。
原文链接
作者：Dwight Kingdon
译者：Bob Jiang
2020最后一天，回顾一下“折腾”的一年。我是一名爱“折腾”的Scrum培训师。
数字 年度总结我们就从数字开始吧。数字是最有说服力的。
网站 - Bob Jiang博客的一年数据如下: 总体来看，点击率很低。2021年可以考虑如何提高内容质量。
微信公众号 - （敏捷家AgilePlus，粉丝数5055；HiBlock区块链社区，粉丝数7937）
知乎 - （关注418，盐值709）
twitter - （粉丝678）
Telegram - （Bob和他的朋友们59）
Youtube - （订阅372）
Bilibili - （粉丝161）
从数字来看，2020年结果很普通。没有抢眼的数字。
最主要的平台还是在微信公众号。另外需要提升的是知乎（权重高）的关注。
阅读 2020的阅读几乎都在微信读书的听书完成的。一共读了20+本书（只记住这么多，还有一些只听了一半的没有记录了。）
非暴力沟通 高绩效教练 用户故事地图 理查德费曼传 刷新 重来1，2，3 小狗钱钱1，2 断舍离 财务自由之路1，2，3 中间人经济 苏世民：我的经验与教训 无限的游戏 百万富翁的快车道 富爸爸穷爸爸 启示录 非对称风险 重构学习体验 社区运营的艺术 新家庭如何塑造人 建筑模式语言 行为设计学 掌控习惯 超级天使投资 影响力 如何说孩子才肯学 精力管理 大教堂与集市 这些书主要分3类：
此条目是作为”支持敏捷采用”计划的一部分而编写的，该计划是一项致力于支持组织及其员工变得更加敏捷的敏捷联盟计划。 生活中有些问题根本没有好的答案。”我们为什么做梦？”，”我们独自在宇宙中吗？” 和”谁杀了吉米-霍法？” 属于此类别的另一个问题是”敏捷组织结构是什么样的？”
然而，这是我发现自己在今年12月于斯德哥尔摩举行的”支持敏捷采用”~sources~(~‘Supporting*20Agile*20Adoption))~searchTerm~’~sort~‘createdDate~sortDirection~‘desc~page~1))研讨会上与敏捷同事和同事一起思考的问题之一。（要收听研讨会中某些主题的摘要，请收听此敏捷教练网络*播客的这一集。）*
组织设计是既不是”正确”也不是”错误”的事情之一。就是这样 组织选择管理其工作的方式反映了它认为有价值的东西：组织结构包含对一种组织立场或另一种组织立场的偏见。
一些组织重视清晰度。分层结构有助于描绘命令链，并在决策制定中创造可预测性。面对棘手的情况，不知道该怎么办？只需问问您的经理，她就会告诉您接下来的步骤。如果没有，她会问她的经理，依此类推。将会得到答案；方向将给出。
当然，尽管获得了好处，但是这种组织方式也面临着许多挑战。层次结构往往会忽略思想的多样性，遇到模棱两可的情况时决策速度可能会很慢，并且无法很好地适应复杂的环境。这是敏捷组织越来越多地寻求组织工作的其他更现代替代方案的原因之一。
例如，Spotify的组织结构方法倾向于优化以创建可持续发展的团队，并专注于其产品的特定元素。正如Spotify的Marcin Floryan向我解释的那样，工作被带到了团队中，以便这群人可以在相当长的一段时间内一起工作并表现得更好。例如，一个团队可能会专注于其Podcast产品的元素，并会在一段时间内专注于该领域。当业务需求发生变化时，同一团队可能会将重点转移到产品的其他元素，例如用户的个性化播放列表或推荐。这种结构是自然产物，人们会偏见-绝非偶然。
尽管这种组织方式对于团队清晰，团队间协作和友善而言可能是很好的选择，但Marcin坦承，它也面临着挑战。当团队位于同一地点时，这种组织结构会很好地工作，但是当员工以分布式方式工作时，这种组织结构的效率就会降低。随着组织规模的扩大，分散的团队往往会成为规范，而不是例外，因此，即使在Spotify，这也不是简单的方法。随着团队时间的流逝，这种结构也会给性能带来挑战。正如Heidi Helfand在”动态再分配“中所指出的那样，团队（和组织）经历了自然的”生态循环”，实际上，中断可能是必要且健康的–使团队保持完整状态的时间过长可能会适得其反。
随着12月周末小组讨论的发展，我们同意组织结构在最大限度地提高VUCA商业环境所需的业务敏捷性方面存在固有缺陷。还有其他比喻可能更好地说明敏捷组织如何努力组织自己吗？
在这种情况下，也许寻找自然并研究有机物可能会有所帮助。Bossa Nova的顾问兼合著者约翰-巴克（John Buck）指出，人脑在尝试学习某些东西时会释放突触前蛋白*神经毒素，*以寻找建立新突触所需的位置。发生这种情况时，没有预设的结构或途径-神经毒素化学物质随新化学物质编码一起分配，该编码指定了新学习的要求。
这个概念是一个有力的类比：随着组织拥抱变化并有目的地执行，他们不仅要按照战略意图协调员工，而且还需要在业务条件变化时快速感知，学习和响应。这类似于大脑检测到变化并对新的适应做出快速反应时发生的情况。
然而，这种类比可能会很有趣，但感觉却很”自上而下”且层次分明。顶部有一个大脑，该大脑发出要做什么的信号，身体的其余部分只是做出反应，并不自己思考。
那么，更贴切的有机类比可能是看一个柔软的八足头足纲动物-章鱼。这种软体动物具有极其复杂的神经系统。实际上，其三分之二的神经元都包含在无脊椎动物自己的触角中，因此您可能会认为章鱼有多个”大脑”。这意味着章鱼的身体部位可以做出自主决定，而无需响应自上而下的命令。章鱼也是著名的抗衰老产品。如果将手臂移开，它会立即开始重新生长过程，从内部神经束到其外部吸盘，一个非常细小的触手重新生长。谈论创意破坏！
就像爱立信执行官和SAA计划主管Hendrik Esser在我们的研讨会上宣称的那样，这也许意味着组织”需要变得更像章鱼！” （我承认这句话，我从没想过我会在敏捷领导力研讨会上听到。）
这种类比在理论上很吸引人，但是在组织环境中应用时并没有那么简单。在实践中，”大脑”将如何协调组织中的决策？就像章鱼一样复杂，它最终是一个具有确定的静态目标的无脊椎动物-获得食物并繁殖。分散，自主的决策如何转化为需要处理更复杂问题的组织？
那自私呢？章鱼-整个身体-具有战略意图。大脑的自我利益与触手中神经元的利益完全一致。没有一家公司可以竞争成为Octopus，Inc.的首席执行官。但是，在一个组织中，这对组织最有利，对本地市场或部门主管而言可能并不最适合，这看起来像什么？当需要协调利益冲突并以某种方式将其付诸实践时，这意味着什么？与章鱼类比一样，内容丰富且发人深省，当我们尝试在组织环境中翻译许多概念时，它很快就崩溃了。
最终，我意识到组织结构旨在创造的是*其员工之间共享的现实感*。一种及时共享信息的方式，可以在为组织创造价值的决策上进行。速度，协调和协作至关重要-您的工作环境将定义组织的外观。
因此，没有单一的”敏捷组织结构”，我们可以将其插入组织并神奇地期望敏捷会出现。没有超自然的或有机的类比-不会像彩虹一样跳跃的独角兽或光荣的海妖-会巧妙地解释敏捷组织如何管理其工作流程。
相反，正如我在”解锁敏捷性“中所解释的那样，在Jutta Eckstein和John Buck的” Bossa Nova ”中进行了阐述，并在超越预算之外的领导模型中进行了进一步定义，这些类比法启发了我们。我们在采用更敏捷的工作方式的组织中始终看到的价值观，行为规范和行为模式。
这些列表虽然并不详尽，但在成功的敏捷组织中我始终观察到以下关键特征：
考虑到客户的端到端视角：内部交接以及开发产品的人员和团队与接收产品的客户之间的距离最小。 实现共同目标的自我组织：人员，团队和组织结构有机地演化以提供客户价值。 致力于持续改进：敏捷不是您要成为的东西；这是你变得*更多*的东西。敏捷组织不断学习，明天会比昨天更好。 人们感到安全，有权做正确的事：高管和领导者致力于营造心理安全的环境；人们可以在边界内做出自主决策。 尽管那个12月周末在斯德哥尔摩举行的研讨会没有提供有关敏捷组织结构的答案，但它有助于弄清到达那里所需的工作。业务敏捷性不是目标；”拥抱变化并有目的地执行”是一项持续的工作。公司的组织设计只是成为更加敏捷的组织时要考虑的维度之一。
哦-毕竟，我确实得到了今年12月回答的那些不可能的问题之一。马丁-斯科塞斯（Martin Scorceses）出色的《爱尔兰人》生动地揭示了谁杀死了吉米-霍法（Jimmy Hoffa）。但是您必须亲自查看它才能获得答案–不会破坏自己！
资料来源：
https://en.wikipedia.org/wiki/Octopus#Nervous_system_and_senses https://blogs.scientificamerican.com/octopus-chronicles/how-octopus-arms-regenerate-with-ease/ https://www.amazon.com/Unlocking-Agility-Enterprise-Transformation-Addison-Wesley-dp-0134542843/dp/0134542843/ref=mt_paperback?_encoding=UTF8&me=&qid= https://www.amazon.com/Company-wide-Agility-Beyond-Budgeting-Sociocracy/dp/154467287X/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=1577785309&sr=1-1 https://www.amazon.com/Implementing-Beyond-Budgeting-Unlocking-Performance/dp/111915247X/ref=sr_1_1?crid=C1S9Y1PA33IC&keywords=implementing+beyond+budgeting&qid=1577785340&s=books&sprefix=implemenrting+beyond+%2Cstripbooks%2C266&sr=1-1 https://www.amazon.com/Dynamic-Reteaming-Wisdom-Changing-Teams/dp/1733567216/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=1577785892&sr=1-1 https://en.wikipedia.org/wiki/Neurexin https://elifesciences.org/articles/35692 原文链接
作者：Jorgen Hesselberg
译者：Bob Jiang
疫情开始后，许多习惯去办公室的人正在家里工作。 我本人大部分时间都待在家里，避免与同事和朋友，尤其是65岁以上或有医疗问题的同事和朋友进行面对面的交流。
这意味着更多的远程会议，远程工作会议和远程社交追赶。（我的读书俱乐部将在周日通过Zoom开会。）
我们如何才能充分利用远程会议的优势？我主张所有会议都采用轻量级的结构，但是在远程会议中，结构更为重要。
我发现这些简单的更改大大改善了远程会议。 提前发送目的和议程，然后在会议之前重新发送。目的解释了会议的原因，议程解释了到达会议的步骤。在议程的基础上，需要一个过程来帮助该小组共同思考和决策。在会议开始时检查目的和议程。对于每个议程项目，在达到这一点时都要说明其过程。在开始时说明整个会议的过程可能会使人保留太多细节。 在会议开始时，介绍您正在使用的工具-如何静音和取消静音以及其他相关操作。提供一些有关交互的准则。例如，在四人或五人以上的会议中，我要求人们静音，除非他们讲话。 考虑在会议开始时添加简短的签到。可以理解的是，许多人感到担忧和压力。签入可以使人们有空间共享他们所发生的事情，并帮助他们暂时搁置它。这也可能是预示着可能会有孩子在后台徘徊的时候。 指出您何时完成议程项目并继续进行下一步。检查以确保每个人都准备好继续前进。如果您正在观看视频，则可以要求一个肯定的信号。如果有人在音频上，请问”谁能为此做出更多贡献？” （”每个人都准备好继续前进了吗？”这个问题是不可靠的。） 尽可能使用结构化的问题和活动。如果您打算进行任何活动（如回顾活动），请选择可以单独进行的活动，除非您拥有带分组讨论室功能的视频或允许所有人参与的工具（例如，Miro）。 发送带有会议议程的会议中您将要引用的所有URL（例如google doc）。如果您打算参考数据，则即使在会议期间要使用屏幕共享，也要提前发送。当您无法控制滚动时，实时吸收数据最多是困难的，通常是不可能的。 如果您有提示和资源，请在下面的评论中发布它们，我将在以后的帖子中分享。
好好照顾好自己和周围的人。有了准确的信息和合作，我们将解决这个问题。
关于作者 埃丝特-德比 这是敏捷联盟社区博客文章。所代表的观点是个人观点，仅属于作者。它们不代表敏捷联盟的观点或政策。
原文链接
作者：Esther Derby
译者：Bob Jiang
敏捷是老套领导力无法比拟的。过时的领导力注重的是管理和工人的分离；如何更好的把敏捷明道理实施落地，1. 专注于集体智慧；2. 创造创新的心理和职业安全；3. KPI和奖励基于价值创造而不是利用价值
本文从超越预算来分析OKR（目标与关键成果），主要从三个角度来分析和质疑OKR（但并不是否定OKR）。相比国内一味的追捧OKR，这是一篇不可多得的文章。
写在前面 非常感谢 ETH123.org 的启发，在以太坊资源大全网站上线的时候，给我提供了灵感。尤其他们的网站是开源的，我可以直接 fork 下来进行改造即可。真心感谢ETH123.org，尤其还是感谢以太坊爱好者的曾汨和开发小伙伴。（帮我解决了一个技术问题）
还有哪些需要优化 目前还有几个地方有待进一步优化：
收集更多的敏捷相关学习资源 制作 Agile123.net logo 每个资源（网站）的logo收集 对于资源分类的建议 任何想法和建议，都欢迎在 github 上面提交issue。
目前有哪些资源 敏捷学习资源分类 当前的分类如下：
热门推荐、社区、敏捷框架、Scrum专区、大规模敏捷、产品设计、DevOps、敏捷度量、意见领袖、工具、资讯、博客、咨询公司、敏捷图书、敏捷实践等
收集的敏捷学习资源网站 这里就不一一列举了，如果你的博客，网站也想收录进来
欢迎在 github 上面提交issue。
最后，如果你认为这个站点对你有帮助，欢迎分享给更多的伙伴。
谢谢你的分享。
CSM培训总结 为期4天的CSM培训结束，自己对敏捷有了更深的认识，scrum是一种轻量级的框架，但却有着功能强大的价值观，原则和实践，主要体现在团队能在短期内能够尽快地响应变化，交付产品，快速反馈，适应变化，连续提升，相比较使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素（内部和外部因素）的复杂度增加，项目成功的可能性就会降低。
在scrum 三个角色当中，我觉得SM相对来说比其他两个角色重要，SM作为team leader和PO紧密地工作在一起，可以及时地为团队成员提供帮助。他的职责在于以下五点：
保证团队资源完全可被利用并且全部是高产出的。 保证各个角色及职责的良好协作。 解决团队开发中的障碍。 做为团队和外部的接口，屏蔽外界对团队成员的干扰。 保证开发过程按计划进行，组织 Daily Scrum, Sprint Review 和Sprite Retrospective。 SM除了主持Daily Scrum之外，还有三个主要职责：
SM需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估计可能已经发生变化。 SM需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的条目。 SM还必须仔细考虑进展中的任务数，进展中的工作需要得到最小化，以实现精益生产率的收益。 SM需要找出阻碍 Scrum的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决，有些则要团队之间的协调，还有的要管理层的介入来解决，甚至有些是公司的问题阻碍了团队达到他们的生产力。
现在的工作模式基本是按scrum来运作的，在迭代开始前，会有需求清单(Product Backlog)，PO会把Product Backlog排出优先级，识别出更有价值的需求排在靠前，团队从需求清单中选择迭代中要完成的US(Sprint Backlog)，由SM给每个成员做任务划分，然后成员根据开发的周期输出自己计划，将US拆分成每天要完成的Task，每天上班先进行Daily scrum，反馈前一天完成了哪些任务，今天要完成的内容，其中遇到的一些问题，SM通过沟通，协调资源等多种途径解决在Daily scrum中反馈的问题，Sprint Backlog完成形成Increment，由PO和用户验收，之后团队进行Sprite Retrospective，总结出急需改进的Top问题以及继续保持的点。
不过还是有些差异，比如Scrum角色中的PO，只能定位作为一个决策者，团队在迭代过程中遇到解决不了的问题以及与其他团队协作问题等，才由PO来沟通，解决；而需求条目的澄清则由团队中专门负责需求整理输出的同事来承担，这可能是由于商业合作产生的这种模式。再比如迭代的周期都比较长，一个迭代至少3周甚至更长才能完结，迭代的交付时间中固定的，团队只能通过施压的形式，来要求团队成员按照交付时间点来完成产品Increment。
– CSM学员 宋
