Scrum抑制创新？敏捷笔记第24篇

Posted 2021-04-25 敏捷密码

在一定程度上，Scrum就是目前敏捷实践的默认选项。因为Scrum直接告诉你“你应该这样这样”，比起指引层面的“你应该怎样怎样”，让人觉得更有头绪，也易于操作。

能够引导你行动的框架，我们总是倾向于把它叫做“流程”；逻辑顺畅，操作简单，正是“好的流程”的必备特征。

很明显，Scrum也是同类流程。

实际上，“流程”是个不好不坏的东西 ，谈具体效果，要看你用多少，怎么用。

可以无论如何：“按照流程……”总是有种限制发挥的感觉，不信你快速的造十个句子，体会一下那种内心的压抑感。

那么问题来了，既然Scrum也是流程，是不是明摆着的，Scrum也抑制个人或是团队的发挥空间，影响创新呢？

类似的疑问，确实是很普遍。

大家都相信，流程是创新的毒药。因为在大家普遍的认知系统里，创新来自于灵感，灵感的产生需要足够的自由空间，流程这种硬约束，只可能改进效率，跟创新毫不沾边。

如果真是这样，叫的响亮的“敏捷开发”是不是就是一个笑话？只是本着把事情做完，完全不顾及新意，“开发”是不是也只能算是一种听上去更高级的“复制”。

我们对流程的理解存在着根深蒂固的偏见。流程的出发点一定是为了降低出错的总成本，但是在工作中，大家作为其中的一环，首先这个成本很少会是你的成本，其次大多不痛不痒的损失，也不容易直接察觉，所以有人误以为“流程只是用来折磨人的”。

当然，Scrum框架下的流程，并没有那么“折磨人”，核心流程就是“开发”“测试”“反馈”。

肯定会有人挑战这个观点，“不对呀！Scrum中的流程是Plan meeting，每日站会，Review meeting，Backlog meeting等等等等等等才对呀！”

回答全面，但更准确的说，这些是实践，不应该算作流程。实践自带变量，可流程就没有那么幸运了，它总是被人为的过度理解，进而挤走变量，保持不变才让人感觉安心。

这一点并不好理解。不过即便是把上面的各种会议当做敏捷开发的流程，也不伤大雅，因为本质上，我们确实在人为的在各个环节中设置了约束条件，也正是因此，各个环节看起来更有流程的样子。

其中，最重要的一个约束跟创新密切相关，那就是目标。

好的目标，是推动创新的第一力量源。

普遍的感受是，我们日常的工作跟创新没啥关系，创新这件事，是用在大事上面的，大事情，才需要大灵感，才有创新。

感觉并不总是靠谱的。创新确实有大有小，不过创新行为本身，却是无处不在。

有对思想的制约，就有创新。

比如简单到在一件事情的末尾加个交付的期限，就是一个时间制约；在目标里，添加价格要求，就是成本制约；在功能特性中，设置最终指标，就是参数制约；划定人员分配，就是资源制约……

面对制约，无论大小，你都要变，变的大小，决定了你对创新的体感。

可无论如何，创新这件事，跟流程或是实践本身，没啥关系。

要说有关系，那大概率是流程中对目标的要求，缺少真心实意的说明，更大概率是目标里缺少斟酌后的制约。

会使用制约因素，应该是非常重要的敏捷能力之一，Product Owner（PO）更应该充分展示这种能力。

想的更严重点，如果PO缺少使用制约因素的能力，视乎这个角色存在的一大半意义已经没了。

不妨看看“创新的国度”以色列，你就更能明白对思想的制约，可以创造奇迹的深意。

Make things, chang things.