Retro= Retrospective (回顧會議),大部分正在運行Scrum team的成員,每兩週/每月都會利用這場會議,回顧這些日子以來遇到的困境,提出可行的解決方案,針對在這個Sprint中,與他人合作時發生的開心、不開心的事件來回饋。許多members也常在retro 說出因受到他人幫助的感謝、但若這場會議變成你感謝我、我感謝你、你再感謝他的巡迴,很容易像是一場輪流上台的頒獎典禮,真正需要改善的問題反而沒有被拿出來討論、解決。
記得感謝但卻沒有提出「具體的回饋」來讓團隊更好,怎麼做讓每次Retro價值感提升、問題不再歷史重演。先聊聊為何總感覺一場retro 會議之後沒有踏實感,問題沒有被解決、回饋不夠到位的
主因— 1.成員間彼此不熟,深怕在會議中講話太過直接傷和氣
大部分會不敢在retro會議中直接反饋的原因是在團隊建立初期時,因為成員間彼此還不熟悉,還在摸索彼此的工作模式,在沒有建立起雙方默契時,若直接點出問題、給予回饋可能會像是在糾正或是找麻煩,如果這場會議剛好主管也在,當下被反饋的當事人不但沒有聽進去,之後再與他合作反而會出現無形隔閡。🙀
主因 — 2. 沒有抓到 Retro 的主要目的
一場Retro可能是回顧這個Sprint,也可以是針對部門的議題做討論,會議目的在事前沒有被確立好,只知道時間到了開始坐下來開會,在目的是什麼、要解決什麼事沒有被定義的情況下,焦點容易在會議上發散。主因 — 3. 節奏沒被掌握,該說的還沒說,會議就結束了
想像回顧會議就是這段日子以來的種種工作回顧,開心的是被好同事carry,不悅的是那個總是遲交文件的同事。感謝完好同事之後,卻不好意思點名那個有點雷的同事,於是會議就這樣結束了…。
:這件事有解嗎?
:有!
解法1. 會議前收集回饋, 會議中對「事件」而非「當事人」做回饋
通常PM在會議前,會群發一封信預告會議時間、地點,同時也可以利用這封信詢問針對會議有什麼「議題」想一起討論,這個議題可大可小、但都是在會影響工作、團隊運作的情況下提供,例如:團隊的溝通效率不佳、設計師的flow沒有及時更新,讓RD在開發時要不斷確認…等。這時候PM在會議前就會先整理大家回覆的email,在會議上針對大家的問題做討論,且注意是針對事「事件」而不是「當事人」,可以提及這是誰提出的問題,請當事人說明事情的原委,但非必要不用特別說明是給誰的建議(因為通常都心理有數),這時候大家會開始討論怎麼解決此事,例如事設計師與工程師間資料歸檔的問題,那就討論出雙方都願意配合的資料歸檔SOP。如此一來,不但提昇會議效率(事先整理好議題,當場討論解法)也避免成員間因為面對面而不敢表達的窘境,簡言之,事先花一點時間整理議題,可以省去很多事後的溝通成本。
解法2. 感謝轉成稱讚,描述事蹟更具體!
受別人幫助,我們會把它放在心上並由衷感謝,但感謝畢竟有其局限性,通常只能起到雙向作用,我感謝你對我感謝,但別忘了會議上還有其他人,若是把原先的感謝轉成真心的稱讚,反而讓力道更強、「具體事蹟」更容易被描述。例1:謝謝Carol準時交付檔案給我!例2: Carol做事很有效率, 準時給我UI檔案讓我及時交付規格。兩句可能是相同情境的話,只是從感謝轉成稱讚,效果就不一樣,成員聽見也會清楚知道那個人因為哪件事而被稱讚,全員一起學習共好!
📷Mindset → 氣氛對了!什麼都對了!
Retro 是一個不算太過正式的會議,因為通常除了回顧工作之外,團隊也會花1/3的時間閒聊工作上的趣事、時事。每個Sprint 已經有百百場會議了,如果每場會議都如此緊繃,會讓人窒息的。想主辦一場成功的Retro ,最終目的是問題得以解決,所要具備的心態就是「掌握節奏&好的氣氛」。因此身為會議主持人(通常是PO , PM or 成員輪流)會想花一點時間在會議前先跟大家聊聊,放鬆大家的心情。因為是非正式的會議,所以可以準備一些茶點、飲料還有萬用的「便利貼」!開始討論議題時,大家會一起想出多個解,這時候可以利用便利貼投票的方式,投出大家心中理想的解法,成員站起來到台貼便利貼寫+1或寫其他文字表達意見 ,如此一來也讓Retro 會議更活潑!😻
🔗線上Retro好用工具: