Scrum被视作是一种适应性和灵活性俱佳、旨在改进开发过程的软件开发方法。多年以来，Scrum的成功案例比比皆是。然而，一些团队依然察觉到许多刻板、教条之处。这究竟是Scrum本身有问题，还是实践过程有瑕疵呢？

　　Terry Bunio在他写给Scrum的信中提道，起初他对Scrum的过程、流程是何等着迷。可是渐渐地，他认识到框架的条条框框无益于项目成功所需的自由。

我的确需要这样一个流程，在sprint期间，让我能够追加合情合理的需求。我不希望讨论仅限在回顾时间，尤其当我觉得还有很多需要讨论……我痛恨被称为Scrum Master。当前这一角色仿佛弱化了我作为项目经理的价值，使我仅仅变成个流程教练，而非一名有价值的团队成员。我感到事实上我不再是团队的一分子了。

　　Marek Blotny也觉得每日站立会议限制太多。Marek不喜欢团队成员“保持沉默”直到轮到他们说话。他认为这无疑扼杀了天然的知识共享。他还提到，有时也没有必要坚持15分钟的硬性限制。如果整个团队正在热火朝天地讨论，就应该顺其自然。

因此如果你问我，强制执行如此刻板的日常Scrum架构是否合理。我会回答……肯定不合理！一方面，你要利用有效的Scrum实践来促进团队合作，另一方面，还要摒弃死板教条、事事照本宣科。

　　Rod Claar提出，尽管Scrum很灵活，一些Scrum团队为了确保一开始就正确实施，则倾向于将它严格化。Rachel Davies 在一些实施Scrum的团队也见过此类倾向。她谈到，

我一旦听到Scrum Master或团队试图“照着书本做Scrum”，就会为自己敲响警钟。Scrum是团队通向敏捷软件开发旅程中的一个起点。使用Scrum并非真正的终点。我们要运用Scrum来增量式发布产品。没有人要来跟着你的团队，检查你Scrum做得是否规范。

　　Geoffrey Wiseman补充道，流程严格和敏捷并非必然形同水火。流程可以规定，一旦sprint开始就不得有任何干扰。Sprint可以被看作是计划和实现的基础（atom），但它肯定也对实际操作中的灵活性敞开了怀抱。

这是强制条款吗？或许是。一些人也许会争论，如果你无法遵循那些约束，就不应该采用那个流程。不过实事求是地讲，Sprint能在某一资源临时调整后继续进行吗？当然，我认为肯定能行。

　　因此，流程的严格程度一定要根据团队的想法来设定。虽然恪守约束，避免整个流程体系走向混乱是很好的，但过于教条以至于无视实际情况同样不利于项目和团队。

　　查看英文原文：How Rigid is Scrum