到了年終，又開始要做個總回顧，再對來年許願。

如果說 2016 和 2017 都是華麗冒險年，那麼，2018 對我來說，是收攝靜觀的一年。

去除一些不便揭露的事情，以下是簡單的回顧。

研發團隊，常會被問到一個問題：

「請問一下，這個Ａ功能，大概要多久才能完成？」

這個問題，不會因為你跑的是敏捷，就自動免疫。那麼，身為經過敏捷思維洗禮的人，該如何做出合宜的應對？

我在 Agile Tour Kaohsiung 2018 開辦一場 2.5 小時的工作坊，帶領大家親自體驗這個議題。

不過，這個題材的背後，其實還有三段故事。

故事，要從一年半前講起。

改革，很不容易；摧毀改革，卻很簡單。知名的改革框架，莫不注重改革的整合與固化。 敏捷亦然。像這篇文章〈慢慢的，公司内敏捷的热度就退了&hell

Scrum 的官方白皮書 The Scrum Guide 非常輕薄短小（像 Nov 2017 版只有 19 頁），它的理念是：只制定最核心的原則、價值、角色、活動、產出物，其餘的則交給團隊根據經驗主義 ¹ 去調適出最適合自己的細節。

想當然爾，有很多事，Scrum 並沒有明說。

那麼，沒有明說的事，就不需要做、就不能做了嗎？做了，就違反 Scrum 嗎？

這是許多奉 The Scrum Guide 為圭臬的人，常有的盲點。

在一篇 Terry & Ruddy 對話紀錄中，看到一系列有趣的 LeSS vs. SAFe 討論： 「為什麼 LeSS 這麼迷人，可是總是輸給 SAFe？」 「SAFe 是敏捷跟辦公室政治作出了完美的妥協