正如前言所形容，敏捷在近年來似乎被奉為救命神丹，似乎只要咬碎服下，各種關於團隊、組織的疑難雜症都可以迎刃而解。但是事情並沒有這麼簡單。這顆救命神丹，未必是一口服得下的。

就算在事前研讀過有關想導入的敏捷流程或是框架，想要一口氣導入都可能會噎到，因而窒息而倒。雖然經驗不多，但偶爾會聽過他人導入敏捷（通常是 Scrum），最後都淪為形式，或是根本無法執行的失敗情況，再繼續詢問下去，通常會發現很多都像是發現新大陸一樣興奮，於是興沖沖的要一口氣導入整個框架或流程，最後終於變動太大，頭尾難以兼顧，最後不了了之。

敏捷其中的一個價值觀就是「回應變化」[^1]，意思在於快速響應變化並且持續發展。再白話一點，就是指要不斷聆聽回饋，然後根據回饋進行改變去適應、再持續聆聽回饋，繼續改變去適應、再聆聽⋯⋯。

套用在軟體開發就是指要持續和客戶溝通，確認需求，若是實作出來的成品不符合需求，就即時同步資訊，讓認知保持一致，並持續這個過程。而為了要能不斷接受回饋，所以軟體不會一氣呵成做完，而是定期或是一做完一小部分就找客戶展示、溝通、確認、紀錄，並回饋到下次開發的過程。

既然可以理解在軟體開發中套用敏捷，那導入敏捷的過程套用敏捷其實也是同樣的道理。若是一口氣導入所有流程，就像是軟體開發中的瀑布流一樣，看似計畫完美，但遇到幾個地方有問題就很容易崩盤，或是失去信心。既然都要導入敏捷了，那導入敏捷的過程也要敏捷。

可以先將想導入的流程進行拆分，判斷先導入哪部分對團隊來說價值最高，分析各個導入的難易度與成本，最後決定導入的排序。並隨著逐步導入的過程所收到的回饋逐漸修正這個排序，若是團隊還在消化新導入的政策，那下次想導入的部分可以挑選比較簡單、比較好推廣的，讓團隊在潛移默化下漸漸導入所有流程。最重要的是，透過這種方式也能讓團隊習慣改變。

透過讓團隊習慣改變，也是敏捷一個很重要的元素。在團隊經營上，能讓團隊願意精益求精，不會被現有的流程僵化，會觀察在完成目標時遇到的阻礙，主動提出並且制定政策去改變。在軟體開發上，大家不安於現有的程式碼品質、不執著於既有的架構，願意嘗試重構去讓程式碼更好。在自我成長上，願意擁抱新事物，不斷學習更好的知識。習慣改變是一種值得保持的心態，是一股不斷注入的活水，讓團隊保持生命力。

稍微離題了，關於上段有機會可以再細談，話題回到敏捷地導入敏捷。

除透過上述的方式進行拆分，逐個導入外，另一個重點是讓團隊自發性的去導入，而不是單純由所謂的主管、敏捷教練或 ScrumMaster 強制導入，畢竟強制導入的東西還是只屬於自己，不會變成團隊的。

在這部分，我會在導入政策前，先透過幾次主題分享，讓他們先暸解我預期想導入的元素，並在分享時強調「主題分享不代表要馬上導入這個元素」，而是先讓團隊暸解，並在沒有壓力的情況下進行交流，藉由分享激發他們的思考、想像，然後展開討論激發出更多想法，並記得在討論過程中接收回饋，暸解團隊對於這個元素的看法、疑慮等等，嘗試在討論中或是之後消除他們的顧慮，取得彼此的共識，最後才在團隊都認同下導入。

那有什麼辦法知道團隊都認同了，並願意導入呢？嘛，先別說這個了，你聽過回顧會議（Retrospective）嗎？

1: 敏捷軟體開發宣言