回归事物最基本的条件，将其拆分成各要素进行解构分析，从而找到实现目标最优路径的方法 - 马斯克

每个系统中存在一个最基本的命题，它不能被违背或删除 - 亚里士多德

"Scaling Agile": At base, you need competent Agile teams. Sine qua non. If you have competent Agile teams, scaling becomes nearly trivial. - Ron Jeffries

敏捷转型对于企业的本质思考

敏捷的第一性原理是什么

敏捷在中国发展到今天已经不是一个新鲜的事物了，从五大行到城商行，从通信企业到现在的汽车，新零售行业，有趣的是每一家在最初尝试敏捷从0到1的阶段甚至是从1到N的阶段中大家背后的动因都在无限的趋同种，我们想借这个平台与机会来谈一谈的内容便是，敏捷背后的第一性原理。

如果一定要回归到敏捷的第一最基本命题，我个人的理解是敏捷是一种可以影响到组织，甚至个人的核心思维方式的改变 -- 组织的迭代式演进，组织能够通过不断的迭代式的试错学习从而调整到一个最适应组织当下的状态。再要追根溯源的话，敏捷背后的动因以我们的调研和学习发现是希望打造一种复杂自适应系统。只有在形成复杂自适应的条件下，对抗外力的变化可能性才能无限的提升。

因此，总结一下来说：

于组织角度，敏捷的第一性原理是成就一个具有进化能力的，会思考的组织。

于个人角度，就是不断的通过迭代来优化自己，让自己随着组织共同学习并且进步。

插图：敏捷的业务价值

一个大型组织为何需要敏捷

对齐，一定是对齐，确保信息足够的透明，保持一致性

很多组织都在谈我们需要战略对齐，让整个组织共同对着同一个战略目标而努力。结果发现最难解决的问题正是组织的对齐。对齐需要从多种不同视角来呈现，主要可以分为年度的战略目标对齐，季度的里程碑目标对齐，月度/双周的发布版本对齐。

插图：组织的心跳

假设一个大型的正在做数字化创新的组织，从以上的三个视角都没有对齐，那么每一个迭代的方向都可能是各不相同的，对于组织产生的伤害以及投入的成本都是巨大的。组织规模越大，成本消耗与浪费也将越大。

根据我们多年的实施咨询项目的经验以及多年来在办公室里摸爬滚打的经验来看，组织方向的对齐本质就是组织高层中层的对齐。很多企业和大型组织中存在着巨大的部门壁垒，阻碍着多端的对齐可能，无论是自上而下的对齐还是横向的对齐，都是为了确保组织是朝着一个共同的方向前行的。在我们实施过的规模化敏捷企业中，大多都会引入一种PI Planning的大型workshop方式来使得组织自顶向下，自底向上的动态对齐目标，这样一定程度上解决了各做各的，互相同步信息不及时的问题，也为组织提升了一下活力，每个季度完成一次组织上下的大规模的互动，也一定程度上提升了组织成员的凝聚力，管理者也可以借用这一平台宣传组织的发展方向。可谓达到一举两得的效果。

当然这里一定也有人持不同的想法，因为有一些组织就是可能完全松散耦合存在，各自孵化着各自的小产品独立运营。那么此时我们需要的更多是一种企业文化与战略规划上的宣传。对齐目标仅仅是一个目标愿景的对齐了。这个部分我就不在此问赘述了，也请各位读者来关注我的公众号，我们会更深入详细的探讨从系统思考角度来论证什么时候需要PI Planning这样形式的工作坊/会议，什么情况下并不需要。

规模化敏捷的几大误区

根据服务过多家跨国银行，保险公司，汽车行业的客户公司的经验。我们总结了如下的一些误区

认为人数一旦规模化，敏捷也就规模化了，其实架构也应该考虑规模化

规模化一直以来对于组织是一个很大的考验，不管规模化什么，可能是某一个工具链，某一种技术实践，某一种文化理念等等都可以被所谓的规模化，那么敏捷自然的大家就想到是否可以规模化。

那么敏捷的第一性原理与本质我们也有过一些探讨，各位可以思考一下如果一个团队甚至个人可以实现敏捷化转型，自然的一个超大型组织自然也是可以被敏捷化的。于是乎就有很多组织试图尝试将每一个业务部门都与IT或者供应商形成强大的跨职能敏捷团队进行规范化的敏捷化处理，为此也定义了详尽的“敏捷”流程，然而短期内并未发现比过去更好，有些情况下可能相反更糟了。

我们也在许多企业中实践过此方法论下的全民敏捷广播体操活动，结论不完全不好。因为规范化总是有效的，但是很多时候也是无效的，原因是不能按照规范要求“敏捷起来”的团队背后原因都有一个有趣的共性，那就是虽然业务线被严格的设计好了，story也认真的拆分成功了，但是底层的服务却没能很成功的形成一定的独立性，因此就成了如下图所示的样子

1. 虽然是我的业务，但是服务却在你这里，于是本来不需要沟通的部分却成了沟通讨论的增项环节

2. 对应端上开发的敏捷团队（APP，小程序等）与中台团队对接异常的困难，端上的逻辑层似乎就成了一种单纯的调用关系而不是逻辑封装

在迭代中演进并且取得某种意义上的平衡态才是我们需要认真考虑与总结的，换言之，我们的架构如果不够支持可扩展性，那么自然的，扑上再多的人跑的再标准的“敏捷规模化实践流程”也仍然减少不了各种复杂的沟通过程。

插图：架构的一纵一横两大难题

必须定义足够的细节规范才能确保大家正确执行敏捷

在初期导入以及实践过程中，我们是否碰到过类似的问题

• 究竟定义到怎样的边界才是epic，feature，story，如果没有feature是不是跑不起来了，如果各业务部门的需求类型有不同，那么应该怎样做适配还是说完全套用我们定义的所谓“组织级”分类和工作流？

• 企业接入了许多开发供应商，各自都有着自己过去引以为傲的“敏捷最佳实践”

• 由于人员层级，角色，供应商或者IT部门等等复杂因素的结合，因此不同角色之间如何分清楚角色边界，新引入的例如Scrum Master，DevOps SRE到底该干什么也成了首当其冲的问题

以上三类问题也只是作为一种抛砖引玉，事实场景可比这个更复杂，我们总是希望大家可以足够的简单起跑，可总是有人希望事情该规划的足够细致入微才可以不出错。管理究竟是简单有效还是复杂有效呢？

基于我们过去的经验，我们也尝试着定义过许多复杂的框架体系，希望团队能够在复杂框架体系下“健康”的成长，然而总是事与愿违，因为这样的结果往往带来的是消化不良。

根据我们的多年实施的经验总结，组织就应该根据现状定义可接受的框架式的实践流程，而不是一股脑的使用各类市场上常见而且看似最终形态非常有效强大的实践作为导入阶段的实践组合。那么此时对团队的不是适用，而是伤害了。

插图：演进式的最适配实践

究竟是全面敏捷还是局部敏捷

在我们服务过的企业中，有过全面敏捷的企业，也有过局部试点的企业。其背后的动因与目的各不相同。全面与局部各有优劣，但是从我们调研过的敏捷企业中发现，似乎全面敏捷化（这里特指更宽泛意义的敏捷思维方式）对于企业的战略对齐以及灵活性具有更深远的影响。

组织规模化的过程是齐头并进还是略有先后，这都无法明确成为一种定论。但是从我们已知实践过的企业中所得到的结论是，如果敏捷动因正确（外部环境压力，内部激活组织，形成创新文化，打破部门壁垒，形成学习型能力的组织等等）那么即使开始是局部的，最终也一定是全面的。

这里要提一下的是，假设有一天全面敏捷化的话，好处是什么呢？

这可能是一个深层次的自我认知并且自问自答的过程，因为可能起步的过程中，大家并不知道为什么要敏捷，自然就不知道为什么要全面敏捷。根据我们之前的讨论，本质上假设有一天组织敏捷了，那么团队会思考了，大团队组合也会思考了，组织也学会思考了。那么这艘大船就很清晰自己什么时候该调头，什么时候该加速疾行，什么时候该韬光养晦了。那么由此假设可以判断，至少全面敏捷益处肯定是不少的。

就像我们之前讨论过的最适配实践同样的道理，即便我们认为终点是正确的，最佳实践是美好的，但是组织在演进的整个过程是需要时间积累的。

如何成就一个规模化的敏捷组织

组织领导者的转型驱动力

组织的领导者是对于组织转型非常重要的驱动者，很多时候嘴上说的动因来自于外力，根本推动企业的或许就是这些我们实质上的领导者。这么说或许有片面性，也有人会认为可以带上我们的具有影响力的领导力的同事们，这样也是在推动着组织转型，很多成功的组织转型也的确是这么在践行着的。

试想下，如果关键领导者不动手不发话，那么基层影响力也是很难自下而上的带动组织转型的。许多类似的转型都止步于某一个小部门或者某一个大项目。因为组织领导者从中并不能识别出敏捷转型对组织整体能够带来的良性变化，仅仅将敏捷当作一种项目管理工具或者方法论，应用于一些特殊的“试点”项目中。毕竟转型是需要成本也可能会失败的。

根据我们的一些分析以及长期的观察，我们发现对于组织转型成功与否，决定组织方向的领导者都会有一些独有的特质，我们可以将其归纳为：

1. 具有一种长期坚持的学习与自驱力，具有这种特质的领导者能够及时的通过组织的某些转变（成功亦或是失败）都可以从中学到经验教训，也可以及时的思考并转身

2. 坚持以身作则，将转型作为一种可以外包给别人的领导者，那么转型最终也只是成了一个外包项目

3. 持有成长型思维，这种思维模式是非常可贵的，有些情况下我们总是看到一旦我们犯了某种错误，似乎就被判定为不可饶恕，而如果我们将任何失败或者错误看作是一种试错，而将每次试错看作经验财富，那么组织是具有正能量的，是会持续进步的。当然某些极端情况下，我们允许了大家试错，但是总是一错再错屡教不改，那么这种情况是不能被鼓励的。而是应该被深究原因的。

业务线+微服务+关键岗位

良好的业务线划分而不是草率的划分了业务线但是又不与实际的业务能力相匹配并及时调整，那么这样的组织架构设计大概率也只是感动到了自己吧。微服务也是我们开头说过的，架构是一个数字化组织的基底，如果基底乱了，业务再好也是无济于事的。最后关键岗位，我们要做敏捷转型，我们究竟是依赖于敏捷教练，还是scrum master，还是产品经理，还是BA，还是测试，还是开发，还是业务人员等等的。其实每一个岗位尤其是关键岗位应该精挑细选，经过统一认知的培训。

在过去我们的优秀实践中，有过一种方法，那就是集中优势力量，整合一套标准化教材，统一培训train the trainer，然后用TTT的力量再扩散到其他业务部门与团队中，能够快速有效的培养起一大波统一认知与工作方式相同的人员，当然我们也提过优秀的最佳实践的危险的。我们还需要从中识别中重要的关键岗位人才，确保大家的价值观与做事方式基本一致。

个人对于规模化敏捷的思考

组织是能够思考的，只是需要一些时间以及给予足够的信任

我们深信组织是能够学会思考的，只是组织速度快一些，有些则异常缓慢，但终究是可以学会的。

此处我们该不断的给予一些信任，以我本人过去多年的经验，我总是会不断的去找关键岗位的人聊天谈心，启发其思考总结，很多时候转变真的只是一瞬间。

不断的把你的，我的，变成我们的

最后想总结一点，这点也是我近1年来不断在做的事情，就是在组织中不断的强调，没有那么多的你的，我的，当有一天我们认识到这件事情是我们的时候，那么组织将会有巨大的改变。是我们共同创造了一个会思考的组织，是我们营造了一种共同创新的文化，也是我们共同维持了一个可持续的秩序，让组织不断的根据外部环境的变化而变化，真正成为动态自适应的平衡态的组织。

感谢禅道的邀请能够给予这么一个宝贵的机会提交自己的总结与心得。当然实际个人总结的内容篇幅远不止这些，也希望有志同道合的朋友加本人微信共同探讨共同进步。

作者是一个热爱音乐，热爱创作，热爱学习的中年男人。

微信个人号

微信公众号