課題分離

July 29 21:25~22:25

▲Eiffel內心獨白：每天睡16個小時是我的課題

 

在Teddy念國中的那個年代，學校每個禮拜都有周會。開周會的時候全校的學生到大操場集合，聽著司令台上的長官發表告誡學生的老生常談。通常校長或是訓導主任的話最多，也最沒人想聽。當時校長說了什麼老早就忘記，唯一記得的一句話是：「自己要為自己的行為負責」。

最近讀了《被討厭的勇氣》，書中提到「課題分離」這個觀念—因為某個決定所帶來的後果需要由誰來承受，就是那個人的課題。如果我們干涉別人的課題，或是自己的課題受到他人干涉，都會引起人際關係的紛擾。

***

在〈邯鄲學Scrum〉提到，有一位擔任ScrumMaster的朋友告訴Teddy，公司希望他「看到團隊有問題不能干涉，要讓他們自己發現。開會的時候也要跟隱形人一樣退居幕後，不要主導會議的進行。」這應該是希望團隊成員可以做到自我管理（自組織），自己處理自己的課題。如果ScrumMaster介入過深，會讓團隊成員以為「這是ScrumMaster的課題，不是他們的課題」，如此一來，如同《被討厭的勇氣》所說，因為不當干涉別人的課題，造成人際關係（工作）的紛擾。

但是，任何規則都有例外。在實踐Scrum的過程中，要把「時間」這個因素放進去考量：此時此刻，團隊的能力屬於什麼樣的程度？團隊改善目標是什麼？團隊目前遭遇哪些問題阻礙他們到達目標？在這些問題中，最棘手的是什麼？要如何優先改善它？

在做到課題分離之前，是否須先建立團隊對於Scrum的信心？

***

雖然Scrum規範Product Owner、ScrumMaster、Team這三種角色的責任，但從「因為某個決定所帶來的後果需要由誰來承受，就是那個人的課題」的角度來解讀三種角色的責任，這個界線有時候存在模糊與矛盾。例如，請問story沒做完是誰的課題？理論上是Team的課題，因為團隊決定如何做、要做多久。但從公司的角度來看，Product Owner或是ScrumMaster卻可能因為「Team的課題」而被責怪。

鄉民甲：這麼說應該直接把團隊叫出來罵？

Teddy：如果你同意這是團隊的課題，請問在Scrum裡面如何面對這個課題？

鄉民甲：不知道…知道我就去當顧問了XD。

Teddy：Retrospective會議應該是一個好的場合。但是，如果這個問題持續發生，也沒有在retrospective被提出來，那應該是誰的課題？

鄉民甲：嗯，看起來團隊會被影響，但有可能是團隊根本沒有持續改善的能力，所以應該不能算在他們頭上。既然ScrumMaster的責任之一是要確保Scrum被正確落實執行，所以對於「團隊沒有持續改善的作為」這件事沒有反應，應該由ScrumMaster來承受，所以算是他的課題。

Teddy：從這個角度來看，Product Owner是否需要介入？

鄉民甲：我覺得Product Owner可以提醒，但應該交由ScrumMaster來處理，因為這是他的課題，而不是Product Owner。

***

Teddy認為課題分離和當責也有關係，該自己負的責任，絕不逃避。不是自己的課題，可以鼓勵當事者採取行動，但不要越俎代庖。

要做到課題分離真的不容易，有些人可能從小到大都習慣依賴別人幫他處理他的課題—「我要問一下我爸媽的意見、這件事要先請示主管、這隻程式不是我寫的。」又或者身為家長、主管的人，放不下心讓子女、部屬負責，因而干涉了別人的課題。

《被討厭的勇氣》是一本好書，還有許多有用的觀念，日後再逐一介紹。

***

友藏內心獨白：只有自己可以改變自己。