一、SCRUM@SCALE（规模化敏捷）
规模：线性扩展，可运用到整个企业
为什么：提供一个整合单个Scrum团队的可扩展的线性框架。解决随着组织内的Scrum团队数量增长，最佳输出（可工作的产品）及那些团队的速率会开始下降（比如由于跨团队依赖和重复劳动等问题）。
名词解释：Scrum@Scale（名词）：Scrum@Scale是一个框架，在此框架中，一致采用Scrum指南进行运作的Scrum团队网络可以解决复杂自适应问题，同时高效并创造性地交付最大价值的产品。
定义：一个对Scrum进行扩展的框架。通过使用Scrum来扩展Scrum，它彻底简化了规模扩展。它仅仅包含一些Scrum团队，这些团队通过Scrum of Scrums和MetaScrums进行整合。
价值：同Scrum价值一致，以客户价值为中心。
如何开始：通过一个团队的成功实践来影响并扩展到其他团队。前提是团队扩展是在与组织的特定策略、产品和服务保持一致。
Scrum Master循环
团队级工作：使得工作高质量的流动起来、提高迭代速率、使得团队以可持续的创新方式运做下去
HOW-如何做：SoS是“团队之团队”
需要协作的多个团队组成一个“Scrum of Scrums”（SoS），开一个团队级别的“站会”（SDS），协调团队并移除障碍以交付价值。参与人员一般为每个团队的Scrum Master。
Scrum of Scrums Master (SoSM)-SoSM负责联合团队的发布
高管行动小组（EAT）：SoS不能移除的那些障碍的终点站。所以，它必须由在政治和财务上得到充分授权的人们组成，去移除那些障碍。EAT的职能是协调多个SoS（或者SoSoS）。和任何Scrum团队一样，它也需要具备一个PO和SM。EAT最好也像Scrum团队一样可以每天见面。每个Sprint他们必须至少见一次面，并且具备一个透明的待办清单。
工作内容：整个SM组织汇报给EAT，后者负责在组织内建立、维护和提升其打造的敏捷操作系统。EAT的角色是创建组织转型待办清单（一份经过排序的列表，包含待完成的敏捷举措）并确保落地执行。
持续改进和移除障碍，跨团队协调，和部署
SoS的目标是像个发布团队一样工作，因此产品部署也是其分内事，而决定发布内容则是PO的分内事。因此，部署的目标是：
持续流动式地向客户交付有价值的完成产品。
将不同团队的工作集成到一个无缝的产品。
WHAT-产品负责人循环– MetaScrum
MetaScrum：各个团队PO组成成的组织，整合多个代办清单。作为单独的团队运作，领导为产品总负责人(CPO)-产品总负责人与各个团队的产品负责人来协调优先级。他们以干系人以及顾客需求来对齐待办事项的优先级。
输出：战略愿景、待办清单优先级排序、待办清单分解和梳理，以及发布计划
连接SM与PO循环
反馈组件是PO和SM循环所交叉的第二个点。产品反馈通过调整产品待办清单来驱动持续改进，发布反馈通过调整部署机制来驱动持续改进
彻底的透明性是Scrum最佳状态运作的本质，但是只在能够拥抱Scrum价值观的组织中可行。它使组织能够诚实地评估进度并检视和调整其产品及过程
二、Less
规模：2～8个团队的产品
对Scrum Master的要求更高负责一个运转良好的LeSS导入。他们关注于团队、产品所有人、组织和开发实践。一个Scrum Master不只关注一个团队，而是整个组织系统。
Less产品：对整个可以交付的产品有一个产品所有人和一个产品待办列表
Less的迭代：统一开始，统一结束，产出的是一个集成的产品
迭代计划会议：第一部分团队共同做-各个团队代表，第二部分各个团队自己定计划
站会：各个团队内部，各团队问题的协调内部的，非正式的
迭代评审：全体的，所有团队
回顾：个体自己的。整个团队-派代表参与
Less巨型框架
规模：超过8个团队
结构：以客户的角度客户强相关的角度领域分组，导入需要几个月或几年
产品：产品领域负责人，负责优先级的排定
[if !supportLists]· [endif]迭代：产品层面的的迭代，每个迭代会带来一个集成的产品。产品所有人和领域产品所有人会频繁同步。在Sprint计划前他们确保团队都工作在最有价值的条目上。在Sprint评审后，他们在产品层面做出适应。
个人感受：
相较于Less，Scrum@scale更灵活一些。个人觉得Less中统一开始迭代、统一结束在实际执行过程中寻在困难。跨团队的人员沟通及协调也会存在问题。
