團隊工作效率很低，客戶對產品不滿意，老闆對團隊工作挑三揀四，個別同事總在拖後進度，個人職業生涯發展有限.....工作中會有各種各樣的問題發生。

敏捷工作(Agile)方法，現在這麼流行，它到底能幫我解決哪些問題呢？

在我的教練生涯裡，無數次面對這種提問。 既然它被問的如此普遍，那麼就值得歸納分享一下了。

對這個問題，我的觀點主要有兩個：

-  敏捷不能解決任何問題， 解決問題的是人。

-  敏捷能解決什麼具體問題不重要，敏捷為什麼這樣設計很重要。

敏捷不能解決任何問題， 解決問題的是人

如果敏捷是一個工具，那麼必須是人去使用工具。工具能發揮多大作用，要依賴於人對工具的掌握程度，以及怎麼去靈活使用。 

人能不能解決問題，首先取決於解決問題的渴望，其次取決於方法。敏捷充其量算是方法中的一種。

渴望不同於願望。願望誰都有，畢竟面對工作中的難題和挑戰，誰不想去解決呢？誰不想變的更好呢？

但同時你可能常聽到一個說法，叫做『有些問題沒解決，是因為還沒逼到份上』。沒錯，想解決問題，只有願望，不一定會產生行動，而且有可能永遠都沒有行動，只是一個"美好的願望"。 『逼到份上』則是在問題本身之上，增加了緊迫性，必要性，和馬上就面臨的損失。這些因素將願望逼成了渴望，而渴望，會促使行動的馬上發生。

你看，解決問題，不是你想不想，而是你動沒動，你動不動，背後的原因是你到底有多渴望。

除了緊迫感之外，使命感，紀律性，強烈的興趣等都會促成對解決問題的渴望。渴望是第一位的，當你不渴望的時候， 方法能起作用極其有限。

《高效能人士的7個習慣》裡提到的『個人願景原則』，和『自我管理原則』，就分別指的是使命感和紀律性，二者都能形成渴望，推動人去迅速行動，也就比普通人更加高效能了。

前陣子有個團隊跟我抱怨，說客戶並不滿意，團隊嘗試過很多方法去解決，並沒有奏效，希望看看敏捷方法是否能幫助到他們。

我做了一番訪談後，發現一方面是團隊很忙，另一方面客戶卻抱怨團隊效率低。究其原因，是團隊在處理技術債，並且做一些非業務性的維護工作，佔用了新業務開發的時間。團隊一味強調忙，但沒能用客戶能聽懂的語言來說明並量化這部分工作。

我從敏捷的角度上推薦了一些工作方法，比如找合適的線上看板工具，讓客戶能容易的看懂當前團隊的工作，建立多個渠道跟客戶溝通，營造更好的透明度。任務分解到更小級別等等。

訪談結束後，團隊非常認可我提到的問題和建議。 但是一週以後，我再來訪問團隊的時候，他們什麼都沒做，並且列舉了一大堆困難，證明我推薦的方法雖好，但不適合他們，然後問我還有沒有其他方法。

我知道團隊在尋求敏捷幫助之前，也嘗試過一些方法，但是都類似的淺嘗輒止。並沒有對方法有深度的學習實踐投入。進一步調查後，我發先根本原因是因為客戶雖然對團隊有所抱怨，但是因為體制原因，沒有更好的選擇，所以團隊並不擔心客戶不滿意會導致自己失業。

這就是典型的"想解決"，但並不"渴望解決"的問題。

當人『渴望』解決一個問題的時候，會不吝投入時間，精力，資源。甚至會逼出些『急智』來。 當人只是『想』解決問題的時候，就會過度的計較投入。

敏捷是一套複雜的方法論，需要大量的學習投入，並且在正確的引導下，堅持半年到一年的實踐，才能夠達到某種程度的應用。在問"敏捷到底能幫我解決哪個問題"的時候，不如先問問自己"我是否足夠渴望解決問題，以至於願意付出如這樣大的努力"。

敏捷能解決什麼問題不重要，敏捷為什麼這樣設計很重要

清楚明白的答案，或許容易理解，不需要花太多時間研究，但於解決實際問題並沒有什麼卵用。因為凡是能解決一個非常具體的問題的方案，可重用性一定很差。即使是同一個問題再次發生，也可能會因為環境的變化，參與的人的變化，導致以前的方案不再適用。

Best Practice很多，但你要真統計一下複製成功率....

既然具體的解決方案重用性那麼差，為什麼我們還常說，"他山之石，可以攻玉"呢？如果簡單複製對方的做法，大概率是要失敗的。但是如果借鑑對方的做事思路，制定適合自己的方案，則大概率是要成功的。

與其呆板的將Scrum流程拿來重複，不如借鑑其思路 - 比如Scrum它設計了短迭代，MVP，user story，都是為了保證跟客戶溝通的頻率， 同時確保溝通的語言是客戶看的懂的語言。

你可能做不了Scrum，但你一定能找到合適自己的方式，讓客戶跟團隊頻繁的出現在同一個場域裡， 見面多了溝通就會發生。你也會有你自己的方法，將團隊的工作轉化為客戶能輕易看懂的語言。

簡單的重複的使用工具，或許在一開始能幫你解決某些問題。 但是在問題解決後，繼續單純的重複就會變成負擔。

每日站會(Daily Standup)是為了創造一個場域，它的目的是增進溝通，暴露問題，互相支援，同時時間盒以及不討論細節的約定，又在訓練你關注會議效率。 

假如團隊成員之間，已經工作透明的，互相頻繁溝通，互相支援，那麼每日站會就變成了額外的負擔。

理解了工具的設計原因和解題思路，才能靈活運用，不斷的解決問題。

但是你如果理解每日站會設計的思路，比如為何使用時間盒，為何不討論細節，你就可以知道如何去提高所有會議的效率。

在敏捷成熟度很高的團隊，如果突然來了一個不常見的，有挑戰的工作。或者新成員加入團隊，那就可以啟動每日站會，幫助新員工儘快融入。 但當團隊重新渡過挑戰期，每日站會又可以重新放回工具箱。

一個開瓶器，只能用來開瓶子。 但是如果理解了背後的槓桿原理，雖不見得能翹起地球，但是至少能貸款買房，融資炒股，打架的時候四兩撥千斤不是麼。

所以你是要獲得一個偶爾能用的上的開瓶器， 還是想變成一個能夠靈活運用槓桿原理的人？