逃离敏捷

回想从2013年开始玩scrum到现在，真正能落地好scrum的团队很少，就出现过一个，动力板车团队、猛牛板车团队只能从协作方面来说做的很不错，但工程实践方面离持续交付还是相差甚远，持续交付只是针对研发内部一些实践，这在十年后依然这么多团队做不到十年前的构建失败后十分钟修复，然后仅仅是做了一些早会，和用户故事的单点导入，而且还是魔改版本，回头还说敏捷不行，这让我有点想逃离敏捷了，逃离之前先写写最近1年多做敏捷的一些感悟

在某公司专职做敏捷教练做了三个项目

2022 H1带领产研协作平台团队全面敏捷转型 ，打造敏捷样板间（内部产研协作平台团队）给产线打样 、培养出一个PO两个TL一个PM具备教练能力 ，具备自运转能力 ，样板间项目加速了研发体系战略产品变革节奏从半年到三个月具备样板间的研发敏捷

2022 H2带领一个从0到1的新解决方案级产品团队具备上攻KA快速验证的能力 ，从无序到高响应力的自主团队 ，研发节奏从按月迭代提效为每周迭代 ，产线主管非常认可产品团队的组织能力有明显变化 ，在年底该产品团队成功与竞争对手pk获得KA用户合同

2023 H1赋能一个15年历史遗留的产品团队做敏捷变革 ，赋能业务与研发建立信任 ，建立跨部门运作机制 ，调整产品研发模式 ，帮助产品扭转负增长的局面重回现金牛产品

这三个变革项目我的一些感悟和收获

敏捷样板间这个项目让我知道希望通过简单粗暴地方式复制组织能力是不太现实的，不同的产品形态、组织阵型、团队能力，怎么可能按照相同的模式去copy呢？

借这个项目一来是帮助千流快速的导入敏捷实践，形成了一些特性组的自运转

二来呢是告诉sponsor一个信号，敏捷最终都要扎根基础的持续交付能力

三来呢是告诉sponsor你的幻想被打破了

四来呢给教练一个适应期，能够理解这个组织的心智模式，企业文化

第二个项目让我意识到要推动产品敏捷，其实干系人不在研发侧，我们最初的策略是找项目主管，因为他的考核权在我们项目管理部，他作为变革接口人必然会执行我们的动作，但是我们忘了他其实影响不了BG，BG的规划主管和产线主管才是接口人，这个项目让我两个收获，

其一呢：有一次机会去验证产品敏捷或者业务敏捷的路径，必然是从业务侧发起，产线主管和规划主管愿意聊，能有一些感知这个事情就能成功一半。

其二呢：业务成功和产品成功不是必然的一个关系，产品成功和商业模式、企业战略、组织文化都离不开关系，一个敏捷教练能撬动的可能是组织阵型、绩效考核、工程能力、但不一定必然带来业务成功或者产品成功，反过来说也成立，业务成功不一定代表组织能力很强，很敏捷

建立信任是最基础却又最容易忽略的一环，我其实在这里面承担的是一个催化剂的存在，从一个第三方视角没有评判，建立一些规则、可视化一些信息，能够理解关键干系人在这里面很多不好明说的道理，所以只需要一把手对敏捷变革的支持，帮忙站站台，并不需要他自己下场

还有一个感触是莫问前程、但行好事，比如在推动变革过程中遇到了一些阻碍，比如流程机制不合理，虽然公司有明确的部门来做流程，但是我可以牵头做这个，比如价值立项也有专门的部门来做这个事情，我还是可以牵头来做这个事情，不是因为我多么高尚，而是因为这件事情我不错我会被打C，我做了，最终这个果实被谁收割不重要，产线的人知道真正干活的是谁，我问心无愧