Timebox 是死胡同嗎？

許多敏捷手法都奠基於 timebox。那麼，為什麼有人會認為 timebox 路線是死胡同呢？有此論點的人，偏偏又是敏捷圈的重量級人物呢。

看板方法之父 David J. Anderson 在新書 Discovering Kanban 第 15 章對於 Scrum 之類基於 timebox 的方法有頗露骨的批評（光從標題 “The Tyranny of the Ever-Decreasing Timebox” 就看得出來）。正好好友 Derek 在 〈《Discovering Kanban》心得：Scrum 可能沒有你想像的那麼美好〉一文整理了這一章的摘要與閱讀心得，在網路上也引發一些討論 ¹，我便趁此機會細讀這一章。

這一章論點非常深刻。但讀著讀著，總覺得作者道出的結論 “time-constrained sprints are an evolutionary cul-de-sac, a dead end”，與我直接或間接所知的業界實踐現況，並不相符。我猜想：會不會是某個推論環節出了些問題？

因此，我嘗試用系統思考角度去梳理相關論述。我試圖用更清晰的因果關係秀出 timebox 路線被點名的痛點，以及常見的因應之道。至於這痛點是否真的已被解決了，則留待讀者思考，不在此文的探討範圍。

目標相同，途徑各異

首先，David J. Anderson 是贊同 small batch 小批量的。他明確指出小批量的三大優點：

the advantages of smaller batches—higher quality, more frequent interaction between customers and the delivery organization, and potential gains from earlier delivery of valuable work (also known as the avoidance of opportunity cost of delay)

他接著指出，欲達小批量的目標，有兩種常見的途徑，一個是 timebox，另一個是 WIP limit：

There are two ways to constrain the batch size of work: Constraining the amount of time available to do the work, resulting in scoping to small numbers of requests that can be completed in the given time; or simply constraining the number of work items, constraining the size of the batch of requests, also known as WIP constraints.

此處姑且小結一下，David J. Anderson 是贊同 small batch 的（至少在整本書我還沒找到反對的段落），但主張透過 WIP limit 的方式達到小批量，反對透過 timebox 的方式達到小批量。

他認為 timebox 劣於 WIP 的地方是：

This switch from a time constraint to a WIP constraint free you from the tyranny of the timebox and it’s three dysfunctions of upfront analysis, excessive and costly estimation, and heavy-weight dependency management.

接下來我們就來看看他反對 timebox 的理由。

Timebox 會浪費力氣在削足適履上？

David J. Anderson 認為，timebox 愈短，就愈是需要花力氣在 backlog item 的事前分析上，以「削足適履」進去 timebox：

smaller timeboxes create three types of pressure that are often difficult to cope with and adjust to: First, smaller batches require an ever more detailed approach to requirements analysis and development—the need to write ever more fine-grained user stories that can be completed within the smaller time window. Second, an ever more accurate approach to estimation is needed so that a realistic commitment can be made; with smaller time windows, greater precision is required in estimation.

The shorter the time box, the more upfront effort is required to estimate whether the work will fit into the available time.

這段話的確指出了一部份實質存在的驅動力量，但並非全部。實務上，如果 Scrum 做得夠確實，在經驗主義的引領下，timebox 會逐漸趨於穩定態：

因此，如果還需要做過多的 up-front estimation，那一定是做錯了 Scrum Planning & Refinement。

David J. Anderson 又進一步評論道：

there is still, after twenty-plus years of Agile, little or no solid guidance on writing fine-grained, consistently small user stories.

這與我直接或間接所知的業界實踐現況，並不完全相符。至少我看到許多成功運用 Mike Cohn 大師提出的 SPIDR 法的例子。

Timebox 會鼓勵低交付價值？

David J. Anderson 認為，timebox 愈短，就只能交付出被削足適履出來的小碎片，這是難以被用戶察覺到交付價值的：

small-scale requirements may not be meaningful to the customer—they may not enable value. This means that if one small requirement has a peer relationship to others, they all must be delivered together in order to release value.

This type of breakdown defeats the purpose of the ever-smaller timeboxes and creates a false sense of agility when, in fact, customer value and quality are not improving; perhaps even the opposite is true.

這段話的確指出了一部份實質存在的驅動力量，但並非全部。實務上，如果 Scrum 做得夠確實，在 Scrum Planning 及 Review 時，用戶有充分機會了解如此拆解的目的，並實質參與拆解的活動。因此，在經驗主義的引領下，timebox 與交付價值之間會逐漸趨於穩定態：

事實上，從上圖可知，不只是 timebox，就連 David J. Anderson 認可的「小批量」也一樣會面臨「低交付價值」的挑戰。因此，Kanban 的淵源——Lean 陣營，即使主張小批量、one-piece flow，但對於 batch size 是否可以無限制壓縮到最小，也是持保留態度的。像《流的傳承》就提到，大野耐一主張 batch size ≥ 5。

Timebox 會讓 Dependency 更惡化？

David J. Anderson 認為，timebox 愈短，dependency 造成 sprint fail 的機率也隨之增加：

What if a story in our sprint backlog gets blocked because of a dependency? That might prevent it from completing on time. Hence, the shorter the sprint timebox, the greater the need to identify dependencies up front.

Fine-grained requirements analysis coupled to short timeboxed sprints introduces a dependency management problem to Agile methodologies. If a piece of work will be affected by dependencies, such dependencies need to be tracked and managed between teams and multiple sprint backlogs and potentially across sprint boundaries.

這段話的確指出了一部份實質存在的驅動力量，但並非全部。假設 dependency 條件不變，timebox 愈短，一點點的 dependency 擾動帶來的影響的確可能較大——這是 threat。可是相對的，granularity 愈小，也愈有將它 fit in 到相關團隊 upcoming sprints 的可能性；尤其當對方團隊也是 short timebox 風格，就更容易 fit in 進去——這是 opportunity。 ²

Threat 與 opportunity，一加一減，綜合起來的效應是好是壞，還很難說。

實務上，如果 Scrum 做得夠確實，在跨團隊 Refinement & Planning 時，已經有辨識、拆解、對齊、協調 dependency 的事情在檯面上或檯面下發生了，而且不只是消極地為了處理 dependency，更是積極地處理交付價值。

事實上，這也是各家各派大規模 Scrum 框架最核心的挑戰與賣點。至於這議題是否真的已被解決了，則留待讀者思考，不在此文的探討範圍。

Kanban 又是怎麼處理 dependency 的？

David J. Anderson 也承認 dependency 是個普遍現象，他也沒有神奇魔法可以讓 Kanban 免於 dependency：

Dependencies are a fact of life in all but very small-scale software development or mediocre development done by largely dilettante generalists.

Kanban 又是怎麼處理 dependency 的呢？從以下文字可以歸結出 global transparency 及 learning to coordinate/cooperate 這兩個方向：

Let dependencies happen as you discover them, create visibility onto them, and actively track them. Use a service-oriented approach and define workflow kanban boards (and systems) that encourage cooperation across functions. Don’t reorganize into cross-functional teams or attempt to design out dependencies from your product architecture; instead, start where you are and learn to be proficient at coordinating shared services.

這段主張，我的理解是，服務導向的看板，通常會是更縱向 end to end，也更橫向 cross functional。如果做得確實，理論上 dependency 會更早浮現，也更早讓縱向橫向的人一起面對，一起 ad hoc 處理或是 systematically 處理。

看到這裡，心中不禁想到：timebox 路線不也是如此嗎？

個人總結

至此，我個人認為，timebox 與 WIP limit 兩種途徑，長期的目標狀態「小批量」其實很類似，只是選擇的途徑不同，造成哪個要先關注、哪個可以等到成熟度提升之後自然就會去關注的不同優先順序。

兩者的差異並沒有想像中的大，雙方只是切入的角度不同，但核心要素是很接近的；尤其是繼續精進時，會發現共同點越來越多，相互取經是司空見慣。

所以我在課程中，總愛用《神之雫》的最終章來比喻兩者的關係。