Agile Coaching Retreat 2021 活動雜記

面對 COVID-19 的衝擊，我們每個人的日常生活都被強迫改變，不管是出於自願還是被迫，許多人開始了遠端工作（WFH/RW），因為無法實體聚會許多活動都改成線上舉辦，因為無法去學校上課/授課，老師與學生都開始嘗試新的學習/教學模式，看著過去的照片，心想下一次可以出國旅遊不知道是什麼時候....

這時候可以問問自己，在心態上真的有準備好接受這一切嗎？還是在心裡，我們仍然這樣告訴自己，再撐一陣子就好了，再來就可以恢復正常了？殊不知這個世界真的不一樣了，很可能再也回不去了？就算疫情過去，可能面對我們的已經是完全不同的世界。

有些人等待恢復過往的生活，有些人已經開始嘗試新的生活與工作形態，而今年的  Agile Coaching Retreat 2021 就是一群敏捷教練在線上嘗試新的生活與工作型態。

 

ICA 參與式科技之轉化型行動計畫(Transformation Action Plan)

 

 

 

最近公司正在為了二轉升空正在如火如荼的制訂規劃新的 Vision & Mission & Strategy ，我也臨危授命的去幫忙帶了幾場 workshop，主要是想透過組合技 ORID 焦點討論法與團隊共創法，幫忙一線主管們回顧過去，找出影響團隊無法達成目標的障礙加以移除，並且展望未來。

 

 

雖然大家討論的很熱烈，也的確讓許多問題都浮出檯面，但是由於我忽略了幾個重要的環節，所以總覺得最終產出還是虛虛的，趁著這次的機會趕緊去報名了 ICA 今年度的 轉化型行動計畫(Transfromation Action Plan) 課程，也可以檢視上次的 workshop 有哪裡做的還不夠？

談到 ICA 的引導，就一定要先複習一下 ICA 參與式科技的引導原則：

• 包容性
• 帶著真誠的尊重來參與 (相信眾人的智慧)
  
• 探索的歷程
• 留意脈絡幫助瞭解與許下承諾
• 引導式的風格
  

要相信團隊成員的集體智慧，流程只是個工具，用來幫助思考的順暢，但重點還是尊重，並且讓大家能充分表達意見的包容力，所以引導者的觀察力與場控力真的很重要（這也得靠經驗累積）。

 

回顧與檢討 Agile meetup - 為什麼我的敏捷總是卡卡的?

故事是從敏捷診療室開始.....(其實是靠正妹吸引目光)

故事的開始

• 為什麼書上的方法用到我的組織都卡卡的? 
• 為什麼社群介紹的Design Sprint 感覺很好用但是公司PM都不敢興趣？
• 敏捷不是要短週期交付？但是客戶不願跟我們意嘗試這種方法？
• 聽Seafood 說要吸引狼屬性的成員加入並且skin in the game很有道理，可是...我並沒有招募人事權？
• 為什麼HR 都不支持我們推行敏捷？

從 2018年第一次到敏捷診療室駐診，到參加 DevOpsDays 的 Open space technology 我發現很多時候大家在討論敏捷推行問題時，因為沒有把情境與context 定義清楚，常常會有岳飛打張飛的情境出現，雖然討論的很熱烈但是似乎都沒具體的結論(不過~誰說一定要有結論，Open space 本來就只是要讓大家討論~:P)，大概是因為我大公司小公司，B2B/B2C和做專案和做產品的公司都待過，我隱約覺得問就是出在組織特性的差異。

敏捷引導者練習 - Crossroad 人生的十字路口

『交叉路口』（Crossroad）這個桌遊是由東京『慶應大學』（Keio University）的『吉川肇子』教授（ キッカワ トシコ; KIKKAWA TOSHIKO）根據 1995 年的日本阪神大地震於 2003 年所設計出的『模擬遊戲』，同時於 2004 年時在京都大學正式發售。

 在網路上能找到的就只有這篇文章：Select “Yes” or “No,” then simulate and pass down disaster experiences Naomi Hama, Director of Kobe Crossroads Society

[引導型敏捷領導力課程] 談管理、領導與追隨

趁著假日陸續整理和和消化之前上課的筆記，有許多東西值得好好回味和思考，話說引導型敏捷領導力課程的第二天，我們談到了管理（Management），領導（Leadership）與追隨（Follow hood），前面兩個詞相信大家一定都不陌生，畢竟這就是我們想學習的東西，但是追隨呢？到底什麼是追隨，在討論中我們不時的把追隨想成追隨者，也就是有人領導就要有人追隨，但是在一個Autonomy 的組織中誰是領導者？誰要追隨誰？如何追隨？怎樣算是好的追隨？

鳳凰項目沙盤推演 workshop 遊戲流程

話說這本鳳凰項目 - 沙盤特別版在市面上買不到，只有授權的原廠才有賣，在開始介紹遊戲流程前，先解說一下這個遊戲的由來：

鳳凰項目 DevOps 沙盤是由歐洲著名沙盤遊戲研發機構 Gaming Works 的創始人 Jan Schilt 先生聯手《鳳凰項目》一書的作者 Gene Kim 先生，開發的同名沙盤演練課程。  鳳凰項目沙盤演練覆蓋了業務場景中所有的職員角色，尤其是那些從事 IT 開發以及 IT 運維工作並希望通過精益(LEAN), 敏捷（AGILE）和 IT 服務管理流程如（ITIL®）等最佳實踐來提高 IT 服務表現或通過 IT 解決方案為業務創造價值的 IT 專業人士。該沙盤同時也是為那些通過創建更好的協作氛圍並最終實現更高效以及更精確的 IT 解決方案部署的企業。

延續上一篇 -  鳳凰項目沙盤推演 workshop 感想，在這邊我先大略描述一下遊戲的內容與大致的流程，遊戲設計的角色，以及要做的工作。

鳳凰項目沙盤推演 workshop 感想

原本想要下的標題是 "紫衣教" 老司機們團報踢館鳳凰項目沙盤推演 workshop ~XD

話說這次參加鳳凰項目沙盤推演 workshop 的成員組成，除了少數不知道怎麼被拐來的人(還是有人連鳳凰項目書都沒看過就被拐來)，大部分的都是敏捷界的老司機，粗略估算一下組成和經歷：

• 80% 被Daniel 開過腦洞
• 40% 有參加過ICA 辦的引導型敏捷領導力課程
• 30% 有參加過呂毅 Less

有參加過這幾種課程培訓的，參加這種workshop 根本就是小菜一盤，首先的起手式就是把工作視覺化，一開始就透過 Kanban 來安排工作，甚至還不斷的演進，每一輪都更新我們看板的格式，為了就是讓工作更加順暢。

Agile 已死

最近在Agile 社群有一篇文章受到熱烈的討論，是關於 Agile 已死的相關問題....
說實在的我並不在意~
不過今天聽完Daniel 的18+成年人的分享我有新的感觸~~

Agile Meetup - 失敗的 agile 經驗 與 Agile East 2012 巡禮

Source: The essence of Agile

這次應該是第三次還是第四次參加AgileCommunity.tw Meet-up了吧？話說 Agile Community tw 算是個年輕的組織，一直一來都在摸索找尋更好的分享與討論方式，因此本著Agile Incremental improvement 的精神，每次聚會完大家都會一起檢討並且找尋改進的可能性，所以這一次聚會除了5min sharing talk外，還增加了TAD Talks為了就是讓每次聚會更有主題性。

因為根據前幾次5min分享的經驗，來參加的人來自各種不同類型公司，有開發專案的，有開發產品的，有大公司的，有Startup， 所以分享的主題可能就會非常多類型(發散)， 而且實行的程度也有蠻大的差異，有些人跑完整的Scrum，有些用Kanban，更多的人是只取Agile的精神，或是執行其中的幾個方法(Daily meeting or User Story ...等)，不過這也更讓大家了解到台灣業界的狀況，以及大家遇到的困難。

第一次參加AgileCommunity 聚會

圖片來源：Gwen  世界萌貓系列月曆預購中

上次看到喲哪桑所寫的文章關於 AgileCommunity.tw 的第一次聚會，就很想去參加，但是卻因為"五分鐘的分享"這個門檻的存在，一直猶豫要不要報名，一方面不知道該從那個角度切入去分享，一方面想說...五分鐘？可以講什麼？要講的多深入(阿就五分鐘你要多深入)

不過後來就還是硬著頭皮做出了投影片去參加了，不過五分鐘時間果然真的很快，根本就來不及講完投影片~XD 找了很多周星馳電影的梗來用，不過感覺Timing都沒抓好~:P

如何利用Jira + structure 做需求管理 

參加心得：

可惜時間太短，所以沒有機會好好多認識來參加AgileCommunity.tw 的高手和前輩們，希望下次能有機會多跟大家交流交流。

另外同樣是在實行Agile和Scrum，但是卻可能因為很多因素會遇到不同的問題，像是：

• 不同角色：
• RD
• PM
• QA
• Customer
• 不同開發性質：
• Start-up 的產品
• 已經上線很久穩定的產品
• 需求變動較多專案
• 需求比較固定的專案

將來也許可以根據這些角度做分門別類的討論。

Scrum大師講座 (Emerson Mills)

Source: 網路

昨天去參加由泰迪軟體主辦、ezScrum 協辦的 Scrum大師講座(Emerson Mills)，真的是覺得物超所值！！而且大師一出手便知有沒有，外國的和尚果然比較會念經...XD此外這次的活動又解決了我許多心中的疑惑，也更加了解國外軟體開發的現況，但是對於Emerson 所說 Do not pre-architecture too mush 嘖嘖稱奇~看樣子還要多去找找這方面的資料。

[ Update 2012.08 ] 延伸閱讀：
Agile(Scrum)與Architecture是否有矛盾或衝突 (1)
講座開始前，Emerson先請大家把想要問的問題寫下來貼在牆上，他會找時間一一回答。

 

下圖是Emerson在講軟體開發的本質與價值所在，我非常喜歡這個講解，橫軸是技術(How)，越右邊代表越不確定性，縱軸是需求(What)，越上面代表需求越不明確，由這張圖可以做以下簡單的分類：

• Simple (簡單)   ：需求明確，技術已知 (沒樂趣，沒挑戰)
• Chaos (混沌)    ：需求未知，技術不明 (通常也無法做)
• 複雜 (Complex)：需求稍微不明確，技術已知 or 技術尚待確認，需求明確
• Complex & Complicated：需求不太明確，技術仍有需要研究的

而通常Complex & Complicated的案子才是有value (價值)能換錢的，也是對於工程師比較有挑戰的。




下圖是Emerson (Odd-e)版的Scrum sprint 圖，跟我之前看的比較不一樣，裡面有特別點出一些眉角是一般書沒有提到的，一個Sprint (iteration)有幾個重要部分：

•     開始前的 Sprint Planning Meeting (這邊有分 Part 1 和Part 2)
•     進行中的 Daily Scrum 
• 預設保留的 Product Backlog Refinement (至少要保留5~10%的時間做 Refinement)
• 交付or展示 Potentially Shippable Product Increment (PSPI)
•     結束後的 Review Meeting (這邊也有分part 1 和 part 2)

如果單純看圖一定不知道這part 1 和part2 有什麼差別和重要性 (可能只會以為是中場休息)，但是聽Emerson講解完後整個豁然開朗，才發現這兩部分才是最重要的核心所在，也會是專案成敗與否的關鍵，其他daily scrum 反而算是比較枝微末節的事。(我再另外寫一篇文章"part1 與 part2 的內容與重要性"講解，我所理解的這個部分)。

下圖是在解釋backlog的重點就是Prioritize，你可能會依照Business value、Risk、Cost...等去排，沒有一個標準，這必須依照各家公司的狀況調整，舉例來說 Value和Cost 這是常常會遇到要比較的問題，一個對客戶有價值Value的東西可能Cost很低，但是一個Cost 很高的東西(要花很多時間研究，佈署調教，準備環境..等) 客戶卻可能看不到其價值，但是不代表他沒有價值！！

下圖是Emerson重新再講解整個Scrum scope 以及 Scrum master 要負責的部份，簡單來說就是全部！Scrum master 的角色說實在是一個很神奇的存在，他並不能套用在現今傳統組織架構的任何角色，他不是管理人員，他只是一個教練。

Scrum Master 可以做什麼 (他的職責比較像Project Manager的部份)

• 要負責整個Scrum的順利
• 要了解整個team 的狀況
• 要思考怎麼imporve team productivity
• 思考目前有什麼在影響team的進步
• 要負責保護整個team 的獨立運作性、不被外面的人打擾...等

Scrum Master 不可以做什麼 (他沒有Project manager的權力)

• 不能要求team加班
• 不能"強制" 要求team多做需求(可以溝通)
• 不能"強制" 干涉團隊成員的決定(可以建議)

因為scrum 的最高精神 "Team must self management !! "，就像我之前文章整理的"敏捷式開發的領導與管理 "裡面提到的僕人式管理。



下午的Panel discuss Emerson也提供了許多建言：

• Do your job ,and improve your job. 
• You need to know why, so you can improve it.
• Team shared responsibility. (All of the whole)
• Creativity means freedom to fail 
• Trying uncertain leads innovation
• Scrum is focus on improve team capability and performance, not focus on software quality. Software quality  is the result.
• Scrum is not about management, is about leadership (他舉了這個影片當範例：First Follower: Leadership Lessons from Dancing Guy ) Scrum master 要引導大家發言，如果一個會議大家都不說話，這也是一個失敗的scrum
• 當你在學別人的Scrum (所謂best practice)必須額外小心，因為這等於就是copy他們的環境和文化。
• Performance review (KPI) will hurt scrum team! Evaluate team as a team. (如果其中有害群之馬，或是無法跟上team的速度與節奏，就要由team member 再review meeting  上提出，review 某人的performance，甚至把那個人踢出，不過這在台灣似乎很難...)

最後，Emerson 給要Run Scrum 的team 三個建議：

1. A fixed team
2. All work come from one product owner
3. Keep Project manager out  (最後一點，應該會有很多人不能接受吧~XD)

插曲：這張照片剛好拍到XDite 大大耶~:P 她好像最近都有去參加ezScrum所舉辦的活動。

參加 ezScrum workshop 心得

今天最有感覺的一句話 (Soruce:喲哪桑的投影片)

今天去參加ezScrum所舉辦的活動，想要了解其他公司目前Scrum運作的狀況，以及看看會不會有其他新的啟發，或是有沒有什麼值得我們學習的地方。主講者有兩位，一位是搞笑談軟工的Teddy，另一位是喲哪桑Speaking 之專案工作日誌的 Jonathan 這兩位很久以前就有在看他們的Bloger，今天終於可以一睹廬山真面目，Teddy 在演講與搞笑的功力真的是一流，但是業界實務經驗我就不確定了(畢竟只有50min 可以報告)。而Jonathan 之前在趨勢科技待了十幾年，現在有跳出來在一家新創的公司waveface當scrum master，所以實務經驗非常充足，然後他在分享他們在運作Scrum的經驗，讓我真的很有感觸，因為幾乎所有的狀況我們也都有發生過，然後我們也都是有嘗試各種的方法去改善，其中心思想就像第一個投影片講的"欲改善行為，先改變結構"，所以要改善某些行為與產出結果，組織必須要能靈活的調度，當然員工和管理者也必須以開放的心態來接受。


先說結論，就是發現我們公司其實Agile的味道與精神都已經有抓到了，而且比起外面已經算是不錯了，但是還可以在更好，也就是再度套句 Ken Schwaber 的話來說：Scrum不是一個方法學，它是一個框架(Framework) ，所以我們要在這個Framework內做調整，挑整出屬於我們的Best practice。

下面是幾張我比較有感覺的投影片：

要實行Agile真的要想辦法打破部門的隔閡，組織一個task force ，讓team member能專注在這個案子上，效果才會好。 (因為在場有許多公司有提到這個問題)

team member在分組上，通常有兩種分法，我們也都有試過：

• 一種是縱向由平台或功能面分：
• 比如說你比較熟後端，你比較熟前端，你比較熟iOS，你比較熟Android。
• 一種是由Epic (較大的User Story)來分
• 讓要做同一個Epic的人一組，一起來討論

Designer 和 Engineer 如何良好的合作的確是一個難題，而我們後來也是嘗試讓這兩種角色Pair programming 讓互相知道對方的難處與思考邏輯。(遙想當年我就是這樣把到老婆的XD)

最後就是Product owner 其實本身必須具備Designer 與 SA的能力 (如果沒有那至少找這兩種角色來幫你)，因為一個好的User story 也必須把UX flow  考慮進去。

另外我也有在這個work shop 問一個問題，這個問題也困擾我很久，就是backlog到底是什麼時候要產出，這個時間到底要算在哪個階段，因為以waterfall的開發方式，backlog的產生通常就是kick off meeting完後，SA&SD 根據RFQ去產生類似Use case 文件(專案需求分析書)，以Agile 來說backlog裡面放的user story是不用那麼詳盡，但是也是需要花時間準備啊，而且在每個sprint中，可能也會有新的需求和user story放入backlog，所以Product owner也必須要花時間為下一次的plan meeting做準備。

看樣子我還是得花時間把Agile的武功密集都研究研究，看看有沒有提這一塊....

(Teddy 引用鹿鼎記的梗~XD)

這是武功密集的目錄

這些才是武功密集