引子：

最近看到这样一个互动问题，深有感触，尝试记录下自己的想法。

王磊：

最近和几个软件老兵聚会聊外包和传统公司是否需要做敏捷，发现更多阻力在高层，你觉得？

这里有两个问题：

1. 是否需要做敏捷？

在这个问题之前，更需要了解的是为什么考虑做敏捷？想通过敏捷达到的效果是什么？

如果一件事值得做，那就值得问清楚为什么做；

这个问题清楚了，也许敏捷不一定是唯一选择；

记得前辈说过的一句话，很多大家想解决的问题，也许你好好地写代码就能解决了，比如缩短交付周期、提高产品质量等。

敏捷是手段，敏捷不是目的，莫把手段当目的，不要为了敏捷而敏捷。

个人在早期学习敏捷时，确实也经历过这样一个阶段，结果就是实践失败。

上述语境里的敏捷，更多的是指概念、形式、框架类的定义，就像疫情影响下，催生了各类线上分享活动，在各类分享的内容中，有种直接的感觉，就是似乎“敏捷”约等于 scrum  kanban 等。

个人认为这些更多的是“形”上面的体现，然而“敏捷”的定义应该有更多的空间。

最近学到一句话叫“敏捷是内功，总归是需要的”，按照ACT的说法，敏捷更多的是让系统本身具有止血跟造血的能力（摘自《关于ACT》），如果是这个语境的话，个人觉得不单是互联网企业需要敏捷，外包的、传统的需要敏捷，同时“人”作为一个“系统”，自然也需要，这里的“敏捷”，是一种不设限的，拥有无限可能的美好状态。

2. 更多阻力在高层？

之前我也是这样觉得的，但最近似乎有点想开了。

与其说阻力在高层，真正的阻力，似乎在于想推进敏捷的人本身，拿我自己来说，我是这么思考的：

第一，如果敏捷是个好东西，高层怎么会阻止你？

高层阻止你，说明你“推销”得不到位，没能让他觉得敏捷可以解决他的管理痛点，或者实现他的管理期望，所以高层不愿意买单。

那如何成功“推销”敏捷呢？

我的方法是“不推销”，是的，不推销，也就是压根就不提“敏捷”，高层自己想提，我也不跟他聊。

（实际上是要"推销”敏捷，让高层愿意买单，我还没学会！ #手动狗头 ）

而是把高层拉回来，拉到地面上，聚焦于解决一个个实在的、看得见摸得着的、一说大家就有共鸣的问题，“解决XX” “改进XX”，不需要那么多的推销铺垫，慢慢地会发现，大家不会拒绝“真正好”的东西，而随着一个个问题的解决，敏捷的状态往往是自然而然的事情，或者到了后期，是不是敏捷，似乎也不重要了。

第二，为什么会有阻力？为什么会感受到阻力？

个人觉得真实的原因在于，你不敢成为那个为“引入改变”“引入未知”这一系列风险而“兜底”的人。

是的，不敢兜底，因为不敢兜底，所以你想把它交出去，交给高层，而高层也不愿意，所以你感受到阻力。

我也不敢兜底，或者说我也做不到完全的兜底，所以为什么最后我的策略，是聚焦到解决一个个实在的问题，因为那是我能力范围内能“兜住”的，我说我能兜底，让团队知道这个尝试有人兜着，大家就有足够的安全感去迎接改变，这时候啥阻力都没有。

例如，之前引入估算，领导觉得，你们在这拆半天，有这时间不如给我写代码去。

这时候，你要能直接站在前面，给团队“兜”住所有质疑的压力。

因为想说服领导，描述估算有多么多么好，在有实际成果前，几乎是不大可能成功的，而这件事我又想做，那我要接受的就是承担个人被质疑，被打低绩效等的风险。

想象一下，如果有一天，你能“兜”起全世界，那“阻力”这个词估计就从你的世界里消失了。