第一次參加 Agile community in 內湖辦的社群活動 (2017 年),同一天其實也是 C.C. Agile #59,當初報名時想了一下,C.C. Agile 從開始到現在,幾乎快要場場都到,似乎有點在同溫層打滾,是否該換個客場,看看其他地方的社群活動,加上這次的主題很有意思,畢竟自己也算是類似主題的前輩 (老王賣瓜),想看看看別人怎麼 run 的。
題外話,其實上完班很累,常常回到家就是搞自閉,根本不想講太多話,所以就 pass 這次 C.C. Agile #59 (open space) 了。
不過,內湖真的很遠,從台北車站過去,都快要一個小時,但看到雙主講也是挺新奇的,由 product owner 和 scrum master 唱雙簧,不是吵架,就是一種挺有趣的體驗 (澄清一下,我擔任 scrum master 時是不跟 PO 吵架的),投影片有分享出來,大家可以自己看,只可惜很多照片是公開版看不到的。
內容蠻有趣的,有幾個點我都發出會心一笑,像是第七頁上寫著:
沒有用什麼高深的東西,就只是”守”
是啊!就這樣,但不容易做到,常會聽到:「啊~因為 x,所以我們不做 y」或是「啊~我們已經夠成熟了,不用 z 這麼麻煩啦」,xyz 可以填很多種組合,然後效果出不來之後又說:「啊~ scrum 沒用啦~」,然後走回頭路,或進行著很奇怪的 scrum,又或者宣稱在 run scrum。
兼任 Android App Leader 要保持中立
之前我也是架構師兼 scrum master,在主持會議時,或是在會議進行時,其實要保持中立是不太容易,自以為中立,和團隊成員認為你是中立是兩回事,這也是為什麼大多數教練不建議 scrum master 兼其他角色的一個原因,不過現實中這一點在預算較不充裕的團隊還是得兼任,這時考驗 scrum master 與團隊的默契了。
進步是需要時間,別堰苗助長,或打特效藥
第 13 頁有張圖表,是 3 個 scrum teams 在 12 個 sprints 中完成的 story 點數統計,從不到 100 進步到接近 400,然後再看第 16 頁有句話特別有意思:CTO 插手 sprint planning,團隊已經表示吃不下了,還是硬塞事情,但從圖表上以及 sprint 1 最後延長一週來看,這插手根本是多餘的。
可以失敗,不要瞎做
別害怕失敗,fail fast; learn faster,若讓團隊覺得上面很在意時數沒有按著線圖走,那會得到一張漂亮的線圖,但到 sprint 的最後一天東西還是沒做完;若讓團隊覺得上面很在意為什麼一個 sprint 只能吃這麼少點數時,那會得到一個 sprint 能吃很多點數,但產出還是沒增加;就如同以程式碼行數當 KPI 時,會得到一大坨垃圾。過度在意失敗,會讓團隊失去嘗試的勇氣。
投影片中沒有提到 refinement meeting 怎麼做需求的釐清與 story 的產出,所以在投影片講完後提問,其實這方式蠻不錯的,原有的數個 PM,在團隊開始跑 scrum 後,角色轉變成 PO 小幫手,還是負責對外收集與整理需求,但會在 sprint 進行期間找時間和部分團隊成員討論,然後進行設計,再切成 stories,跟 PO 確認 priority 後送入 refinement meeting,與所有團隊溝通,由團隊自行認領 stories 進行細部的規畫與拆解 (task)。
最後一個是不管團隊進步的幅度如何,不相信的還是不相信,若是不相信的人是開發人員,可能還是把他/她調離開團隊 (其他部門或團隊) 或是找其他方式減少對團隊的影響;若不相信的人是團隊外的人,PO 及 SM 要堅強一點,多處理政治上的問題。
可能正好碰上疫情吧,加上下班後真的累了,這幾年很少跑社群了,這類的分享文恐怕是會越來越少了。