稍早草擬的〈接班人計畫〉偏向一對一的培訓。

若是一對多呢？

於是乎，就有了這份企劃：【主管的修練】讀書會。

這一部分是模仿《利潤的故事》的做法 ¹，尤其是楊傑美的「前端載入」方法。但我還融入剛學到的 liberating structures 等技巧 ²。改成速讀 + 互動討論的形式，應該既緊湊又有趣吧。

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

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

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

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

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

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

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

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

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

改革，很不容易；摧毀改革，卻很簡單。知名的改革框架，莫不注重改革的整合與固化。 敏捷亦然。 敏捷三叔公 David Ko 在 Scrum 社群裡轉貼了一篇文章，一則可悲的故

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

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

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

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