作者是 Scrum 的始創人,談其背後的理論、為什麼,而非務實實作。所以書看一大半,你都看不到實際上 Scrum 是如何運作,反而是作者很有熱情地介紹 Scrum 如何神奇。對於 Scrum 流程有一般認識者,又想多點知道背後理念,其發展源由,適合讀此書。用這個角度去看,會發現 Scrum 是針對很多人性弱點、偏誤去設計其流程,很忠於 Agile 的以人為本的宗旨。
Scrum 在建立團隊上很用力,每日立會、看板、成員自我組織等等,都是想建立高效、高透明度、緊密合作的團隊。作者期望這些團隊有自己的意志,能夠自發熱心地向所訂目標進發。他在解釋每日立會時,用了個比喻:足球中場球員圍圈討論對策,「那個敵方給我麻煩了」「沒問題,我來搞定他」「不如來個左面突擊?」「好,我可以這樣配合」… 成員之間高度配合,主動而進取。看這個比喻,就對他心目中的 Scrum 團隊模樣更有概念。
每個成員都主動、熱心、進取,看來對成員要求很高,如何能辦得到?作者認為我們其實都是制度下的產物,一個好的制度,能自然地令每個人都有所發揮,在實踐中取得滿足感。我們的行為表現,很被所身處的制度影響,這已有很多實驗証明。Scrum 設定高透明度的環境(看板、圖表),立會使成員間可以高度分享資訊。衝刺專注於小目標上,讓團隊可以目光一致。扁平的階級架構造就團隊成員可以擁有空間,去決定如何達致目標。作者在創立 Scrum 之前曾到機器人實驗室,看到只需為手手腳設定簡單規則與環境互動,整體加起來就很有智慧了。他想 Scrum 時就想做出類似的效果:團隊遵守簡單規則,並能快速回應環境變化。
快速回應,擁抱改變,是敏捷的核心原則。大型工作必先切成細分,再逐一交付。在每次交付之間得到的回饋,可以改變目標以提升價值,這是演化式的。在這裏,工作如何切份、如何估計、如何排優先次序就成了關鍵。使用故事形式去描述工作,適於人腦的記事模式,有了上下文更清楚工作目的,並有發揮創新空間。故事必需可執行、獨立、可測試、有完成定義。這些故事會化成一張張便利貼,在看板上移來移去,一目了然。我們不善於估計,切細工作故然有幫助,還可以使用費氏數列作相對的大小,這適於我們對大自然的經驗。而為免從眾效應,可在估計時使用撲克牌。
至於優先次序,就由產品負責人決定。他雖有決定權,但不會管理團隊 (他們是自我管理的)。根據 80/20 理論,20% 的工作就能有 80% 的價值,產品負責人就是要找出那 20% 出來優先做起,甚至先推出 (minimal viable product)。這樣就可以減少浪費的工作,也是精實生產的原則。而根據產品推出後的回饋,產品負責人就要找出下一個 20% 來實現。在這種演化下,產品能更適於改變,也能生更多價值。
Scrum 重視團隊效能,每次衝刺後都必要有回顧會議,去看衝刺之時的阻礙、浪費,而後改善流程。所以裏有了雙重回饋:一是產品、二是流程。在回饋下改變、演化,兩者都有了自己的生命,都能夠持續改善。看浪費也必需夠深入,例如超時工作並不會增產,反而是種浪費,因為超時工作多做錯,做錯要改正就是浪費。遇上問題不快速解決也是浪費,因為問題越後解決成本越大。在這裏有另一個 Scrum 大師的角色,用來為團隊除去運作沙石之餘,也確保團隊符合 Scrum 精神。一如產品負責人,Scrum 大師也不做管理,而是服務團隊。
Scrum 對團隊狀態敏感,設有開心指標,問簡單的評分問題,能夠優先看到產出(團隊速度)的升跌。這裏的「開心」並不是安於現狀,輕輕鬆鬆又收工的狀態,而是正面、熱心、投入、勇於面對挑戰、感覺個人成長的那種開心。唯有這種開心才能創造價值。
然而 Scrum 只是一個初始架構,套入不同情景需要不同的實踐。例如在軟件開發裏就必需輔以 XP 的 TDD、Simple Design 等實踐。又或者可以說,在回顧裏開發者必然會發現手動測試很慢、軟件寫得太複雜等問題,而進以引進工程實踐改進之。在其他情景,這些改進、工作方法可以大不同。例如作者在書近尾寫有人試在教育上行 Scrum (eduScrum),學生組隊自修,老師作輔助 (很像可汗學院所理想情況)。在這情景下,學生如何可以達標(學習到某概念),則是由學生團隊自行自由發揮。
作者覺得 Scrum 很有用,能改變世界,事實上多年以來很多團隊也以此取得成功。但 Scrum 方法是否適用於所有事呢?這有人提出質疑,例如 Peter Thief 就質疑此些方法不能成就偉大創新,突破並不能給演化出來的。不談哲學問題,Scrum 現實實作上,還是會遇到很多困難,而問題往往是沒有跟足去做,連「守」也不成,何談「破」和「離」?這書談 Scrum 的理念,多少解釋「守」的原則為何。