收到 Max Lai 關於敏捷旅程台中的 Keynote 分享邀請時，我真的蠻高興的。第一因為出生於台中，對台中總是有一份特殊的情感。第二是分享的主題是組織轉型，剛剛好跟十月在新加坡敏捷年會分享的主軸相同，只要英翻中就好，順便一魚多吃！
根據我在新加坡年會的經驗，原本預計講個40分鐘，但30分鐘就說完了，幸好因為談的是大家都會有的痛點和共同經歷，所以發問很熱烈，十多個提問把時間完美的佔到45分準時結束，大家都以為我是故意留很多時間提問的XD。比預期時間快的原因是上臺後的緊張語速加快，而且每次準備的故事都會東漏西漏，時間一定會快一些。而台中的分享時間是一個小時，讓我有點傷腦筋，要如何補足剩下的20分鐘又可以彌補我口條不好的缺點呢。 閱讀全文〈Agile Tour Taichung 2017『空手、緊握、到放手 – 敏捷路上學到的5件事』台中敏捷旅程分享心得〉
當敏捷遇上引導的談話發生後，David, Abraham 和 Vicky 就進入了籌備模式，花了不少時間研究如何設計流程，才能讓參與的夥伴可以在表訂時間2.5個小時內得出共識。
當場 Vicky 的引導創造了讓大家安全說話的環境，我自己感覺到大家發言到欲罷不能，如沒有受限於時間因素，命名出來的群組名字有機會更直指核心。由於參加的夥伴來自個個不同組織，有開發團隊、ScrumMaster、Product Owner、主管等等角色，產出的結果應該蠻有代表性。
結論是推行敏捷會遇到以下的阻礙：
1. 現在好好的幹嘛改變
2. 團隊不知道如何建立信任
3. 對敏捷的導入沒有共識
4. （主管/ScrumMaster) 的引導技巧不夠
5. 團隊溝通不夠有效
6. 高層的信任和支持不夠
7. 傳統的績效管理不適用
8. 不知道如何用 Agile 處理（範圍時程）硬梆梆的專案
9. 工程和領域的技能不夠
10. （因資源有限）角色重疊混淆
11. （不知道如何）讓member 感受到結果的價值
12. 缺乏跨界交流的機會 閱讀全文〈找出組織無法變敏捷的阻礙 – 團隊共創法實做〉
在開始時跑 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團隊自組織的具體方法〉
敏捷宣言的原則中有提到『最佳的架構、需求與設計皆來自於能自我組織的團隊。』所以自我組織（Self-Organizing），或簡稱自組織，在敏捷開放中是個常被提到的關鍵字。
可惜 Scrum Guide上也沒有針對自組織定義，只好參考維基百科對自組織的解釋是：
自我組織，也稱自組織，是一系統內部組織化的過程，通常是一開放系統，在沒有外部來源引導或管理之下會自行增加其複雜性。 自組織是從最初的無序系統中各部分之間的局部相互作用，產生某種全局有序或協調的形式的一種過程。這種過程是自發產生的，它不由任何中介或系統內部或外部的子系統所主導或控制。
參考以上，在敏捷式管理中，我對自組織的解讀是：為了達到群體的目標（以服務或產品的形式提供顧客價值），由每個團隊內部或個人發動，所產生的協調和行動。
閱讀全文〈自我管理就是我說了算？ – 談自組織的不同階段〉
在傳統的專案開發中，都有一個角色負責分配工作，常常是由PM（專案經理）或是Team Lead（組長）來擔任。分配工作這回事非常吃力不討好，既要了解每件工作的急迫性和複雜度，還要考量每個人的能力，平衡每個人的工作量。
這角色常常會成為團隊的瓶頸，因為每件事情都要經過他來分析、排程、驗收、忙著開會，常發生團隊成員空等他來分派工作。更別提如果工作項目比既定時程提早做完、或延遲完成所需要的協調工作。這也是最容易被上下壓力夾殺，很快Burnout陣亡的苦主。
敏捷開發或Scrum如何解決這個角色的問題呢？ 閱讀全文〈工作沒人想做怎麼辦？ – Scrum中的工作分派與分工〉
有一則叫【看蜜蜂】的笑話是這樣嘲笑管理的：
話說很久很久以前，有個養蜂人養了一群蜜蜂，每幾天就採些蜂蜜來賣，日子過的也還算輕鬆愜意。
有一天，不幸有個管理顧問經過，他看了看蜜蜂飛來飛去，轉頭就問養蜂人：
『你怎麼知道蜜蜂都有在努力工作，沒有偷懶呢？』
養蜂人傻住了，回答：
「我沒有想過這個問題，」養蜂人有點心虛
「那要怎麼知道蜜蜂有努力工作呢？」
『這還不簡單，』管理顧問自信滿滿得說到
『你就請一個人來看蜜蜂，由他來管理蜜蜂，蜜蜂就不敢偷懶了。我們在企業都是這麼做的，非常有效，有個專門的職稱叫 Team Lead 組長。』
「說得有道理，」養蜂人低頭沉思了一會
「那如果看蜜蜂的人偷懶，我要怎麼辦？」
『沒想到你還蠻有管理的 Sense 的嘛！』管理顧問用充滿激賞的眼神看著養蜂人
『你就再請一個人，看著“看蜜蜂的人”有沒有專心看蜜蜂啊。這工作也有個專有名詞，叫做經理，英文叫做 Manager。』
「這樣就夠了嗎？」養蜂人露出恍然大悟的表情 閱讀全文〈敏捷界的禁語 – 敏捷組織中需要管理者嗎？〉
如果世世代代都住在一個被大洋環繞的小島上的村落，靠著採集和捕魚為生，村子中最先進的科技是獨木舟，當有天突然看到飛機飛過頭頂時，心裏的OS是什麼呢？
在二次世界大戰時，美日兩國為了爭奪太平洋的制海權和制空權，紛紛在汪汪大洋中、既偏遠又與世隔絕的島嶼駐軍。當軍隊開到時，島上的村民眼看著海上的超級大箱子（軍艦）靠岸，大鳥（飛機）從從頭頂飛嘯而過，還有神仙（士兵）從大箱子和大鳥走出來，下巴都掉到合不起來。
如果換成我的話一定覺得神仙降臨來處罰世人，世界末日要到了！幸好這群神仙不但沒有處罰世人，還賞了不少寶物給村民，如生病時吃了就痊癒的仙丹、會變出食物的盒子等等。當世界大戰打的如火如荼時，這是村民世代以來過的最好的日子，根本就是身在天堂啊。 閱讀全文〈今天拜飛機了沒？ – 談敏捷開發中的貨物崇拜〉
如果要票選技術團隊最可怕的噩夢，跟第三方廠商（Third Party）合作系統整合一定是前三名。
因為跟第三方合作，雙方沒有主從關係，對方不一定要聽你的，而自己還是要對業主負責。加上雙方都是技術人員，難免有文人相輕的脾氣，覺得對方的系統設計是白癡。如果又遇到要修改API，那更是僵持不下，吵翻桌子都要對方改。
這時候，如果聽到有人說：『因為我們跑Scrum，所以。。。』我都很想跳到他面前，掐住他的脖子說：『你以為全天下只有XXX你家跑Scrum啊！』 閱讀全文〈因為跑Scrum，所以辦不到 – 跑Scrum還是炮Scrum〉
很多新創團隊都是使用敏捷開發如Scrum，最大的原因是使用MVP技巧，快速迭代，盡快取得回饋。
而一個成熟的組織使用Scrum或敏捷，除了快速取得市場回饋，有什麼誘因或好處呢？當過主管的朋友，應該都知道最痛苦的時刻，是不該走（？）的人提辭呈的那一刻，特別是專案成敗就靠他時（煙~）。
而跑Agile，就主管來說最大的好處是提高組織的可持續性，把原本集中在重要成員身上的工作量，視覺化或顯現出來，讓大家可以分擔，從而增加團隊的公車指數。而團隊的可持續性，最好的指標就是公車指數（Bus Factor）。 閱讀全文〈少一個差很多 – 算算團隊的公車指數〉
在把妹的時候，成功進入穩定的戀情是最終的績效目標，而我們要靠一些跡象來判斷達成目標的機會有多大。如已讀不回的次數，說『恩恩、哈哈、去洗澡』的次數，被當工具人的次數等等，來幫我們做心理建設（告白被拒不哭哭）、改善行動方案（不修電腦改租超跑）、或改變績效目標（下個正妹會更好）。
回到組織來說，存活下去最重要的就是有財源。所以談到如何衡量團隊的績效，在一般的情境下，都是拿團隊能帶入的收益來判斷團隊的績效。例外的情況是燒錢搶市場，但長期還是要有獲利模式。
簡單的說就是結果論，一個可以賺錢的組織不一定是好的，但不賺錢的組織一定是壞的，一個沒辦法養活自己的組織，沒有存活下去的價值。
