iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 16
0
Agile

為團隊與組織導入敏捷的經驗分享系列 第 16

授人以魚,不如授人以漁

今天先岔開昨天和前天聊的事情,先來聊點另外的小議題:授人以魚,不如授人以漁 [^1]

身為敏捷推廣者,我們理所當然會比一般團隊成員在敏捷相關的知識上與經驗上較為豐富,也通常知道要怎麼做會比較好。但越是如此,我們就要越謹慎的是推行敏捷相關政策,避免我們會無意識的剝奪團隊成員自己尋找出路的方式,讓他們的參與感被我們太過直接的建議給剝奪了。一旦太過於頻繁的直接給出解決問題的做法,將喪失團隊自己練習解決問題的機會,這樣或是他們對於我們會有嚴重的依賴、又或是他們對於這些做法沒有認同感,導致難以落實。

引用自以前我抄錄自書籍《Essential Scrum 中文版》[^2] 上的一段話:

ScrumMaster 的態度就應該向任何一個優良的教練一樣:「我在這裏不是為你解決你的問題;相反的,我是來幫助你解決你自己的問題。」

一個很棒的 ScrumMaster,幾乎從來不直接回答問題,而是以反問法來做回應——不是那種腦人的問提,或故意為了問而問,而是有思想的、深刻的,探討性的問題——幫助人員了解到自己具備找出答案的洞察力。(一種蘇格拉底是的提問)

這邊雖然寫作 ScrumMaster,但我認為也適用於任何想要推廣敏捷知識的角色或位置。直接回答問題,就像是「授人以魚」,而透過教練式引導,也就是透過不斷地發問引發團隊思考的方式,則像是「授人以漁」。當我們直接把答案給他們時,通常他們比較不會主動思考為什麼要這樣做,而只是想「既然他說這樣有效,那應該就可以嘗試吧」,到最後你出來的東西,終究還是你的東西,不會被他們消化,變成他們的東西。

唯有透過不斷地發問去引發團隊思考,最後找出來的答案才會是深深的刻於他們腦海深處,畢竟是他們自己討論出來的結果,他們已經有思考過問題的原因,以及各種可能的做法,經過充分的討論、甚至激辯,最後好不容易才得到這的答案。獲取這個答案的所有過程,他們都參與其中。

不過這種方式無論對一個比較沒這方面能力的團隊、或是一個想嘗試但是相關經驗還不熟的推廣者、ScrumMaster 都不是一個簡單的事。在團隊還沒有辦法透過自己的能力找到適合的答案時,推廣者到底要繼續袖手旁觀還是要介入尋找答案的過程,這個平衡點是很難抓取的,這部分可能會需要和團隊嘗試交流看看。如果是兩方都沒經驗的情況下,雖然在追尋答案的過程中會更辛苦、花更多時間,但是彼此有著共識,認為沒有不變的答案、沒有最佳的解決方式,任何做法都是可以隨著時間不斷被修正、改良的,先做出一點點改變、然後逐漸改善它就是一個不錯的開始。好好秉持這類想法,我想就能夠一起成長、找到最適合團隊的答案了。


1: 原標題為〈你的東西還是你的東西〉,為了更貼近本文要表達的意思,改為〈授人以魚,不如授人以漁〉
2: 《Essential Scrum中文版:敏捷開發經典》 (Essential Scrum: A Practical Guide to the Most Popular Agile Process),Kenneth S. Rubin 著、阮聖傑、胡重威、黃柏勳 譯


上一篇
從驗證完成到開始開發的準備
下一篇
組織一起訂定產品的生命週期流程
系列文
為團隊與組織導入敏捷的經驗分享32

尚未有邦友留言

立即登入留言