l

2018年10月24日 星期三

此流程非彼流程

Oct. 24 22:14~23:07

螢幕截圖 2018-10-24 23.07.10

▲工作中的阻礙


幾年前有一次機會參加一個行政團隊的sprint review與retrospective會議。這個團隊剛開始接觸Scrum,他們對於Scrum的理解是由公司內上過Scrum課程的同仁所傳授。在review會議中,同仁甲展示他的工作成果—召募新人流程。他將這個流程視覺化,並比較舊有招募流程與新流程的差異。

Product Owner對於這個展示沒說什麼,倒是Scrum Master問了很多問題。Scrum Master以前是行政部門主管,跑Scrum之後轉為Scrum Master。

***

Review結束之後,在retrospective會議Scrum Master請團隊成員各說出三個好的與三個有待改善的項目。

同仁甲:我覺得Scrum Master要求我們將自己工作流程視覺化這一點很好,讓我比較容易看出現有流程有問題的地方。有待改善的地方就是關於校園招募這部分,我覺得吸引學生來填寫資料的誘因還不夠,這部分的流程以後還可以加強。

就在每位同仁都發表意見之後,Scrum Master請Teddy提供一些建議。

Teddy:我想請問你們知道retrospective會議的目的是什麼嗎?

Scrum Master:知道啊,就是流程改善啊,讓我們可以越做越好。

Teddy:你說的沒錯。請問各位同仁,你們剛剛所提出Good與Improvement的項目,是屬於需求面的改善,還是流程面的改善?

此時安靜了幾秒,大家你看我,我看你,對於Teddy所提出的疑問,大家一臉黑人問號的感覺。

Scrum Master:我不懂你的問題,我們剛剛提出來的的確是流程的改善。像是同仁甲就很明確提出他在校園招募流程方面的改善建議。

Teddy:同仁甲,請問您的主要工作是什麼?

同仁甲:我負責招募與其他人事方面的工作。

Teddy:所以新人招募是你提供的服務,對嗎?

同仁甲:這是我的工作,要說是我提供的服務也可以。

Teddy:你們是行政團隊,不像開發團隊需要寫程式,做出可動的軟體。你們所提供的「服務」就是你們的user story

Scrum Master:所以你是說,我們剛剛都在討論「需求的改善」?

Teddy:沒錯。

同仁甲:可是我們討論的明明是「流程改善」啊,以我來說,我談的是招募流程改善。

Scrum Master:啊,我知道了。我們實作的「需求」,是對公司提供某種服務。我們討論的都是這些服務的流程,就好像軟體功能怎麼被使用的流程一樣,這是屬於需求的範疇。

Teddy:沒錯。

Scrum Master:我還是有一點不明白,retrospective所謂的流程改善,是什麼流程?

Teddy:是團隊合作的流程,有什麼阻礙存在,讓團隊無法更快、更好的交付價值給客戶。

Scrum Master:可以舉個例子嗎?

Teddy:例如,我觀察到你們每個人所負責的工作彼此獨立,無法互相幫忙。這對你們來說會是一個問題嗎?如果有同仁請長假,他所負責的工作會不會無法進行?你們在提供服務的時候有沒有遇到什麼阻礙?是否很清楚用人單位的需求?會不會經常發生找到人被RD打搶等等問題。

Scrum Master:如果撇開Scrum不談,難道我們不能找時間討論我們提供服務的流程嗎?為什麼要侷限在retrospective所規範的活動範圍?

Teddy:團隊當然需要時間來討論供服務的流程,也就是你們團隊的需求。在Scrum框架中,你們可以在product backlog refinement workshop討論,也可以在sprint planning討論,但不適合在retrospective討論。

Scrum Master:可是我就是不想被框架限制住啊。

Teddy:你會在告別式的時候包紅包嗎?

Scrum Master:啊?當然不會啊,我沒那麼白目。

Teddy:那你為什麼要在retrospective討論需求改善呢?如果你在這個活動討論需求,請問你要在什麼活動討論「工作流程改善」?Sprint planning嗎?不會吧。

Scrum Master:是不會啦…

***

友藏內心獨白:先學會走再看看要怎麼飛。

2018年10月22日 星期一

Scrum Master的兩個魔咒

Oct. 22 13:21~14:20

螢幕截圖 2018-10-22 14.18.00

▲兩個搗蛋鬼


Scrum「大濕」

對於Scrum而言,Scrum Master是一個很神奇的存在。正所謂「好的Scrum Master讓你上天堂,不好的Scrum Master讓你住套房」。這個角色似乎成為Scrum成敗的關鍵因素,理論上你的Product Owner和開發團隊甚至整個公司一開始很爛都沒關係,在Scrum Master的輔助之下,透過持續改善的過程,Product Owner和開發團隊的不足之處都可以慢慢地變好。

理論上…

***

自組織魔咒

Scrum的開發團隊是自組織團隊(請參考〈自組織〉),因此有些Scrum Master會採取所謂的「主動不做任何事」的模式,從旁觀察團隊。當團隊遭遇問題時讓團隊成員自行解決,既使解決的過程產生各種大大小小的失敗也視為學習所需付出的必要成本,Scrum Master儘量不要跳出來幫團隊解決問題。

這一招對於已經具備「自我餵食」能力的團隊成員可能會很有效,但如果團隊成員尚未具備「自我覓食」能力之前就貿然將其放生,最後結果可能不是放生而是放死。從生物的角度來難,當個體還屬於幼年時期,需要的是更多父母親的照顧,然後在個體成長的過程中慢慢培養自組織的能力。

曾經有朋友告訴Teddy,他離開Scrum團隊的原因居然是因為看不慣Scrum Master主動不做任何事的行事風格。團隊也想要自組織、靠自己的力量排除阻礙,但問題是團隊目前就是無能(尚未具備此能力),都跟你發出求救訊號你還置之不理,身為Scrum Master總不能只靠主動不做任何事這一招打通關吧?!

***

寶媽魔咒

為了讓團隊運作順暢,impediment removal(阻礙排除)佔了Scrum Master最多時間,這種情況在初導入Scrum的團隊中特別明顯。

屏幕截图 2017-05-11 01.46.58

▲節錄自《Essential Scrum》,


雖說Scrum Master需要幫助排除阻礙,但幫助不等於自己動手做,而是讓團隊具備自己排除阻礙的能力。有些過於積極與熱心的Scrum Master可能會認為處在「幼年期」的團隊尚未具備「自我覓食」的能力,如果放任他們自生自滅,將會落入自組織魔咒而無法自拔。因此Scrum Master開始扮演一位認真的新手媽媽,對孩子照顧的無微不至。

在不知不覺中,團隊只要遇到無法解決的問題全部丟給Scrum Master幫忙處理,久而久之Scrum Master變成寶媽,而團隊成員則變成了媽寶。

Teddy認識一位技術很強的Scrum Master,在團隊剛導入Scrum時扮演寶媽的角色,自己動手幫助團隊解決幾個關鍵的技術問題,讓團隊在導入Scrum初期,在兵荒馬亂的過程中增加關鍵穩定軍心的助力。而在團隊熟悉敏捷開發精神與Scrum框架之後,慢慢淡出舞台,切換到主動不做任何事的模式。

***

沒有一定的形狀

好的Scrum Master,沒有一定的樣子。不要看到別人主動不做任何事,以為回家後照做就會成功。別人的Context與你的Context不一樣,無腦照抄解決方案,到時候失敗再來哭哭討拍,抱怨Scrum不適合台灣人乃至整個亞洲人的特殊體質。

套句PPT上鄉民常說的一句話:「正妹不是不給約,而是不給你約」。反思一下,這是正妹(方法)的問題呢,還是自己(團隊)的問題。

***

友藏內心獨白:要先確定是不是正妹。

2018年10月17日 星期三

增進學習力的三個練習

Oct. 17 22:13~22:47

螢幕截圖 2018-10-17 22.09.28


Teddy在北科上課時經常指定學生回家閱讀教科書或技術文章當作家庭作業,隔週上課再討論閱讀內容。大部分的學生並不擅長抓住內容的重點,閱讀經常只停留在字面上的涵義。

Teddy不是什麼閱讀專家,但多年來發覺把握以下三個重點,可以幫助自己在閱讀技術文章時看到不同層次的問題,也可以提升自己的「教學力」。

  • 1. 定義:對於重要的名詞或概念,能否用簡潔的字句說出它的定義?例如,試著說出以下名詞的定義:多型(polymorphism)、迭代與增量(IID)、敏捷、Scrum、軟體架構、設計模式。
  • 2. 比喻:能否用一般人聽得懂的方式說明重要的名詞或概念?例如,用下圖的磨豆漿來解釋迭代與增量就比較容易讓鄉民們理解。

螢幕截圖 2018-10-17 22.29.34

▲圖片節錄自 https://goo.gl/YgiMyr


  • 3. 找問題:名詞或概念通常代表某種產品或解決方案,也就是建築師Alexander所說的Form。學了一堆名詞與解決方案,如果不知道它們用來解決什麼問題,很容易發生吃錯藥的情況。就好像學了一堆design patterns但卻不知道每一個pattern要解決什麼問題,所以就很容易誤用pattern。

有一個很簡單的自問自答練習,可以幫助自己發覺名詞與解決方案背後所要解決的問題是什麼。只要問自己:

If X is the solution, what is the problem?

例如:

  • If polymorphism is the solution, what is the problem?
  • If IID is the solution, what is the problem?
  • If Agile is the solution, what is the problem?
  • If Scrum is the solution, what is the problem?
  • If software architecture is the solution, what is the problem?
  • If the design pattern is the solution, what is the problem?

***

只要把握住這三個簡單的重點,相信可以把技術文章看得比別人更透徹。

***

友藏內心獨白:桌子要解決什麼問題?