本文轉載自InfoQ網站。
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能在某一資源臨時調整後繼續進行嗎？當然，我認為肯定能行。
因此，流程的嚴格程度一定要根據團隊的想法來設定。雖然恪守約束，避免整個流程體系走向混亂是很好的，但過於教條以至於無視實際情況同樣不利於專案和團隊。