敏捷是用來交付複雜產品的一種簡單但有效的框架。它不是通用性的解決方案，也不是什麼高招，更不是複雜的方法論。相反，敏捷為團隊可以自組織地用經驗解決複雜問題提供了最小邊界。這種簡單性是它最大的優點，但也造成圍繞“敏捷”一詞的許多誤解和謬論。在這個帖子系列中，我們——你們的“流言終結者”Christiaan Verwijs和Barry Overeem——將闡述最常見的流言和誤解。

 

 

以一個案例開始

 

 “所以Tim決定不再加入了嗎？”一個沮喪的很明顯的開發人員在參加每日站會時問到。那些在場的人聳著肩長吁短嘆。“即使談過需求之後，我們也要公開分享進展嗎？””另一個開發人員補充問道，緊張顯而易見。Tim至今快2個月沒有參加每日站會，將時間花在了“非常重要的事情”上。Tim更喜歡用站會時間來寫程式碼。但是，除了他在迭代結束時所做的眾多承諾——通常會被別人撤銷——沒有人真正知道他實際上在做什麼。開發團隊在迭代回顧時數次提出這個問題，沒能解決。團隊的敏捷教練Tess已經在多個場合和Tim談到這個問題，試圖找到Tim的祕密。儘管聊的很好，也沒能改變任何。團隊漸漸厭倦了這種對抗。士氣下降，而且因為Tim所做工作的以及給迭代帶來何種影響的不確定性，團隊越來越猶豫是否要實現迭代目標。在嘗試很多不同方法針對這種情景卻沒能成功後，Tess決定把Tim從敏捷組挪走。

 

 

 

這個案例展示了在敏捷小組自組織的本質和使敏捷為團隊和更廣泛的組織工作之間的平衡。我們描述的案例僅僅是艱難決策的一個代表。

 

當被問起敏捷教練是否可以從團隊移走任何人時，大多數人會響亮的回答“不”。它形成了團隊裡的等級，會傷害信任的氛圍和開發團隊的自組織本性。本文會基於上述案例，探討敏捷教練要成為“服務型領導”意味著什麼。

 

 

 

Scrum指南怎麼說？

 

Scrum指南並沒有明確指出敏捷教練可以從團隊中刪除某人。但是它確實強調了幾個相關的職責：

• 敏捷教練負責如Scrum指南中定義般在團隊和更廣泛的組織中促進和支援敏捷；

• 作為服務型領導，敏捷教練幫助創造使團隊有效敏捷工作的環境；

• 敏捷教練負責清除會妨礙開發團隊前進的障礙。許多事情都可能成為障礙，從壞了的電腦到團隊衝突，從計劃中斷到缺乏技能。但是他或她自己應該關注會危害迭代目標或是開發團隊不能自己解決的障礙。更寬泛點說，敏捷教練嘗試清除或解決會妨礙團隊有效敏捷的工作的一切障礙（也就是整個組織）。

 

 

從另一方面來看敏捷教練作為服務型領導，通過設定和維持遊戲規則，給玩家提供儘可能有效地玩遊戲的自由和支援。儘管Scrum Master做了所有的事情來幫助人們在遊戲中發揮最大的作用，但他或她的主要職責是確保遊戲的正確執行。移植到產品開發上來，意味著這是在關於有價值的產品交付中，逐步學習並讓更好的觀點湧現。

 

清除障礙——任何阻礙遊戲順利進行的障礙——敏捷教練責任之一。所以現在問題變成：敏捷團隊的成員有可能成為障礙嗎？

 

敏捷團隊的成員有可能變成障礙嗎？

 

 

如果人變成了障礙？

 

雖然我們並不樂於給人貼上“障礙”的標籤，但現實是人的確有可能妨礙敏捷的有效性。比如這些例子：

• 像案例中的，開發人員緊緊守著自己所有的“祕密”，不公開工作內容、進展如何或是其他人能如何幫助。無論他在做什麼，沒人真正知道。明顯是因為這個開發者沒有看到每日站會的價值也從不參加；

• 一個開發人員經常在晚上的時候單方面地扔掉團隊編寫的程式碼，用她認為比團隊所產生的程式碼更好的程式碼來替代它——儘管開發團隊越來越不滿;

• 一名開發人員不放過任何一個機會來表達他對Scrum的不滿，在各種敏捷活動中觸發激烈的爭論，並不顧他人的意願把注意力從手頭的事情上轉移出去（“我們又來了……”）;

• 一名開發人員利用她的資歷，不斷地批評他人的工作，當她在房間裡時總是會讓別人感到不安

這些例子本身並沒有充分的理由將某人從團隊中剔除。但是，如果同時出現了下列情況呢？

• 這種情況已經持續了一段時間，並且沒有改善的期望

• 開發團隊很清楚並且也不喜歡這種狀況，迭代回顧會上已有幾次關於它的對話。但卻未能將改變的意願付諸行動。團隊害怕採取措施，覺得不是他們的責任也沒有勇氣去做一個太沖突的決定比如從隊伍裡剔除掉某些人

• Scrum Master已經與該成員進行多次談話，來幫助他們意識到他們對團隊的影響;

 

 

換句話說，有一個未解決的衝突正在損害Scrum團隊的功能。考慮到了有這種衝突，一個Scrum Master卻什麼都不做，等待團隊自己做出決定，這真的是合理的嗎？如果每個人都清楚這是行不通的，而且它影響了團隊的運作，那麼Scrum Master就會是一個合適的人——作為一個服務領導者——介入並做需要做的事情——不管多麼困難。

 

 

一個Scrum Master什麼都不做等待團隊自己做出決定，這真的合理嗎？

 

 

 

對信任的影響？

 

一個常見的反對意見是，從團隊中移除人員會損害信任。當人們知道Scrum Master可以採取這樣的行動時，他們又會如何感到安全呢？

 

這個論點假設從一開始就有一個“信任的環境”可以被破壞。但是，如果一個團隊正在處理一場未解決的衝突——就像前面提到的例子一樣——已經有很多事情正在發生，它們正在極大地損害信任。更有可能的是，這個團隊在“人工和諧”的狀態下生存——一種不太健康的現狀。如下列信任的環境為例，是否會出現在前面提到的有衝突的團隊中？

• 進行艱難的對話而不用擔心報復;

• 對某件事持批評態度或持懷疑態度，而不用擔心遭到報復或被取笑;

• 在沒有受到指責或懲罰的情況下犯錯誤;

• 依靠團隊中的其他人來幫助你，當你陷入困境時;

• 可以“深情地戰鬥”（進行一場激烈的辯論，而不影響相關人員之間的關係）;

• 承認你不知道某件事，或者害怕它，而不用擔心後果;

• 依靠人們所說的是他們真正的想法（例如，不是表面的）;

 

如果你仔細閱讀字裡行間，不難發現這些行為與缺乏透明度、檢查和適應聯絡起來——都是關於Scrum的核心原則，也是Scrum Master要保護的核心。

 

那麼相反的情況更有可能是真的嗎？與其損耗信任，不如將一個成員從團隊中移除，這將有助於恢復信任。在團隊動力方面，它為團隊創造了空間，讓他們找到更有效的協作方式。而Scrum Master也證明了他或她願意做出這樣一個艱難的決定，比如為了團隊的利益而移除某人。移除可能是幫助恢復信任的強大訊號，而不是減少信任。

 

與其損耗信任，不如將一個成員從團隊中移除，這將有助於恢復信任。

 

 

為什麼不把決定權轉交給HR或管理層呢？

 

在這篇文章中，對這個難題的一個常見的迴應是將決策委託給團隊之外的一些成員，比如人力資源或管理層，讓他們根據呈現出來的證據做決定。然而，這種方法揭示了在Scrum中關於管理角色的傳統觀念的持續存在。

 

為了有效地與Scrum合作，Scrum指南只規定了三個角色：一個產品負責人、一個Scrum Master和一個開發團隊。這三種角色共同擁有了完全的職責可以作為一個團隊來決定產品開發和他們的內部過程。儘管管理層當然可以參與其中，但他們並不是做出決定的人。如果他們想替團隊做決定，這將破壞Scrum團隊的自組織特性，並釋放出一種決定開發和內部流程的權力並不真正屬於Scrum團隊。他們如果擁有或想要決定意味著團隊並不是真正的自組織。記住，將某人從團隊中移走並不意味著被解僱。他們很有可能在另一個團隊或公司的另一個職位上有很大的價值——僅僅是在這個團隊中沒有。

 

記住，將某人從團隊中移走並不意味著被解僱。

 

 

怎樣從敏捷小組踢人？

 

將某人從團隊中移除是一個艱難的決定，而且確實應該是最後的手段。Scrum Master應該盡一切可能幫助解決衝突。但如果其他方法都失敗了，移除是一個可行的選擇。儘管從團隊中移除某人肯定沒有“最好的方法”，但以下是一些基於我們的經驗給Scrum Master的參考：

• 確保被質疑的人已經有足夠的機會改進。因此，這一決定不應完全出乎意料;

• 誠實地說出將某人從團隊剔除的原因；

• 不要當著團隊所有人在場時宣佈這個決定，私下找到他宣佈這個決定。待人友好，有同情心，但堅定而堅決。花足夠的時間給這個人一個機會去迴應，問他們腦子裡想的是什麼; 

• 確保你在決策過程中涉及必要的人員和部門（比如人力資源管理部門），同時還要控制你作為Scrum管理者所做的決定; 

• 不要把它變成個人的，不要用個人理由來證明這一點。堅持正確的事實，或者（至少）由團隊中的大多數人分享; 

• 一起決定從此時如何開始。根據當下情況，成員可能希望馬上離開。但他們也可能更願意完成當前的衝刺。無論哪種情況，確保在決定後的幾天內與此人有跟進;

• 在作出決定後，與開發團隊分享。讓他們有機會迴應並反思所發生的一切。這也許是一個放鬆的時刻，但也可能是關於如何在未來如何預防這一問題的艱難對話;

• 不要表現得冷漠和強硬。公開表明這對你來說不是一個容易的決定，但因為對團隊有好處所以是必要的;

• 將某人從一個團隊中剔除是很困難的——特別是對於被移除的人來說。要格外尊重和同情;

• 不要向別人吹噓你是如何從團隊中移除某人的，或者你是如何挺身而出，做了一些困難的事情。對被你移除的人，以及需要的情況，給予最大的尊重。把某人從團隊中剔除不是什麼值得驕傲的事情。

 

 

如果是產品負責人呢？

 

我們認為，這篇文章中提到的所有要點也適用於產品負責人。針對產品負責人可以通過多種方式參與到遊戲中來：

• 產品負責人不願意或者不能充分為開發團隊澄清需求並確定需要構建哪些內容;

• 產品負責人沒有授權或完全缺乏產品願景來對產品做出任何決定，使得快速檢查和適應變得非常困難;

• 產品負責人正在創造一種不適合敏捷的氛圍，例如，將重點放在承諾和控制上。

 

如果所有其他的解決方案都失敗了，那麼Scrum Master的最後一招就是用更適合這個角色的組織內部或外部的人來代替產品負責人。如果這個人找不到，那麼敏捷的價值就會降低到所有人會懷疑它是否有用的程度。這再次強調了Scrum Master有多麼需要管理的授權。

 

 

關於文化差異的一點建議

 

每一種文化在處理人際衝突和信任方面都是不同的。作為作者，我們的觀點深受荷蘭文化的影響，在這種文化中，直率、開放和不受拐彎抹角的影響是有價值的。但其他文化看重的是不同的東西，比如為群體挽回面子或做出個人犧牲。無論在哪種文化中工作，Scrum Master仍然主要負責幫助團隊有效地與Scrum合作。如果有人妨礙了（比如從結構上），他們就應該做點什麼了。但是，作為一個Scrum Master，你所做的事情應該是在你所被影響的文化價值觀範圍內的。

 

無論在哪種文化中工作，Scrum Master仍然主要負責幫助團隊有效地與Scrum合作。

 

 

關於精神障礙的一點建議

 

在指導健康的個人和幫助有嚴重的精神障礙的人們（如抑鬱、成癮、精疲力竭）之間存在著巨大的差異。不管多麼誘人，把這個留給專業人士吧。作為一個Scrum Master，你應該做的一件事就是讓自己認識到這些疾病的症狀。當你看到這些症狀出現在一個團隊中，為有問題的人提供專業的幫助。

 

將嚴重的精神障礙（如抑鬱、成癮、精疲力竭）留給專業人士。

 

 

 

結語

 

我們認為如果有人成為團隊實施敏捷的障礙，敏捷教練就有權請他們離開團隊。敏捷教練的第一個責任就是確保敏捷為團隊和更廣泛的組織工作。這個責任賦予了他能踢人的權力。顯然，這個艱難的決定不可能會輕鬆。在這個帖子中，我們分享了在哪些情況下踢人是可選項的一些觀點，以及最佳方式的建議。

 

你認為這篇文章怎麼樣呢？你也曾經歷過團隊成員被敏捷教練從組裡移走嗎？後來又發生了什麼呢？