Scrum是近年軟體開發方法最熱門的關鍵字，說得像是可以返老還童、起死回生的仙丹妙藥。但台灣真正導入的團隊又沒多少，聲稱導入的團隊又充滿著在地文化的台灣式手法。那麼，到底應不應該導入Scrum呢？
關於Scrum的模式和方法，在《Scrum Primer》這份文件（連結為簡體中文PDF版）已經解釋得很清楚；如果英文沒問題，還可以看看更原汁原味的英文版。所以本文就來純粹談談導入一段時間之後，最深刻的經驗和感想。
Scrum跟其他Agile方法最大的差異，在於把人（Team、Product Owner、Scrum Master），事（Sprint Planning、Sprint Retro等等），物（Product backlog）很明確的定義處理。其他敏捷方法如XP，是著墨在技術方法上；而Kanban則著重在流程上的處理。所以相對而言，Scrum可以馬上就照表操課，而且還可以跑得有模有樣。那麼，到底有什麼難度呢？
Scrum的缺點
Scrum難在它他並不是設計來「做出產品」的，而是將全部開發流程透明化、讓優點和缺點明顯暴露出來的「擴大器」。
怎麼說呢？比如說Team自己決定這Sprint要拿多少工作，通常Product Owner就會哀嚎「怎麼產出比之前降那麼多」，因為之前高產出是用PM的鞭子與愛心、主管的壓力關懷、以及工程師的偷工減料創意堆疊出來的。
所謂出來混遲早要還，之後就會反映在高離職率上、修不完的bug、或是完成99%的系統就是差1%而永遠無法結案。
那暴露出來的弱點怎麼辦？
就是改善啊！假設每次Sprint會有1%的改善，50次Sprint就增加64%；等於是在1-2年的時間中，5人Team的能力會擁有8人的戰力，聽起來很不錯吧？
你接下來一定會問，如果不改善呢？
第一個是要靠Scrum Master的功力，讓團隊認知到這些問題；第二，如果團隊認知了、而且有意願改善，就盡力協助。如果是一個團隊認知問題，但又沒意願改善，那怎麼辦呢？在現在超級競爭的環境中，還願意待在一個不求進步團隊中的義士，再過幾年變烈士的幾率是很高的。
Scrum的優點
講完缺點，當然也要談談Scrum的優點。同樣的，想要進步、自動自發的Team，在Scrum的框架下會得到尊重和授權；在一個正面循環之下，會不斷增加自己的能力和產品品質。
能在這種團隊和環境工作，成就感和滿意度都會遠超過由PM主導的傳統開發模式；至於個中滋味，就只能靠自己體會了。
因為Scrum是擴大器（或者說是照妖鏡），第一個導入的前提就是「心臟夠大顆」。察覺到團隊可以自我管理時，絕對會讓人雀躍不已；而在沒有外在壓力時，卻發現團隊產能直落谷底、或是不願意改善，用「傷心」也不足以形容這種失望。
所以，如果要導入Scrum，你心臟夠大顆嗎？
本文改編自作者於2021年7月出版的《敏捷管理生存指南：不是快，而是適者生存》一書。
發源於矽谷的敏捷式開發，在軟體產業如 Google、Facebook 臉書實證成功後，敏捷管理也開始影響各個不同的產業。
透過書中的實例和做法，無論老闆、主管或員工，科技業、服務業、傳產、學界或政府，都能運用敏捷讓自身工作更順心，團隊合作更順暢，企業成長更順利。
