不懂敏捷的團隊，也可以用敏捷做專案嗎？
答案是：可以的，只要有一位有敏捷實務經驗的Scrum Master。
過去幾次導入敏捷的經驗發現台灣不論是軟體公司還是公司的資訊部門，敏捷的推導屬於「能做不能說」的範疇，也就是說就推不動，可是只要身體力行做下去，就一定會感受到敏捷的好處，不但會改變對敏捷的看法，甚至擁抱敏捷。
圖片來源：depositphotos
加上我初到這間公司時，挖角我的同事幾次苦口婆心跟我說，千萬不要在公司提到敏捷，也不要說你要導敏捷，公司不適合敏捷。
因此，我決定採行「守、破、離」漸進式學習的第一階段「守」，直接把敏捷精神與手法應用到當下嚴重delay的那個專案，由我直接帶著整個團隊實際做一次敏捷專案，當然前提是沒有大張旗鼓的宣告此事。要讓大家在不知情的情況下，用敏捷的手法做專案，著實讓我花了一些心力包裝敏捷：
1、Sprint以及Sprint Goal的變身
從接手這個專案到早就定下且動彈不得的上線日期，只有7個月而專案進度是0，專案風險高到嚇人，在沒有時間溝通敏捷的名詞與作法的情況下，我直接切成四個專案階段(phase)，以及訂下每個階段要完成的功能，藉此把固定期間的Sprint以及Sprint Goal變身成大家熟悉的專案階段(Phase)與里程碑(milestone)，降低大家對新作法的抵觸與適應期。
2、以實際可交付功能橫切分割法取代縱切分階段假交付
這是一個度為0又只剩7個月就要上線的高風險專案，第一個MVP很重要的是，這是專案的保本，就算後面的迭代增量進展不如預期，至少都有第一個可用可評估上線的業務流程所需功能，而不是一堆還在產線上的半成品。
因此我直接以業務流程橫切出第一個MVP，以及後續三個交付階段的迭代增量功能，一樣是大家熟悉的專案分階段，但不同的是，傳統專案的分階段不外乎兩種：一種是瀑布式，前期只有文件需要等到最後才有可用軟體；另一種則因為大家習慣以縱切功能模組的方式切階段範疇，加上系統要先資料才能做業務功能，先能登入才能執行業務的觀念，沒有等到最後階段，前期的產出幾乎無法組合出任何一個可上線運作的業務流程。
3、資源部分投入的全部投入
敏捷雖說要求聚焦(Focus)，成功的關鍵之一就是一個團隊只負責一項產品開發，但現實上是完全不可能的，而這點也是許多組織、團隊對敏捷既期待又怕受傷害，繼而將之拒於門外的關鍵原因。
這個專案初期，在我完成上面第1 、2兩個工作之後，還是遲遲無法開工，因為「沒時間投入」，於是我把整個團隊召集起來開發，逐一問每個人「下周你有多少時間可以投入這個專案？」，然後比對每項工作的預估工時，排定好接下來兩周的工作安排，以及第一次實際demo，也就是Sprint review的時間。
這種作法我稱之為「資源部分投入的全部投入」，也就是讓團隊成員估算與承諾接下來可投入的工時佔比，敏捷專案框定這項資源的部分工時，而團隊成員則是努力達到被框下來的這部分工時，需全時投入該專案。這樣的作法，讓我成功地在兩間公司解套導入敏捷手法所面臨如何兼顧敏捷要求的聚焦，以及實務上不可能一次只做一件事的衝突困境。
不懂敏捷的團隊，也可以用敏捷做專案嗎？
答案是：可以的，只要有一位有敏捷實務經驗的Scrum Master。
沒有一位有敏捷實務經驗的Scrum Master，也可以用敏捷做專案嗎？
答案是：可以的，先從上面三件事做起，就可以啟動用敏捷做專案的成功前三步，以及第一個衝索刺期(Sprint)
題外話，我剛考過Scrum.org的PSMⅠ，80題有過半都是各種情境題，例如「你剛到公司一個月，公司有五個產品要開發，這五個產品都要採行敏捷手法，你被指派擔任這五個團隊的Scrum Master，請問你首要任務是下面哪幾項？」這是考試最難的一種題型了，複選但不知答案有幾個，你得把所有正確答案都選出來，少一個都不行。
當然因為這是第一級的考試，所以題目很實務與情境，但答案很簡單，候選答案都是Scrum的名詞或從Scrum Guide的內容延伸出來的作法。
這樣的考試題目很實務，能讓應試者去思考不同的情境，選擇可能可行的方向或手法，但知道可行的方向後，要能訂出實際可行的操作手法，還是有一大段距離，這就真的考驗Scrum Master的敏捷心態、敏捷精神跟應變能力了。
