Retrospective|團隊如何尋找下一步行動的改善機會

Jolin Tsai
7 min readFeb 29, 2020

--

閱讀次數滿了嗎?請點我免費閱讀

Photo by Glenn Carstens-Peters on Unsplash

敏捷宣言第9個敏捷原則是「團隊定期思考如何變得更有效,然後相對地調整方法。」由於 Agile 強調持續改進的重要性,所以對 Scrum 團隊來說,定期進行 Sprint Retrospective 是 Agile 開發實踐中最重要的項目之一。

什麼是回顧會議 (Sprint Retrospective)?

Retrospective 是讓團隊回想上個 sprint ,並為下一個 sprint 制定改善計畫的機會。這是團隊改進的機會,確保所有團隊成員都應該參加。

其實跟 PDCA 的「Check」很像,一個是品質管理、目標管理,一個是團隊改善,但兩者其實是相似的思維脈絡,這樣敘述對於沒有跑過 Agile 的人來說會不會比較好懂。

Retrospective 發生在 Sprint Reviewing 之後和下一次 Sprint Planning 之前。Retrospective 長短取決於 Sprint 長短,為期1個月的 Sprint 則 Retrospective 最多3個小時。我們 Sprint 為期2週 ,Retrospective 大約2個小時。

Scrum.org

該如何進行回顧會議 (Sprint Retrospective)呢?

確保團隊都清楚以下規則和思維:

保持積極不斷改進的精神,充分告知團隊盡情分享任何你認為有助於團隊改進的東西。

  • 不要把這個會議內容個人化
  • 以開放的心態傾聽,每個人分享的經歷都是有價值的,即使不是你所分享的
  • 設定這次會議要討論的範圍,提醒團隊我們要往回走多遠。是最近的 Sprint 嗎?是整個產品嗎?是去年的開發過程嗎?
  • 鼓勵團隊接受改善的心態,不以責備為目的,以找到改進機會為主

在 Retrospective 期間,團隊主要討論3個部分:

  • 在 Sprint 進展良好的是什麼?
  • 在 Sprint 可以改善的地方?
  • 在下一個 Sprint 團隊可以嘗試改善的是什麼?

第一場回顧會議 (Sprint Retrospective)

參與第一場回顧會議時,團隊會比較放不開,主持人也需要經驗才能順利引導團隊進行,先提供基礎版步驟,進階版在最下面:

  1. 創建一個簡短列表,請團隊列出哪些工作做得好、哪些需要改善

可以在白板用便條紙建立,或者你們家便條紙是 3M 那也可在牆上。記得在會議結束後馬上記錄起來,以便日後參考。

2. 根據團隊的重要對列表進行優先排序

這時候可能會發現一些共同的項目,可以把他們組合在一起。

3. 針對改進列表的前2項項目,討論改進的方法

關注於後續如何改善,而不是針對過去、人。若團隊有餘裕的話,可以把改進列表所有項目討論完。

4. 制訂行動計畫

在會議結束後,團隊應該已經有一些想嘗試的行動,並且有明確的行動者來解決須改善的項目。

5. 嚴格執行 #4(這才是最重要的!)

當團隊每次都會靠北一樣的問題,但又沒人嘗試改善時,是多麼令人沮喪。為了避免原地踏步甚至退步,確保團隊都清楚下一步該做什麼,行動者需一直追蹤須改善的項目。

Photo by Hugo Rocha on Unsplash

進階-焦點討論法 (ORID)

我們總監曾利用 ORID 變形,引導我們進行多場 Retrospective 以及公司讀書會。台灣高智商的行政院的數位政務委員唐鳳,也透過 ORID 應對公關和網路問答。

Video by Audrey Tang

ORID 是用對的順序,問對的問題,來節省至少 1/3 的溝通時間。共有4個步驟,按以下順序進行:

  1. Objective:觀察外在客觀事實
  • 你看到了什麼?聽到什麼?記得什麼?
  • 發生什麼事情了?

2. Reflective:重視內在感受、反應

  • 有什麼讓你很感動/驚訝/有趣/難過/沮喪/開心/鼓舞?(感受通常難以具體表達,可以提供多一點形容詞引導團隊說出感受)
  • 有什麼令你印象深刻的地方?
  • 什麼是比較困難/容易的?

3. Interpretive:詮釋感受的意義、解釋

  • 為什麼你會有這些感覺?感受發生的時間點是?
  • 引發你想到什麼?有什麼重要領悟嗎?
  • 為什麼這件事你覺得很重要?

4. Decisional:找出決定、行動

  • 有什麼我們可以改變的地方?
  • 接下來的行動/計畫會是什麼?

進階-Speed Boat(or Sailboat)

是我喜歡的 Retrospective 可視化技巧,起源於 Luke Hohmann 的《Innovation Games》。這種技巧是使用帆船作為團隊的隱喻,運用帆船/快艇會遇到的各種情況,幫助團隊具象化什麼事情會讓團隊慢下來,什麼事情會推動前進。

Photo by davidemanske.com

Speed Boat 有各種版本,有拖住船的錨、看到的島嶼等,選擇適合團隊狀況的項目就好,不一定要多。重點是讓團隊清楚知道每個項目的意思,思考與表達為什麼是放在這個分類。有些分類不容易分得清楚(Sun/Engine、Wind/Rocks),可以先從簡單的分類進行。

  • Sun 太陽:什麼是我們在上個 Sprint 中做得好的地方?
  • Wind 風:什麼不利於我們的工作,是我們需要減少的?
  • Engine 引擎:是什麼動力讓我們可以保持下去?
  • Risks/Jaws 暗礁/鯊魚:未來有什麼風險?
  • Rocks 石頭:我們這個 Sprint 遇到什麼阻礙?

請團隊在便利貼上寫下每個項目的回顧內容,等到所有人都寫完後,每個人輪流上去畫船和貼便利貼,並說明自己的回顧內容(也可以主持人把船畫好,一個分類團隊回顧完成後,再進行下一個分類)。好的部分持續保持,不好的部分討論改善方法。

--

--

Jolin Tsai

靠美食、電玩、動漫、閱讀、產品活下去的 B2B2C Product Manager LinkedIn: https://bit.ly/3bn70zZ