回顧反模式

如果你使用回顧,或任何一種人們應討論並從討論中學習的會議,你會時不時經歷到效率較低的會議。這並不令人意外,而且發生在多數人身上。本文描述並提供三種不幸情況的解決方案:跳過產生見解、迷失在無法改變的事物中,以及被大嘴巴主導。

2023 年 2 月 15 日


Photo of Aino Corry

「回顧反模式」作者 Aino Corry 是一位教師、技術研討會編輯和回顧促進者。她擁有電腦科學碩士和博士學位。她還教導教師如何教授電腦科學,因此不負其公司的名稱:Metadeveloper。Aino 曾居住在斯德哥爾摩、隆德和劍橋,但現在回到丹麥奧胡斯,與她的家人和不斷增加的絨毛頭足類動物收藏品一起生活。在她的空閒時間,她會跑步和唱歌(但不會同時進行)。


回顧 的概念幾乎永遠存在,但並不總是使用這個名稱。只要人類存在,我們就一直共同回顧活動,試圖從中學習。在狩獵後、出生後、比賽後、手術後等等。

Norman Kerth 是第一個在 IT 世界中將其命名為「回顧」的人,他在 2001 年出版的書中:專案回顧 - 團隊檢討手冊 中描述了一種正式的方法,用於保存從每個專案的成功和失敗中學到的寶貴教訓。這本書以詳細的場景、富有想像力的插圖和逐步說明,開啟了我作為回顧促進者的旅程。我喜歡這個想法,並開始實施它,首先在我的團隊中,然後在其他團隊中,後來在我的組織之外。活動「主要指令」「發展時間表」「我太忙了」和其他活動都來自他的書。

稍後,Diana Larsen 和 Esther Derby 寫了一本書:敏捷回顧 - 讓好團隊更棒。這本書引入了較短的回顧,以符合敏捷流程。這對我來說是個改變遊戲規則的時刻。她們的書幫助我規劃更短、更有效率的回顧,同時也包含了協助我以更有效率的方式規劃回顧的實際流程工具。

在 Norm Kerth 的書問世之前,我們只知道驗屍。驗屍是在發生問題後進行的較長反思。驗屍作為一種從錯誤中學習的工具非常有用。如果執行得當,它可以對相關人員產生療癒效果,但它與回顧不同。即使事情進行順利,我們也會進行回顧。這就是 Derby Larsen 的書的副標題是「- 讓好團隊更棒」的原因。

但是,我對回顧的實際經驗也讓我看到回顧很容易變得沒有效率。如果你沒有遵循回顧的理念,只是照表操課,你就會浪費時間。由於敏捷方法的普及,回顧已經變得非常普遍。這種成功對回顧來說已經變成一個問題。每個人都必須進行回顧,但他們沒有花時間學習如何正確地促進回顧。這導致許多非建設性的,有時甚至是有害的回顧。當人們聲稱回顧是浪費時間時,我常常同意他們的說法,因為我聽說他們是如何進行回顧的。幾年後,我開始注意到出錯的模式,包括我自己促進的回顧。

丹麥的故事

一家組織決定在軟體開發方式上變得更敏捷。作為其中的一部分,他們引入了回顧作為一種學習方式。一些團隊成員認為回顧「妨礙」了「實際」工作。他們建議回顧可以比預定的 90 分鐘短。由於促進者在回顧方面經驗不足,她決定接受這個建議。

為了花最少的時間,他們縮短了回顧時間。這帶來了許多負面後果。讓我們專注於此處的一個反模式,我稱之為幸運輪[1]。在現實世界的幸運輪中,你有時會得到獎品,有時會輸。輸贏是隨機的,你無法做任何事情來提高機率。這也可能發生在團隊的回顧中。

促進者決定使用流行的「開始、停止、繼續」活動來收集資料。但為了節省時間,他們跳過了產生見解的步驟,這是回顧的 5 個階段之一。相反地,他們從收集資料跳到決定要開始做什麼、要停止做什麼,以及要繼續做什麼。

對於這個活動,促進者貼出三張海報,一張寫著「開始」,一張寫著「停止」,一張寫著「繼續」。接著,她請團隊寫下便利貼,並貼在海報上。其中一張便利貼寫著「開始配對程式設計」,另一張寫著「停止舉行這麼多會議」。團隊可以從中產生行動重點:「每週三天,進行三小時的配對程式設計」。以及「週三不開會,午餐後也不開會」。20 分鐘後,回顧就結束了!

這種舉行回顧的方式可能會造成嚴重的後果。如果便利貼只顯示症狀的解決方案,而不是實際問題,你只能解決表面問題。團隊沒有進行配對程式設計的原因,或許不是因為他們忘記了,而是因為心理安全感不足。在這種情況下,強迫他們在行事曆中排定時間表並不會有幫助。他們要不還是不會去做,要不就是會去做,但人們會感到不舒服,並離開團隊,甚至公司。

沒有進行配對程式設計的另一個原因可能是,他們不知道如何在遠端設定中進行。同樣地,這是一個無法透過在行事曆中排定配對程式設計時間來解決的問題。

會議的便利貼也適用相同的原則。會議的問題可能是品質,而不是數量。在這種情況下,減少會議次數並不會解決問題,只會讓問題變得不那麼明顯。當團隊要求減少會議次數時,通常可以透過改善「會議衛生」來解決真正問題。

幸運輪

當團隊「解決」症狀而非問題時,問題仍然存在,並且會再次出現。就像真正的《幸運輪盤》一樣,他們可能會幸運。他們解決的一些問題可能是真正的問題。但我們通常只看到症狀,並急於採取「解決方案」,而這些解決方案並未解決根本原因。結果是,即使這些短暫的回顧也感覺像是浪費時間,因為只討論和應對症狀是浪費時間。

反模式必須有一個「重構解決方案」,也就是一個比反模式解決方案更好的解決方案說明。在這種情況下,重構解決方案是確保在決定要採取什麼行動之前產生見解。在得出結論之前。您可以透過簡單地討論出現的問題來做到這一點。或透過「5 個為什麼」訪談。如果看起來像是一個複雜的問題,魚骨分析可能會很有用。複雜問題的範例包括「錯過截止期限」或「未遵循同行審查程序」。這樣說起來,它們聽起來很簡單,但簡短的說明隱藏了一個複雜性:這些問題可能有多種不同的原因。

陷入困境

在下一次回顧中,出現了另一個反模式。團隊希望討論供應商提供的糟糕軟體對他們造成的影響。軟體品質對團隊來說是一個持續的問題。他們自己的軟體系統受到此問題的嚴重影響,而且他們已嘗試將問題升級到管理階層。團隊之前已經討論過這個問題很多次。每次討論時,他們都會感到沮喪和難過,而且什麼都沒有改變。這讓回顧感覺像是浪費時間,因為討論他們無法改變的事情「就是」浪費時間。這是反模式身陷泥沼的範例。

當你身陷泥沼時,你會花時間在無法改善的事情上。而不是了解並改善你可以改變的問題。

重構解決方案是使用一項稱為身陷泥沼的活動,其中你要求團隊將他們正在討論的事情分成他們可以採取行動的事情、他們可以影響的事情,以及身陷泥沼的事情。當事情身陷泥沼時,它們是你無法改變的生活的一部分。你最好花時間接受並找到適應情況的方法。或透過讓自己脫離泥沼來改變你的情況。你可以在收集資料後立即使用此活動,如下所示。或者,你可以在決定要採取什麼行動時使用它,以避免在回顧時留下不在你的能力範圍內執行的行動點。

In the Soup activity               during Gather Data

圖 1:我們可以做的事情、我們可以影響的事情、身陷泥沼的事情。

大嘴巴

在這個團隊中,他們現在知道如何將時間專注在他們可以改變的事物上,並且他們已經了解到花時間產生見解是多麼有價值。但他們仍然有一個問題。團隊中有一個大嘴巴。在回顧的所有討論中(以及所有其他會議中),這個大嘴巴會打斷並講述冗長的故事,讓其他團隊成員無法參與。主持人試圖邀請其他團隊成員發言,但情況並未改變。

這種反模式經常被發現,但並不難解決。首先要注意的是為什麼它是一個問題。有些人可能會說,如果某人有話要說,那麼就應該允許他們說出來,我同意。但對於回顧來說,團隊有時間分享、欣賞和共同學習。如果只有部分團隊成員能夠做到這一點,那麼時間可能會部分浪費。

對於有大嘴巴的團隊來說,經過重構的解決方案是避免全體討論。相反,將人員分成更小的組,甚至成對討論主題。您還可以引入更多寫作和移動便利貼而不是說話。[2]在回顧之後與大嘴巴交談甚至是有益的。他們可能沒有意識到他們對他人的影響,而且他們通常非常感謝了解到自己這一點。我曾與大嘴巴合作,他們發現意識到這種傾向改變了他們生活的更多方面。有些人是我們所謂的「積極思考者」,他們需要說話或做些什麼來思考。顯然,他們在思考時需要大聲說話,但這並沒有什麼壞處。

在本文中,您已了解回顧促進中最常見的三種反模式,現在您有一些提示和技巧,了解如何避免陷入其中一種。但請記住,促進者最重要的技能不是熟記大量活動,而是傾聽、運用他們的智慧來緩解衝突,並持續反思和學習對他們有效的方法。


進一步閱讀

您可以在我的書回顧反模式中閱讀更多關於這些回顧反模式的內容。在書中,您將找到 23 種回顧反模式,每種反模式都描述了促進回顧的常見挑戰、克服該挑戰的實用想法,以及我發現自己處於該反模式時的一則個人軼事。本書基於 15 年以上的回顧促進經驗,以及 20 年以上的學術和產業教學經驗。我花了一些時間研究如何教授和學習電腦科學,在該研究中,我發現了很多關於為什麼有些事情有效而有些事情在教學和促進方面無效的輸入。

註腳

1: 每個反模式都有圖片和名稱,讓人更容易記住並注意它們。通常是章魚,因為我喜歡章魚

2: 有趣的是,這些建議對「大嘴巴」中非常安靜的人也很有效。

重大修訂

2023 年 2 月 15 日:發布