曾經待過一個新創團隊，因為產品才剛起步，所以團隊採取了敏捷模式。
一天上午的例行會議 (Stand-up meeting)，一位資深同事氣沖沖的，說要告訴大家什麼才是正確的開發模式，似乎累積了長期的怒氣。
他不斷地強調，需求一直改變是不行的，大家沒辦法做事，需求必須要被固定下來。
但是啊，不就是因為，需求一直改變，團隊才採用敏捷的方式開發嗎？
敏捷不難，難在心態
敏捷這個概念本身並不難理解，但是能不能接受又是另外一回事。
前面那位資深同事，過去長期在進行瀑布流開發的團隊工作，因此需求通常會先經過完整地確認，然後進行詳細的規劃後，再投入開發，一投入開發至少就是一兩個月的事情，最後才再進入測試、驗收。
但是走敏捷的時候，這樣的過程被縮短成兩三個禮拜就要重來一次，一個新需求進來，馬上就要進入開發，然後測試、驗收、展示。
當然，每個週期變短了，需求的內容當然也變少了，如果只是把半年的工作量，硬要你在一個月內完成，這並不叫敏捷，這叫壓榨。
但是確實沒錯，開發週期變短了，開發步調更緊湊，自然給人的壓力也變大了。
而對於那位資深同事來說，他不習慣這麼快步調的工作模式，他認為這樣的工作模式沒有辦法好好做事。
我同意也理解，但其實，也就代表這樣的人，心態並沒有準備好要待在一個敏捷團隊。
找到對的團隊成員
所以，當一個團隊決定採用敏捷後，除了要學習敏捷的方法論，其中還有一項重要任務是，找到適合的人加入團隊。
有些人不是能力不足，而是不適合這樣的工作性質。而這就是為什麼，很多傳統團隊，要轉型成敏捷開發，會遇到困難。
敏捷導入通常發生在公司面臨新挑戰，需要有別的嘗試，來反轉頹勢的時候。但公司內部的員工，多半歷經了過去長期的穩定期，是一群習慣穩定步調工作的人，要讓他們改用敏捷，肯定是萬分困難，且挑戰重重的。
如果這些人沒辦法改變心態，很可惜，即便他們充滿了經驗，他們可能也不會是敏捷團隊的人。
一個接受敏捷的人，應該是什麼樣子的？
一般來說，目標應該是明確的。但是敏捷的目標是會一直跑的，這個月的目標跟下個月的目標，是不一樣的。
一個人可以接受敏捷，他必須要能夠接受模糊狀態，接受目標總是不確定，總是在改變的模糊狀態。如果不能接受這些事情，那可能就不是那麼適合。
另外，敏捷團隊的溝通需求很大量，如果討厭溝通的人，也許也不適合。
以下舉幾個例子。
–
「這個需求還不確定，但我們必須要先討論出一個版本。」
適合敏捷的人：「我們可以一起來看看怎麼做比較好。」
不適合敏捷的人：「可以等需求確定再來討論嗎？需求不確定的狀況我們沒辦法討論。」
–
「公司營運方向改變了，這個功能我們要改掉。」
適合敏捷的人：「噢，所以打算要怎麼改？之前有哪邊不好嗎？」
不適合敏捷的人：「為什麼又要改？這樣大家的工時不都白費了嗎？」
–
「我們來約時間討論一下早上遇到的問題」
適合敏捷的人：「OK，什麼時候比較方便？需要找另一位同事嗎？」
不適合敏捷的人：「這個問題有需要找我討論嗎？主管決定不就可以了？」
–
這幾個例子中，雙方的說法並沒有對錯的問題，只有適不適合的問題。
結論
很多時候大家都只是一窩蜂的想要使用敏捷，可能是接收太多過分放大敏捷能力的錯誤資訊，而忽略了敏捷本身要解決的商業問題。
而採用敏捷最容易遇到的雷之一就是團隊成員的適性問題。只是導入敏捷的工作模式，像是 Scrum，而忽略的團隊成員的組成，很容易立刻就遭到團隊成員的反撲，結果失敗收場。
所以有些成功的案例，他們會另外在公司內部組成敏捷團隊，從公司中找出擁有敏捷心態的人，真的沒有就從外面找，由這樣的敏捷團隊來帶領公司做敏捷轉型，也是一種可行的做法。
如果真的沒辦法找到適合的團隊成員，也許先不要嘗試敏捷？或至少不要想著一步到位。