LeSS 的 “Scrum Master focus over time” 一文主張,在導入敏捷的初期階段,首要焦點應放在 TeamProduct OwnerOrganization 三者。

Scrum Master focus over time (from LeSS)

Scrum Master focus over time (from LeSS)

如果借用麥肯錫 7S 模型來分析這些初期的施力重點,不難發現,Organization 的施力點大致可直接對應到 7S 的結構 (Structure) 1 ,至於 TeamProduct Owner 的施力點,則是對應到 7S 的風格 (Style)、技能 (Skills),甚至是共同價值觀 (Shared Values)。

前者屬於硬性要素,較易理解,也較易實施;後者屬於軟性要素,較抽象,也不易立竿見影——這是敏捷啟航時需要面對的模糊題。

面對軟性要素,除了像【敏捷原理與團隊塑造】工作坊這種典型的起手式,我發現,要促成根本改變,還得致力於「建立共同語彙」。我還更進一步發現,這些共同語彙,不只是敏捷轉型需要,就算不談敏捷轉型,也一樣需要——這應該是各職能工作者都該有的專業基礎。

其中,我最看重且亟需建立的共同語彙有三:

  1. 5W1H
  2. WBS & MECE
  3. Working backwards collaboratively

5W1H

很多人視 5W1H 為過氣的老調。有趣的是,日本人對於經典的 5W1H 似乎情有獨鍾,出了幾本專書:《5W1H 超強思考術:你的所有問題,都可以靠 5W1H 解決!》、《5W1H 經典思考法:容易獲得成果的人都在用》。

5W1H 不只是表面上「人事時地物」這麼單純的事項羅列,以事實為基礎的行事態度才是它更深層的意涵。如果套用麥肯錫常用的「天空、下雨、雨傘」比喻,如果連「天空」這個事實層次都無法精準陳述,後續「下雨」的推論詮釋或是「雨傘」的行動決策,都是刻舟求劍。

對敏捷的影響:若行事態度不以事實為基礎,等於是推翻了 Scrum 經驗主義三支柱當中的「檢視性 (inspection)」,就別奢望能夠正確發揮 Scrum 的功效。

WBS & MECE

工作分解 2 ,是專業工作者的基本功。磨練工作分解的技術,不管是 WBS 形式還是 MECE 意識,都能促成更專業的工作品質。

對敏捷的影響:儘管敏捷並不講究在一開頭就進行鉅細彌遺的工作分解,但這並不代表敏捷就不需要工作分解技能了。此技能若不精熟,Sprint PlanningSprint Refinement 等活動很快就會卡關。

Working backwards collaboratively

Working backwards 一詞,近年來因 Amazon 而聲名大噪,但這觀念其實相當古老。至少當我們還在學生時期,都懂得所謂的「逆推法」解題祕訣:面對數學證明題,有時候可以嘗試從待證明的結果往回推導個幾步;面對閱讀測驗,較有效率的做法,往往是先快速掃描後面的提問及選項,而不是傻傻地先閱讀冗長的文本。

迷宮,未必非得從入口出發;從出口往回倒著走,可能更容易破關。

Working backwards 是學生的法寶,只可惜到了職場,只有一流高效人士才懂得重拾這個絕招。像在專案管理領域中,WBS 就是最典型的 working backwards 應用:從「最終交付物」出發的分解結構 (a deliverable-oriented hierarchical decomposition)。

一流高效人士不只是懂得 working backwards,更懂得 working backwards collaboratively。專案管理名著 Work Breakdown Structures: The Foundation for Project Management Excellence 就說,WBS 不是 PM 一個人悶著頭生出來的,而是靠整個團隊的力量集結完成:

Who owns the WBS, who should be involved in developing it, who keeps it up to date? The answer to each of these is the project manager and the project team. […] who is responsible for the upkeep of the WBS? This is the responsibility of the entire project team.

不靠整個團隊的力量,很難做到 WBS 所講究的 “100% rule”。

對敏捷的影響:不具備 working backwards collaboratively 的心態及技藝,就只是表面功夫的敏捷。就以敏捷圈常見的 user storySBE 手法為例:

  • User story:經典句型 “who + what + why” 及 acceptance criteria 就是 working backwards,3C 要素當中的 “conversation” 就是 working collaboratively。

  • SBE:經典句型 “given-when-then" 就是 working backwards,3 amigos 活動就是 working collaboratively。

交叉訓練

5W1H、WBS & MECE、working backwards collaboratively 這些共同語彙,不只是敏捷轉型需要,就算不談敏捷轉型,也一樣需要——這應該是各職能工作者都該有的專業基礎。

檯面上沒有單一課程能深度涵蓋這三種語彙。我只好打組合牌,透過幾種課程的交叉訓練,從不同角度冶煉出這三種語彙的交集,再以我的【職涯躍升書系導讀會】做為佐料來提味:

Git 專案管理入門 SBE TDD 遠距工作講座
5W1H
WBS & MECE
Working backwards
Working collaboratively

教育訓練效果不彰,很多時候是因為:​❶ 主管自己都沒上過,❷ 沒有人致力於把它變成組織內的共同語彙,❸ 沒有人有 coaching 的意識與行動。​如此這般,就淪為徒具形式,船過水無痕。

透過交叉訓練,應用場景自然而然擴大起來,再搭配正確的 coaching 意識與行動,將更有機會成為真正實質意義上的「共同語彙」。

整土

這些共同語彙一旦真正建立起來,許多 Scrum 元素就顯得理所當然。

Scrum 跑不順,不見得是 Scrum 的錯。畢竟 Scrum 是個篇幅 20 頁的擴大機,原本的天籟會增益,反之——噪音亦然。

Scrum 懷璧其罪很久了。

在敏捷啟航之前,花點時間處理這些軟性要素,在組織中種下這些共同語彙,把硬土、淺土、雜土整理成好土,整理成易於滋養敏捷的環境吧。


  1. 即使 Kanban 方法是傳説中一開始對既有組織結構衝擊最小,且明文宣稱 “Start with what you do now“ 及 “Initially, respect current processes, roles, responsibilities, and job titles”,但根據 Kanban from the Inside 一書的說法,Kanban 最輕量的導入手法 “The Sustainability Agenda” 當中,就包含 ① Visualize, ④ Make Policies Explicit, ⑤ Implement Feedback Loops 這三項 Transparency 實踐手法——說實話,這未必是小小的衝擊!如果借用麥肯錫 7S 模型來分析這些初期的施力重點,可說是從 7S 的體制 (Systems) 這項硬性要素及風格 (Style) 這項軟性要素切入。 ↩︎

  2. 請參考〈工作分解講座・閱讀材料〉一文。 ↩︎