敏捷教練的進退之道

　　最近，敏捷教練Morgan Ahlström在郵件列表“敏捷教練支持(Agile Coach Support)”上求助：有的客戶聲稱想要更多地從敏捷中獲益，但實際行為卻與該目標背道而馳，如何面對這種窘況?

　　下面是他所描述的情況：

　　你是否受雇擔任敏捷教練，結果做的事情名不副實?你是否偏離了任務方向?你是否在兢兢業業幫人實現敏捷，只因為自己拿了這份錢，即使對方根本不想改變?你是否得一面搞改革，一面服從潛規則?你是否要借助于其他什么頭銜來推動大家走出泥潭?實際工作中你還有其他什么可行的方法?

　　D. André Dhondt的想法：

　　在我看來，改進和敏捷是兩碼事。我會專注于對方想要改善的地方，或者對方感覺難受的地方，把“敏捷”放在一邊。我仍然要做溝通、互動，以人為本，但不會拘泥于敏捷這個術語。

　　Peter Green跟帖說：

　　每次有機會做教練，我們都指望能改變世界。經常落入的誤區是：如果客戶沒把敏捷貫徹到底，就是我們的失職。不管怎么說，事情還得一步一步來，采取持續改善(Kaizen)的方式——不積跬步，無以至千里;不積小流，無以成江海。

　　團隊和組織的改革，包括很多細致入微的工作，我們可以帶動大家一起向著敏捷前進。其過程的漫長會令人沮喪，但緩慢的改變仍然是改變。

　　Tim Ottinger從歷史眼光看待問題，同時提出警告：

　　我正在醞釀的一個口號：“形象工程”是“不斷實現”的大敵。

　　按照一套框框來做事，并非早期XP和Scrum的要求，也不是達成它們的手段。它們改變了團隊合作中一些深遠的東西，它們來自對真正高質量軟件開發的嘗試。因為它們看起來真的很牛。XP是為了實現更多、更好、更快、更安全、更干凈的一套深層次變革，而被大家所采用。我們正在懸崖邊上，“敏捷”現在幾乎成了攔路虎，而不是快車道。大家為了守規則而守規則，而不是從團結中獲益。

　　稍后他又補充說：

　　我曾經面對的尷尬是，程序員和經理們就在那消磨時間，等著我什么時候走人，等著“敏捷”的風頭什么時候過去。太可怕了。

　　另一方面，如果你真觸動了少數幾個人，那也算沒白忙。如果能接近舊有套路的切入點，你就可能促成一些改變，并點亮星星之火。別搞混了，“挫折”與“失敗”不能同日而語。

　　Lior Friedman的選擇：

　　壓力一旦增加時，人們通常會重拾舊的習慣。名義上采取哪種流程，并不重要，我只要做到讓事情100%可見，確定讓每個人明白團隊正處在什么位置，以及接下來朝哪里走。任何一點能促成的進步，都會讓我喜悅。

　　我也會實事求是地評估自己，如果對我的ROI投資回報率是正值的話，就繼續在這個崗位上，基于現有條件，努力做到最好。

　　George Dinwiddie對務實精神有共鳴：

　　盡管我的工作大多是訓練團隊朝著“敏捷”過渡，最終目標卻不是“達成敏捷”，而是幫助人們更有效率地開發軟件和其他系統。

　　“幫助”是讓對方得到好處，提供他們想要的，不是我想要的。如果我在這沒有幫助，就是該離開的時候了。當然離開也會有其他原因。

　　Tim Ottinger充實了討論內容，鏈接內容是他和Jeff Langr寫的一篇文章，標題為“敏捷的誤區(What Agile is Not)”。

　　查看英文原文：When to Cease Being an Agile Coach?

原文轉自：http://www.kuqin.com/software-engineer/20110613/91900.html