l

2020年4月27日 星期一

怎麼當好一個ScrumMaster?

April 27 12:46~14:15


演給你看不好嗎?

接觸過Scrum鄉民應該都會同意,Scrum的三個角色:Product Owner、Development Team與ScrumMaster,其中ScrumMaste是最抽象、虛無飄渺的存在,最不容易了解,也最難扮演好這個角色。

曾經有幾位客戶要求Teddy到他們家去充當短期的ScrumMaster。這是一個很合理的速成方法,如果請有經驗的人來當ScrumMaster,團隊的新手ScrumMaster就有一個「具體的範本」可以參考。日後只要依樣畫葫蘆照著做,應該八九不離十差不到哪裡去。

但就算是在缺少業績的情況下,Teddy從來沒有答應過客戶去當短期的ScrumMaster。Teddy可以當敏捷顧問、敏捷教練、碎碎念講師(看你喜歡哪個稱呼),陪著PO、團隊與ScrumMaster一起成長,但無法擔任團隊的短期ScrumMaster。

為什麼?因為Teddy始終是個外人。ScrumMaster與Product Owner和Development Team之間是一種很緊密的團隊合作關係,唯有長期承諾,讓整個團隊知道「你是在玩真的」,這種關係才會是完整的。外在環境、專案特性、團隊成員等不斷地變化,沒有固定的公式可以遵循,很能靠一個外人「演給你看」就可以了解箇中精隨。

ScrumMaster必須現時現地去體驗各種作用力、各種限制、各種壓力、各種機會,並且不斷地嘗試、調整。只是短時間加入團隊的「外派」ScrumMaster頂多在敏捷形式提供團隊參考,但這種參考非常片面,也很容易讓人誤解。

***

動輒得咎

書上說,ScrumMaster要協助團隊排除阻礙,因此有些ScrumMaster從這一點著手,最後變成團隊有任何問題都找ScrumMaster來處理,團隊變成了媽寶,而ScrumMaster變成了寶媽

書上又說,ScrumMaster採取僕人式領導(Servant-Leadership),從這一點出發,有些ScrumMaster最後成為團隊的僕人,負責幫團隊訂會議室、安排議程、寄發會議通知、撰寫會議記錄、更新Scrum Board,以及催大家準時參加Scrum會議。僕人易做,領導難行。

也有人覺得引導技能很重要,ScrumMaster要引導團隊發現自身的問題,而不是跳下去幫團隊解決問題。再加上Scrum團隊是自組織團隊,應該有能力能夠從失敗中學習,逐漸改善。因此,當團隊成員向ScrumMaster求助時,ScrumMaster總是說:「由團隊決定」,弄到最後讓團隊成員覺得ScrumMaster的存在本身變成了一種阻礙。

***

云何應住?

依據Teddy的理解,ScrumMaster之所以存在,他要解決的問題是:「如何讓Development Team、Product Owner與組織獲得Scrum的好處?」可以從這個角度切入,來思考要怎麼做好ScrumMaster。

金剛經裡面有一段話:

「菩薩於法,應無所住,行於布施,所謂不住色布施,不住聲香味觸法布施。須菩提!菩薩應如是布施,不住於相。何以故?若菩薩不住相布施,其福德不可思量。」

把「菩薩」換成ScrumMaster,就可以知道ScrumMaster要怎麼做。

ScrumMaster依據敏捷精神,無須拘泥一定的形式與方法,只求能夠幫助開發團隊、PO與組織。不需拘泥教練、僕人領導、流程專家、干擾屏蔽、阻礙排除、變革代理。ScrumMaster要專注在協助開發團隊、PO與組織獲得敏捷的好處,不拘泥於特定形式,如此便可產生有利的效果。

有些ScrumMaster很認真,為了做好自己的工作,上了很多課。但回到團隊之後,如果做得好,他變成了一個教練、一個僕人式領導者、一個流程專家、一個保護者、一個石頭搬運者、一個敏捷轉型策略大師。做不好,他成為沒打過棒球的棒球教練、任勞任怨的僕人、技術控、太極高手(推拖工作)、吵架王、嘴砲王。

他已經不是ScrumMaster,他被切割成好幾塊

***

無為而無不為

扯了這麼多,到底ScrumMaster要怎麼做?很簡單,在敏捷精神之下,該做什麼,就做什麼。做了之後有幫助,就持續下去。沒有幫助,思考如何改善,不斷精進。

這個過程很漫長、很痛苦,因為現實世界很危險,你要靜心,忍得住孤獨、寂寞、羞辱。你可能需要一位師父、前輩、長者,與你同在,支持你走完這個過程。

最後,你渡過河,到達敏捷的彼岸,你有能力幫助其他ScrumMaster繼續他們的旅程。

***

友藏內心獨白:是在找聖人逆!

2020年4月20日 星期一

毛書一刀未剪大公開

April 20 11:28~12:45


Teddy在2012與2014年所出版的兩本書《笑談軟體工程:敏捷開發法的逆襲》與《笑談軟體工程:例外處理設計的逆襲》已經絕版一陣子了。上個周末上【Scrum敏捷方法實作班】,有學員知道書已絕版,詢問Teddy是否能提供第一本書的電子檔?Teddy也忘了之前有沒有公開提供過,所以今天就寫一篇文章把這兩本書的電子檔公開。

因為書本最後出版的格式經過悅知出版社編輯過,這個「排版編輯」版權屬於出版社,所以Teddy只能公開當初提供給出版社的原稿。編輯前的原稿與最後出版的內容略有差異,且可能有一些尚未訂正的錯字,請讀者自行除錯。

電子檔下載:

***

友藏內心獨白:紙本的比較香。

2020年4月19日 星期日

塞翁失馬

April 19 20:37~21:28


也是疫情受害者

這兩天(4/18~19)是第32梯次【Scrum敏捷方法實作班】上課日,這梯次課程很早就確定開課,但因為前一陣子境外移入的新冠肺炎案例大增,陸續有學員取消報名,最後上課學員只剩下七位,剛好湊成一組。

原本課程最低開課人數是10人,因為目前處於疫情的特殊狀況,Teddy也沒有取消該梯次。疫情期間人少一點也好,雖然收入變少免不了有點小失望,但加減賺,至少可以付房租。

***

趁亂做實驗?

Scrum課程有一個練習活動,讓學員透過User Story Mapping(使用者故事地圖;USM)作為敏捷需求管理工具。上課前一天(禮拜五)Teddy想:「既然這次只有一組,練習活動是不是可以做一些調整,試看看改用Event Storming Workshop(事件風暴工作坊)來收集需求的效果?」。

想了一天,覺得自己沒有把握在短時間的練習活動中可以讓Event Storming Workshop達到原本USM的效果,於是決定還是先維持原本的練習活動。

昨天上了一天課,因為只有一組,Teddy反而有更多的時間與學員討論(WIP=1),講得話比往常都還要多。今天(禮拜日)早上起床,邊吃早餐邊打開電視聽新聞。突然間,不知怎麼的靈光乍現,有點想通了Event Storming Workshop與USM的差別,以及兩種方法個別合適的應用情境。

雖然在Event Storming發明人Alberto Brandolini的書中提過這個問題,但讀書的當下Teddy並沒有特別深刻的領悟。也許是緣分到了,經過一段時間的醞釀,突然有點感覺了。

***

上了台就不要想賺多少錢

Teddy在吳宗憲的綜藝節目中聽憲哥說過一句話:「上了台就不要想賺多少錢」。言下之意是說,不管此次的收入多少,身為一個藝人上台之後就是要拿出最好的表演。

***

如果不是疫情,最後報名人數只夠湊一組,人數不足是不會開課的。

如果Teddy抱持著:「只有七個人,那就不用特別準備,照以往的方式上課就好。」這兩天也就這麼過去了,也不可能有今天關於USM與Event Storming Workshop的小小突破。

所以說,認真把事情做好,其他事情就交給老天爺吧。

***

友藏內心獨白:活在當下。