企业级可扩展敏捷框架是一些原则和实践的集合，旨在为大型公司提供一种“扩展”敏捷工作模型的方法。自2011年成立以来，SAFe经历了巨大的增长。全球将近有一百万人成为SAFe认证从业者。
我实际上认为SAFe 非常糟糕。它宣称看似明智的价值观，然后转而强加了扼杀真正敏捷性的过程和结构。有许多质量各异的“扩展框架”，但特别是SAFe体现了最严重的误解和应用不佳的敏捷思维。
SAFe与敏捷思维方式不一致的许多方式应该很清楚。它以编程为中心的官僚主义、复杂、包括许多通常不必要的过程，削弱了团队的自主权等等。
SAFe实现官僚地自上而下的控制
在最高级别（称为“投资组合”），SAFe确实主张为不确定的“价值流”提供资金-通常代表产品，产品线或客户类型。但是，控制资金的精益项目组合管理团队（LPM）（以前负责瀑布式项目预算的人可能是唯一的权力）批准每个流向哪些项目组合（大型计划）。Epics并不是对需要解决的问题的解释。它们是关于如何最好地解决这些问题的预先形成的想法。
高级思想者提出想法，低级思想者执行那些想法。忽略了最接近工作的人可能最有能力做出决定的可能性。
SAFe将小型产品团队（通常是Scrum团队）召集到“敏捷发布培训”中，这些团队具有额外的管理角色层，这些角色包括产品经理（PM），系统架构师（SA）和发布培训工程师（RTE）。在“编程级别”中跨每个组，通常，这些角色会阻碍团队的自治。它们与提供的价值成比例地增加了流程和通信开销。
SA和PM定义并分解较大的工作（通常从上面的投资组合过程继承），然后将这些工作传递给团队，从理论上讲，产品负责人和团队可以会优先考虑其他较小的工作，而不是强加于他们的工作，来自最高层领导部署的工作视为最重要的工作就具有自然的压力。因此，产品负责人的角色必须被简化为撰写故事和检查验收标准，而不是作为产品领导责任的单一最初意图。
系统架构师无法接近实际的工程工作，因此他们传递的体系结构计划可能与工作的实际情况脱节。这些角色是大型设计前瀑布项目的标志，并且在SAFe中得到了很好的保留。
发布培训工程师定义一致的跨团队流程和节奏，并处理许多操作任务。最终，这为单个团队留出了更多空间来修改，改进或试验自己的实践，而这些实践都偏离了既定标准。
有时，所有这些问题都会通过添加“大型解决方案级别”而再次重复出现，“大型解决方案级别” 是一组团队，每个团队的角色与编程级别的团队相似，但跨越发行培训。发生这种情况时，很可能会重复同样的问题，但是解决方案级别似乎不太常见。
SAFe采用最差的方法来管理依赖项
依赖关系是团队需要等待其他地方完成一些事情才能完成自己的工作的实例。SAFe的构造是一种倒退的态度，即依赖是生活中不可改变的事实，有时甚至将它们称为战略优势。以下是SAFe未重视甚至完全忽略的一些建议：
- 鼓励内包(inner-sourcing )文化，一个团队可以将工作提交到另一个团队的代码库，而不必依赖于他们，而不必接受合并
- 使团队成员可以在需要时轻松地临时或永久交换团队
- 专注于雇用，组织和培训团队，无需外部帮助即可满足自己的需求
SAFe实际选择如何管理依赖项是通过更加关注计划、流程、层次结构和标准化。可以预见，这将导致大量会议干扰完成工作的能力。它通过一次全面推广而强加了这种方法，该推广会立即影响整个组织。如果没有其他繁琐的结构，就不会考虑在哪些领域可以让团队自力更生。
SAFe过度围绕编程
SAFe的一项核心功能是大约10周的编程增量（PI）。您可以想到包含所有常规Sprint的大型Sprint。
每个PI都以PI编程活动开始，该活动持续约两天。PI编程还需要在编程级别进行前编程和后编程活动。
让人们亲自聚在一起建立关系，共享信息并围绕目标定向无疑具有一定的价值。另一方面，使用有限的时间窗口根据预先定义的功能为特定的用户故事制定10周的计划，然后要求对这些编程做出承诺，其价值将大大降低。
一旦PI编程结束，一旦学到新知识，那些基于有限理解和众多假设而创建的编程将被淘汰。团队将不断地陷入没有意义的工作和重新定位期望的过程中，原因可能是他们之上的人可能无法理解的原因。
SAFe围绕数量而不是价值
在所有关注量度指标、估算和通过管道进行变动的工作中，很容易失去真正有价值或成功的概念。
SAFe意识到它不是以价值为中心的，并且最近在其文档中增加了“设计思想”，“以客户为中心”和其他概念以弥补损失。到目前为止，我还不相信它会在其过程中进行任何重大更改，而这些更改实际上为这些事情留出了空间，并且甚至一开始就理解它们也感到很困惑。
SAFe不必要地复杂
SAFe具有天生的优势，可以防止受到批评。它是如此复杂，以至于难以完全理解。尽管我花了很多时间研究框架，但我仍然可能会出错或遗漏某些重要方面。但是，复杂性本身就是一个合理的问题。SAFe有如此多的会议，检查点，价值和方法，几乎不可能使每个人都在同一页面上。
SAFe限制回顾和持续改进
编程级别及更高级别的角色可能无法参加所有团队回顾。这意味着实际上可以改变许多正在讨论的事情的人们将不会直接听取回顾。
SAFe试图对此进行补偿的方式还不够。
SAFe降低了其汇总的概念
SAFe的关键是现有概念的集合，例如Scrum，看板，精益产品，精益用户体验和DevOP。如果您不熟悉，建议您随时间推移而不是一次全部探索每个概念。许多功能本身很有价值，但是SAFe不能在实际合成它们方面做得很好，有时会增加混乱。
SAFe通常会拥护其实践遵循“精益敏捷”原则。诀窍在于，“精益敏捷”实际上并不指“精益”或“敏捷”原则。相反，“ 精益敏捷原则 ”是SAFe自己设计的创造。这套新的“原则”扭曲了它所吸收的概念。
SAFe不敏捷
到目前为止，SAFe与敏捷思维方式不一致的许多方式应该很清楚。它以编程为中心的官僚主义、复杂、包括许多通常不必要的过程，削弱了团队的自主权等等。
事实证明SAFe起作用的所有案例研究如何？
scaledagileframework.com上有约40个成功采用SAFe的案例研究。失败的案例研究明显缺乏。相反的缩写，安全涉及跨越一个巨大的生态系统为一到一个巨大的新的进程同步变化巨大的风险。除非这40家成功的公司中的每家都拥有11,250名获得SAFE认证的从业人员，否则我们不会听到很多公司的消息。
2016年，消费技术公司Fitbit向市场发布了四款受到消费者好评的新产品，并出货了超过2200万台设备。一年之内交付最多产品的部分原因是该公司对SAFe （Scaled AgileFramework ）的承诺以及成功采用SAFe 作为扩展团队以达到目标日期的一种方式。
现在，我们无法真正将Fitbit的失败归因于我们拥有的信息量对SAFe的采用。但是，如果一家公司可以为此付出很大的努力，并且仍然希望采用SAFe来提高他们的产品决策的响应速度，那么在检查其余案例研究时，我的视线会更加狭窄。
这是过渡步骤，对吗？
SAFe路线图中没有任何地方实际上将其任何核心实践称为过渡性的。如果这是一个过渡框架，那么在提供任何类型的过渡计划方面都做得很差。
对认证的过度关注也损害了框架的灵活性。如果您花费大量的时间来获得认证，认证将成为您自己价值的一部分。
点击标题见原文