收到 Max Lai 關於敏捷旅程台中的 Keynote 分享邀請時，我真的蠻高興的。第一因為出生於台中，對台中總是有一份特殊的情感。第二是分享的主題是組織轉型，剛剛好跟十月在新加坡敏捷年會分享的主軸相同，只要英翻中就好，順便一魚多吃！
根據我在新加坡年會的經驗，原本預計講個40分鐘，但30分鐘就說完了，幸好因為談的是大家都會有的痛點和共同經歷，所以發問很熱烈，十多個提問把時間完美的佔到45分準時結束，大家都以為我是故意留很多時間提問的XD。比預期時間快的原因是上臺後的緊張語速加快，而且每次準備的故事都會東漏西漏，時間一定會快一些。而台中的分享時間是一個小時，讓我有點傷腦筋，要如何補足剩下的20分鐘又可以彌補我口條不好的缺點呢。 閱讀全文〈Agile Tour Taichung 2017『空手、緊握、到放手 – 敏捷路上學到的5件事』台中敏捷旅程分享心得〉
很榮幸被 Agile Tour Taipei 主辦單位邀請分享我們組織嘗試引導的經驗。雖然從三年前就開始土法煉鋼自己做引導，一年前也開始受 ICA 正規的引導訓練，並很幸運有機會在敏捷社群和引導的對談參與其中，照理說應該蠻多東西可以分享的。
但我真的不知道要分享什麼，因為引導是個非常廣大也非常形而上的主題，從會議的引導、日常生活習慣的引導、到引導式領導，每個主題都可以講個三天三夜。而且我希望參與者不是只是來聽聽，覺得引導好棒棒，而是可以有東西讓可以回去馬上實做應用。琢磨了好一陣子後，決定與其我來說引導如何好、如何有效，不如讓大家實際體驗一下被引導的感覺。 閱讀全文〈『ScrumMaster的吃飯傢伙 – 引導出個夢幻團隊』- Agile Tour Taipei 2016 分享心得〉
開始跑敏捷後會開始遇到一些跟傳統科層式組織格格不入的地方。科層式的組織架構的優點是中央決策，可以最大化命令與控制的力道。但在敏捷中強調的是讓第一線人員做出決策，傳統的組織就變成一個綁手綁腳的設計，所以如何讓組織架構成為產品開發的助力就是一個大問題。
當初第一個找到的其他組織模式是弄合制 （Holacracy），也買了專門討論 Holacracy 的書 – 無主管公司 – 研究一下。看完後的第一印象不好，主要有兩個原因，第一個原因是作者一直強調要用就要整套用，All or Nothing。換句話說是要組織整體打掉重練，跟我看情況挑戰、摸著石頭過河、小步快跑的哲學不和。
第二個原因是太太太複雜了也太太太嚴謹了，從營運、角色定義、每個人職權、到會議如何開都有規範，還一定要規範出來，跟敏捷大家不分彼此一起把事情搞定的原則違背（有興趣的朋友可以參考弄合制憲法），我最討厭規則連看都懶的看 XD。
總之就是喜歡他的初衷但設計不對胃口，就擱下來了。直到參加新加坡的敏捷年會，聽到 Jutta Eckstein 主講的 Sociocracy – A means for true agile organizations。聽到興趣就來了，因為 Sociocracy （沒有正式中文翻譯，Wiki 上翻成全民政治，我偏好稱為全員參與制，簡稱全參制。）強調的是大原則，沒有制式的方法跑，給很大的彈性，可以進階的嘗試導入。 閱讀全文〈適合敏捷式組織的架構：全員參與制（Sociocracy）、認可決、雙連結〉
最近台灣 Scrum Community 的 FB 社團非常熱鬧，有很多深度的討論，應該是天氣太冷了大家呆在家裡沒事做 XD。
這個討論串談到一個Sprint應該排 80%，100% 還是 120% 的工作量？，被 John 點名了一定要扯淡一下的啦。 以下是我的回應：
今年有幸參加 Gerald Weinberg 和 Esther Derby 的 Problem Solving Leadership （PSL）工作坊，到現在還沒寫心得，因為太多點了不知如何寫起 XD
就說說其中一件與『成年人』有關的事件好了，在第二天的其中團隊活動結束後的 Retro，有一個夥伴出來分享，他說他很自責，因為他知道正確答案，但沒能說服團隊依照他的方案走，所以後來團隊失敗了。 閱讀全文〈Scrum 中一個 Sprint 要排多少工作量？ – 談談『成年人』〉
在開始時跑 Scrum 時就自己腦補，所謂引導就是『引誘+誤導』團隊乖乖按照自己的既定方向走 XD。所以去讀了些心理暗示與影響力的書，在會議前先設想期待的結果，設下陷阱讓團隊講出自己的答案。
大多數時候過程都可以按照自己的劇本發生，而當自己預期的答案沒有出來時，就用誘導式問題（Leading Questions）讓團隊就範，讓自己的答案從團隊成員的嘴巴中說出來。如果爭議太大的議題，就先埋好暗樁，適時的跳出來帶一下風向。
(English version published on T.8ytes 英文版發表於 T.8ytes)
在我2014年剛剛開始接觸 Scrum 的時候，覺得 ScrumMaster 是個神一般的存在，不但要幫助團隊了解 Scrum 架構與敏捷精神、支持團隊提升技術能力 、教導團隊如何自組織、移除團隊成長的障礙、協助 Product Owner 產出價值最大的化的 Product Backlog、解決組織中影響團隊運行的阻礙，更扯的是他跟團隊是平行單位，完全沒有叫人做事的權力，乾脆找超人還比較容易 XD。
以上職責要一個人全部做到非常挑戰，但一個個分開個別來看，至少都還看得懂要做些什麼。但其中最令我困惑的是提到 ScrumMaster 要引導團隊的部分，而且還特別強調這部分的重要性，但引導（Facilitate）到底是什麼意思呢？ 閱讀全文〈敏捷X引導 – 讓Scrum團隊自組織的具體方法〉
有一則叫【看蜜蜂】的笑話是這樣嘲笑管理的：
話說很久很久以前，有個養蜂人養了一群蜜蜂，每幾天就採些蜂蜜來賣，日子過的也還算輕鬆愜意。
有一天，不幸有個管理顧問經過，他看了看蜜蜂飛來飛去，轉頭就問養蜂人：
『你怎麼知道蜜蜂都有在努力工作，沒有偷懶呢？』
養蜂人傻住了，回答：
「我沒有想過這個問題，」養蜂人有點心虛
「那要怎麼知道蜜蜂有努力工作呢？」
『這還不簡單，』管理顧問自信滿滿得說到
『你就請一個人來看蜜蜂，由他來管理蜜蜂，蜜蜂就不敢偷懶了。我們在企業都是這麼做的，非常有效，有個專門的職稱叫 Team Lead 組長。』
「說得有道理，」養蜂人低頭沉思了一會
「那如果看蜜蜂的人偷懶，我要怎麼辦？」
『沒想到你還蠻有管理的 Sense 的嘛！』管理顧問用充滿激賞的眼神看著養蜂人
『你就再請一個人，看著“看蜜蜂的人”有沒有專心看蜜蜂啊。這工作也有個專有名詞，叫做經理，英文叫做 Manager。』
「這樣就夠了嗎？」養蜂人露出恍然大悟的表情 閱讀全文〈敏捷界的禁語 – 敏捷組織中需要管理者嗎？〉
很多新創團隊都是使用敏捷開發如Scrum，最大的原因是使用MVP技巧，快速迭代，盡快取得回饋。
而一個成熟的組織使用Scrum或敏捷，除了快速取得市場回饋，有什麼誘因或好處呢？當過主管的朋友，應該都知道最痛苦的時刻，是不該走（？）的人提辭呈的那一刻，特別是專案成敗就靠他時（煙~）。
而跑Agile，就主管來說最大的好處是提高組織的可持續性，把原本集中在重要成員身上的工作量，視覺化或顯現出來，讓大家可以分擔，從而增加團隊的公車指數。而團隊的可持續性，最好的指標就是公車指數（Bus Factor）。 閱讀全文〈少一個差很多 – 算算團隊的公車指數〉
今天在玩Taco桑的Scrum Lego Game中，需要預估所有需求（Story）的大小，利用T-Shirt Size方法歸類到XL，L，M，S。而有一個Story是要蓋市長紀念碑，團隊先放到到S，但最後花了一整個Sprint，比其他XL花的時間還多。（都怪某一組拉高了市長的期待，還放跑馬燈，讓我們壓力很大 T_T）
其他Story預估大小也和真正實作的時間差很多。
所以在Retrospective（自省）中有夥伴說：『因為我們沒有玩積木的經驗，所以估計不準。』
我很好奇的問：「大家在現實工作中，都估計的很準嗎？」
有夥伴回：『如果估不準，怎麼報價給客戶？』
閱讀全文〈閉嘴也不錯 – 如何用靜音排序(Mute Mapping)快速估算需求〉
這天夥伴問了很有趣的問題：『Scrum 團隊裡面每個人做的事都一樣，那不是很無趣嗎？』
這要都感謝政府從小不余遺力的洗腦，讓我們當聽到團隊兩個字時，腦海最先跳出來的是一群排列井然有序、穿著筆挺制服、面無表情、動作劃一的隊伍。
從小到大，我們接受的是表面上推崇團隊合作，實際上摧殘團隊精神的儀式一再洗禮。穿制服、各種典禮、秩序比賽、整潔比賽，都只是追求表像上的一致。
這些從小學、中學、大學、到當兵所有行禮如儀的團隊大拜拜，充其量只是一團團人體聚合物的展示，跟真正的團隊一點關係都沒有。
所謂的團隊合作，就是每個人的動作都一模一樣踢著正步，只要表現任何跟大家不一致，就是不合群的團隊破壞分子。
有人說穿規定的制服和集合唱國歌，才能打造出團隊的向心力和文化？醒醒吧，要是團隊的文化和向心力那麼容易打造出來就早就統一全世界了好了。
一直以來我們都很強調自己是技術導向導向（Technology Centric）的團隊，直到有一天敏捷發現了我們，我們才開始往使用者導向（User Centric）慢慢移動。
我自我感覺良好的認為，自己思維還算是夠使用者導向，直到最近才發現果然是自我感覺良好。
話說最近新開發了一個產品，上線後發現網頁開很慢。一個沒啥圖片的登入頁面，User first visit大約要5-10秒才能Load完。
