值得一提的是在準備本書出版的時候，有兩件事情琢磨了許久。
一個是書的目錄結構，為了讓華文世界的讀者更容易帶入，從原本音樂的比喻改成武俠的比喻。另一個就是書名了。
語不驚人死不休的書名
我自己也是喜歡酸中文書名跟原文差很多的眾多酸民之一，如之前談弄合制的無主管公司，明明弄合制的設計中還是有主管角色的。所以在設定書名的時候特別傷腦筋怕被酸。 閱讀全文〈原來你才是絆腳石 – 書名花絮〉
作者: Yves Lin
Trying being agile in the fun way.
喜歡并相信敏捷，期許能帶入一些不同的思維，能讓華語圈不只軟體產業，都可以更敏捷。
跨職能團隊是否真的有效？- 『原來你才是絆腳石』書摘
在傳統組織中跨功能的團隊通常在危機時才會出現，他們會組建了一個瞭解危機的特別工作小組，並由小組成員全權負責解決該問題。
在敏捷開發或 Scrum 中，我們常常強調團隊是要跨功能的成員組成。在傳統的企業，會按照功能來分部門或團隊，團隊成員的技能相對單一，像是QA部門與開發部門獨立分開。
而在敏捷式的組織，強調的是希望一個團隊可以自行從頭到尾交付給顧客價值（提供產品或服務），減少跨團隊溝通造成的延遲或資訊落差，所以成員的組成需要跨職能。
有一個蠻好的具象化比喻是不丹的傳說故事，和諧四友：大象、猴子、兔子和小鳥組成的團隊。
雖然大象又巨大又強壯，還是需要敏捷的猴子才能摘下果實。但如果當初小鳥沒有吃下種子，讓種子跟著排泄到土壤中，就不會有樹的出現。而如果沒有兔子在土中挖洞，讓土壤通氣與保留水分，樹也不會長的又高又好。
以下是在『原來你才是絆腳石：企業敏捷轉型失敗都是因為領導者，你做對了嗎？』一書中，可以用來探索『跨功能團隊是否真的有效』的一個實驗。
探索12：跨功能團隊是否真的有效？
背景：在傳統組織中跨功能的團隊通常在危機時才會出現，他們會組建了一個瞭解危機的特別工作小組，並由小組成員全權負責解決該問題。 閱讀全文〈跨職能團隊是否真的有效？- 『原來你才是絆腳石』書摘〉
團隊自省是否能提高顧客滿意度？- 『原來你才是絆腳石』書摘
在某些情況下，工作可能是以「個案」為主（例如零售商店，醫生診所或諮詢櫃檯）而不是專注於專案，因此沒有明確的開始與結束時間，也就沒有工作節奏。因此，定期反思和學習就有些強人所難，且太過死板，員工很容易會有「我們在浪費時間」或「在你們這些蛋頭顧問後，我們決不會做這些蠢事」之類的想法。
在敏捷開發或 Scrum 中強調的是持續改善，而持續改善的發生主要是靠團隊的反思或自省。
這一篇哈佛商業評論『再討厭，也要安排自省時間』也提到自省的重要性。Scrum 中甚至規定團隊在每個短衝結束時，要舉辦自省會議（Retrospective）以找出在下個短衝可以改善的工作流程。
但自省會議所花的時間真的值得嗎？要如何衡量它所帶來的效應呢？
以下是在『原來你才是絆腳石：企業敏捷轉型失敗都是因為領導者，你做對了嗎？』一書中，可以用來探索『團隊自省是否能提高顧客滿意度』的一個實驗。
探索22：團隊在規律的節奏中學習和反思，是否能提高顧客滿意度？
背景：在使用敏捷開發的軟體部門，定期舉辦自省會議是很常見的做法。在自省會議中，團隊成員會討論在過去兩三周內，他們從已交付軟體所獲得的成果學到了什麼。他們也從彼此間、與公司其他部門、或與顧客的互動中學習。根據筆者自己的觀察，從事其他工作的部門很少採取這種做法。
在某些情況下，工作可能是以「個案」為主（例如零售商店，醫生診所或諮詢櫃檯）而不是專注於專案，因此沒有明確的開始與結束時間，也就沒有工作節奏。因此，定期反思和學習就有些強人所難，且太過死板，員工很容易會有「我們在浪費時間」或「在你們這些蛋頭顧問後，我們決不會做這些蠢事」之類的想法。 閱讀全文〈團隊自省是否能提高顧客滿意度？- 『原來你才是絆腳石』書摘〉
信任是否可以幫助降低企業成本？- 『原來你才是絆腳石』書摘
差旅費用的申報耗人心神，也傳送出矛盾和另人不舒服的訊息：「雖然我們相信你可以做出許多重要的決定，但我們也認為你可能會欺騙我們。」收到這種訊息令人灰心，而且這樣的流程比起可能節省的成本，花費了更多的金錢和時間來防弊。
人性本善？還是人性本惡？
這個是永遠討論不完的問題，而這觀點也會影響企業中的政策和規定。
與其空口討論，不如直接來做個實驗吧！
以下是在『原來你才是絆腳石：企業敏捷轉型失敗都是因為領導者，你做對了嗎？』一書中，可以用來探索『是否可以利用信任來減少成本』的實驗。
探索2： 信任是否可以減少成本？
背景：另一個過度官僚例子是複雜的差旅費用管控，這個管控是假設員工會企圖欺瞞公司，所以就規定只能住哪類型的旅館，只能吃多少錢的食物等等。 閱讀全文〈信任是否可以幫助降低企業成本？- 『原來你才是絆腳石』書摘〉
原來你才是絆腳石 – 一本給變革領導者的企業敏捷轉型指南
在一年前審閱英文原版時我心中是非常激動的，邊看邊想：『如果能早幾年看到，就可以少走好多冤枉路』。要是本書能翻成中文版，對華文世界的企業一定大有幫助，因為敏捷只是心法，而本書就是補足理論和實踐之間差異的那片拼圖！
從 2014 年在公司內開始導入 Scrum 和敏捷Agile，然後接下來在組織面的種種演變，如建立跨功能的團隊裁撤QA部門、推動自省會議的發生、在團隊中不設組長、薪資公開化、推行團隊自組織、推動雙連結等等，我們的敏捷轉型可以說是摸著石頭過河。一方面是因為大部分的資料都是針對 Scrum 在開發團隊中的應用，偏向技術面或產品面，談企業組織面的資料很少。二來敏捷式組織也是相對新的概念，別說中文了，連英文的資訊都非常有限。
所以在一年前有幸被邀請審閱 Company-wide Agility with Beyond Budgeting, Open Space & Sociocracy: Survive & Thrive on Disruption 一書，在閱讀時我心中是非常激動的，邊看我就邊想：『如果能早幾年看到，就可以少走好多冤枉路』。要是本書能翻成中文版，對華文世界的企業一定大有幫助，因為敏捷只是心法，而本書就是補足理論和實踐之間差異的那片拼圖！
而我的心願終於實現了！！！
『原來你才是絆腳石』一書已經在天瓏網路書店、博客來、讀冊生活、新絲路和各大實體書店與大家見面！
團隊決定的跟我想的不一樣！- 談參與式決策的技巧
在敏捷組織中，參與式決策被大量的使用，因為現在的環境變動太快，有成員的買單和真心認同，在執行時決策的意圖才能被真正落實。參與式決策的重點，在於讓大家覺得自己的觀點和想法都有被聽到，所以流程的設計是一門學問。
最近看到一則議題是總統擔任主席時，不認同投票表決的結果要求重新表決。
先聲明非關政治，我也沒有研究此會議的流程所以沒辦法判斷對錯。但這是很好的案例，來探討一個所有主管都會遇到的問題：『團隊決定的和我想要的不一樣怎麼辦？』 閱讀全文〈團隊決定的跟我想的不一樣！- 談參與式決策的技巧〉
欸對準一點 – 談校準的重要性(不服從的領導學心得)
關於校準這個概念我是從 The Art of Action （不服從的領導學）一書中學來的，我認為這是影響我蠻大的一個管理概念，之中的許多想法也暗合敏捷精神，如響應變化 重於 遵循計畫 (Responding to change over following a plan)。
不管在工作中還是敏捷開發，都有強調做價值的事，『有效』重要過『效率』（Effectiveness over Efficiency）。剛剛好在臉書上看到什麼是『有價值的工作』的討論，我覺得價值本來就是主觀的東西，沒有對錯，所以校準（Alignment）會比價值本身是什麼更重要。組織的方向是節約成本、研發為主、創意開放、流程至上，具體的做法都會不一樣。如果每個部門往公司的方向對準，每個團隊往部門方面對準，每個成員往團隊方向對準，那整體就超強啦。
關於校準這個概念我是多年前從 The Art of Action （不服從的領導學）一書中學來的，我認為這是影響我蠻大的一個管理概念，書中的許多想法也暗合敏捷精神，如響應變化 重於 遵循計畫 (Responding to change over following a plan)。（順帶一提，我覺得很多中文書名都跟內容不符，也許可以增加看書皮購買的興趣，但買了發現跟想像不同不是讓讀者感受更糟嗎？還是其實因為買書有看內容的是少數？越想越可怕 XD）
阻力無所不在
在組織中其實很多政策都是為了校準，確保下級單位有把上級的目標放在心裡，比如說 KPI 就是用胡蘿蔔與棒子的思維來校準。但為什麼我們花了很多心力在校準，但結果往往跟我們想的不一樣呢？ 閱讀全文〈欸對準一點 – 談校準的重要性(不服從的領導學心得)〉
薩提爾探索自我工具 – 互動要素（Ingredients of an Interaction）
冰山模型比較偏向幫助對方從行為開始探索他的內心，而互動要素偏向反思自己再表達前的心路歷程。互動要素有點類似推論階梯（Ladder of Inference），但互動要素更深層的挖起這些反應機制形成的原因。
對於薩提爾模式，比較常聽說的是冰山模型（Iceberg Model）。而今年在新加坡上到 Jean McLendon 和 Hugh Gratz 所引導的薩提爾成長工作坊，反而對於冰山模型只是帶過，花比較多的時間在運用互動要素（Ingredients of an Interaction）。
我自己的看法是，冰山模型比較偏向幫助對方從行為開始探索他的內心，而互動要素偏向反思自己再表達前的心路歷程。互動要素有點類似推論階梯（Ladder of Inference），但互動要素更深層的挖起這些反應機制形成的原因。
先簡單介紹一下互動要素，在互動要素中一共有七個步奏
- 感知資料（Sensory Data）
- 聽到/看到/聞到/觸覺
- 意義（Meanings）
- 對你來說這些代表什麼意義
- 感受（Feelings）
- 你的感受是什麼
- 感受的感受（Feelings about Feelings）
- 對於這些感受你有什麼感受
- 防衛機制（Defenses）
- 之前如何處理這樣的情況
- 表達習慣（Rules about Commenting）
- 之前都是怎麼表達
- 反應（Response）
- 你現在打算怎麼反應
薩提爾成長工作坊參與心得（Satir Growth Workshop）
薩提爾理論的核心在於把日常生活中複雜的互動，簡化成三個面向：自我、他人、和情境（Self, Others, and Context）。然後依照對這三個面向的考量多寡，分成了五種應對的姿態。分別是討好、指責、超理智、打岔和一致。
「問題本身不是問題；如何應對才是問題。」
－維琴尼亞‧薩提爾“Problem is not the problem; coping is the problem.”
– Virginia Satir
第一次接觸到薩提爾的概念是 2014 年開始導入敏捷，Odd-e 的 Stanly 推薦了溫伯格的軟體管理學這一套書籍中，第三冊提到的關照全局的管理作為（Congruent Action）。原本我想的是軟體管理跟心理學有什麼關係，後來慢慢接觸多了，也去參加溫伯格的問題解決領導者工作坊（Problem Solving Leadership），才了解到溫伯格認為軟體開發就是靠團隊的溝通和互動，所以沒有關注人的組織，是做不出有品質的軟體的。
近年來台灣敏捷社群的學習主軸也從方法論（Scrum、Kanban）、引導技巧、走向心靈路線 XD（當然還有硬工夫 DevOps）。去年參加陳茂雄老師的薩提爾冰山模式課程後，對薩提爾的理論有更一步的認識，但一直沒有真實面對自己的足夠勇氣去上薩提爾的工作坊。
直到今年 Odd-e 邀請 Jean McLendon 和 Hugh Gratz 在新加坡引導薩提爾成長工作坊，因為機會難得不用飛美國，我就豁出去參加了。他們兩位在薩提爾的身旁學習了二十多年，直到薩提爾於 1988 年去世。也因為這次在新加坡難得的經驗，讓我有機會把過去三年從不同的書上、工作坊裏學到的各種薩提爾理論與技巧，統整在一起而有了整體性的了解。 閱讀全文〈薩提爾成長工作坊參與心得（Satir Growth Workshop）〉
小心定律就在你身邊 – 五個系統設計常用的定律
讀到每个程序员都该知道的五大定理（5 laws every developer should know），感覺這些可以應用在系統設計上的定律，應用在社會和人生上也没有違和感。
文中提到的五個定律分别是
- 墨菲定律 Murphy’s law
- 高德納定律 Knuth’s law
- 諾斯定律 North’s law
- 康威定律 Conway’s law
- 帕金森瑣事定律 Parkinson’s law of triviality
1. 【墨菲定律 Murphy’s law】
“只要有可能出錯，就一定會出錯。”
“Anything that can go wrong will go wrong.”
如果殺人祭天有用，就殺吧。但如果換另一個人還是有可能出錯，這時獵女巫是没有用的，系統性問題要用備源、防呆、容錯、再確認等等機制處理。