Scrum 的官方白皮書 The Scrum Guide 非常輕薄短小（像 Nov 2017 版只有 19 頁），它的理念是：只制定最核心的原則、價值、角色、活動、產出物，其餘的則交給團隊根據經驗主義 1 去調適出最適合自己的細節。
想當然爾，有很多事，Scrum 並沒有明說。
那麼，沒有明說的事，就不需要做、就不能做了嗎？做了，就違反 Scrum 嗎？
這是許多奉 The Scrum Guide 為圭臬的人，常有的盲點。
Scrum 沒有所謂的「暫停」？
譬如說，有人對 sprint 這種百米賽跑的壓力提出疑問：
Run scrum 一陣子了，有感覺到一些跟傳統軟體開發專案不一樣的壓力。以前這種方式對 team member 來說，會有淡季跟旺季的差別，所以大家比較好安排自己的休假，或者在淡季的時候安排一些 researching、training 的工作。
現在 run scrum 覺得每個 sprint 壓力都好大，每個 sprint 都好趕，都剛剛好在最後一刻達到 sprint goal。大家也會因為齊步走的關係，所以都不太好意思請長一點的假。以前一年可能最多面臨四次 milestone review 的壓力，現在是至少每四週都會面臨一次這種壓力，Scrum guide 又說 sprint 開始以後就是一個 sprint 接一個下去，中間不會有間斷，但我們真的好想暫停 0.5 個 sprint 讓大家喘口氣。
前輩們都怎麼處理休假問題跟這種持續性壓力的問題呢？
Scrum 真的沒有「暫停」這件事嗎？
首先，回到 The Scrum Guide 原始文本，看看它是怎麼說的：
The Sprint
Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.
Sprint 長度在整個開發過程中都是固定的，前一個 Sprint 結束後，下一個新的 Sprint 立刻接著開始。
如果只以形式主義來說，這些 sprints 的確好像是一棒接著一棒，棒棒相傳，不漏接，無止息——沒有假期。
再進一步思考 sprint 這個載具的原始目的——即所謂 sprint goal，就可發現，goal 的意義，是由我們 Scrum team 來賦予的。就連 The Scrum Guide 都叫你要保持彈性，不要形式主義：
Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.
每個 Sprint 可視為一個不超過一個月的專案，如同其他專案一般，Sprint 是用來完成某些事情的。每個 Sprint 有著要打造些什麼的目標，而由一份設計和有彈性的計畫來引導其打造的過程、工作與最後的產品 Increment。
Sprint goal 的意義，是由我們 Scrum team 來賦予的。
問題是，你想賦予什麼意義呢？
譬如說，市場探索，可不可以是一種 sprint goal 呢？用戶研究，可不可以是一種 sprint goal 呢？五日 design sprint，可不可以是一種 sprint goal 呢？
甚至有點離經叛道的講：恢復元氣，能不能算是一種 sprint goal 呢？
休耕期
恢復軟體本身的元氣，有一個更正式的名詞——休耕期 (fallow)。
在《編程的頂尖對話》中，大神 Douglas Crockford 如此解釋軟體研發領域的休耕期觀點： 2
「一般來說，團隊應該知道什麼時候合適（進行這種清理程式碼、重寫的事）」，大神 Douglas Crockford 毫不客氣挑明地講：「管理層很難看到這一點⋯⋯管理層很久之後才會發現。」
如果沒有這種特地保留起來的休耕期，那麼，重構、技術債的議題，幾乎註定會一直被推遲到比馬里亞納海溝還更低的順位。這將嚴重破壞 Scrum 的基石：PSPI 3。
敏捷陣營也有人呼應這種想法。像 Toronto Agile Conference 2017 有一場演講 “Technical Debt Is a Systemic Problem, Not A Personal Failing”，用的是 “technical-debt sprints” 一詞，還畫出 CLD 呢：
「休耕期」觀念，不是出於傳統的 Scrum 論述，The Scrum Guide 也沒講，你認為它有違反 Scrum 嗎？
如何做？
那麼，該如何踏出第一步呢？或者更敏感地講：誰該去在貓脖子上掛鈴鐺？
大神 Douglas Crockford 說：「團隊應該知道什麼時候合適，管理層很久之後才會發現。」
所以，請先自問：你們有規律地跑 retrospective 嗎？在團隊層次，甚至在更大的組織層次？
我參加 Scrum.org 在台北舉辦的 #ScrumOn 活動。經過六十分鐘 PSM I 洗禮，以及敏捷專家學會 Percy 的推坑，特地去查閱 Nexus Guide。
發現，裡面正好有特地提到技術債議題。特地摘錄於此：
軟體開發必須在技術債變得讓 Nexus 不可接受前，找出並解析依賴關係。若缺乏透明度，不可能有效指引 Nexus 有效地將風險最小化並將價值最大化。
Software must be developed so that dependencies are detected and resolved before technical debt becomes unacceptable to the Nexus. A lack of complete transparency will make it impossible to guide a Nexus effectively to minimize risk and maximize value.
-
The Scrum Guide 說：「Scrum 是立基於經驗導向的流程控制理論 (empirical process control theory)，或是經驗主義。經驗主義立論於知識來自於經驗和依照已知的資訊來下判斷。Scrum 使用疊代和逐步 increment 的方式，來最大化可預測性和控制風險。」 ↩︎
-
Douglas Crockford 在 CUSEC 2010 Keynote - The Software Crisis 這場演講主張：‘Perhaps we should take advice from Exodus: “Plant and harvest crops for six years, but let the land rest and lie fallow during the seventh year.” Maybe do six sprints where you add new features, but on the seventh sprint, don’t add new features at all.’ ↩︎
-
我個人認為，Scrum 的判準，就在於 increment，以及能否在各個疊代過程中，捍衛並精進這個 increment 的整全狀態。詳見〈敏捷的判準〉一文。 ↩︎