如果Retrospective 要有效果, 有些手法可以來試試看:
(1) 平等
每個人都有機會說話, 不可以不讓他說話, 或是限制他不能說什麼
每個人說話的時間長度要平等, 不要讓話多人就有較長的時間
但是有些人天生不擅長說話, 因此要能設計一些活動, 讓他們有機會多說一點, 或者讓他的意見可以表達出來.
例如,
a. 先寫在便利貼上面, 然後再發表. 每人至少寫一張.
b. 或是提示一些容易回答的問題, 讓他比較好說些什麼
c. 或者利用 1-2-4-all 讓大家的意見都可以有機會呈現
(2) 讓數字說話
很多時候在開 retrospective, 所有事情都是憑感覺在說話
如果你話術能力好, 可能就可以讓大家認爲事情就是這樣
比較好的方式, 是準備好一些數字資料, 讓有些理性中立的資訊可以呈現
例如:
a. 功能的 lead time
看看我們平均交付時間是越來越來快嗎? 這個迭代是否比以前好? 或者那些開發人員有比較快的速度? 或是哪些類型的功能做得比較順
b. burn down chart, CFD
看看整體團隊交付狀況, 哪些地方有遲緩, 哪些區段是瓶頸, 哪些地方比較多 WIP
c. Flow metric
像是 Flow Time, Flow efficiency, Flow Loading, Flow Velocity 等等
d. Bug 狀況
平均每個 功能有多少 bug, 平均每個 bug 修復時間, 哪些人的 bug 量比較多, 哪些功能的 bug 比較多
(3) 凡事都從自己開始
不管怎麼討論, 最後的行動方案, 不該是別人要做什麼, 應該是在這件事情上面, 自己可以做什麼. 因為你無法成功請別人怎麼改變, 唯一能做的就是改變自己.
例如： PM 需求寫不清楚. 這時候如果你的解決方案, 就是請 PM 把需求寫清楚, 我想這可能沒有成功的機會. 一方面可能是 PM 不想改, 另一方面也可能是 PM 不知道哪裡不清楚. 如果是可以從自己開始, 就可以要求自己多發問, 多寫些 examples 來跟 PM 對齊討論. 或者每當有問題時, 隨時提出想法和 PM 確認.
(4) 確認改進項目有落地
我們能有空去做改變的時間其實不多, 因此, 不需要所有事情都能去改. 但是一但說要改, 想辦法讓他是有進度, 並且把這個進展是讓大家都看到, 這樣大家才會覺得是玩真的, 我們說的話, 上面或是團隊有聽進去.
(5) 成長心態
很多事情, 心態不同, 所採取的行動就會不同. 這邊可以試試看培養團隊 Player 和 Learner 的思維
a. Player vs Victim
b. Learner vs Knower
發表迴響