圖片來源：www.freepik.com
第一次參加 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 要堅強一點，多處理政治上的問題。
可能正好碰上疫情吧，加上下班後真的累了，這幾年很少跑社群了，這類的分享文恐怕是會越來越少了。
