隨著開發周期的縮短，團隊成員間持續的軟體交付、共同承擔的角色和職責，使得敏捷軟體開發的效率有所提高。
實際上，敏捷專案源於消除廣泛、低效率瀑布式方法：軟體通常會延遲交付，而且並沒有按照設計的那樣滿足用戶的需求。
與瀑布式方法不同
敏捷專案只有代碼編譯完成後才能進行測試，敏捷專案能夠很好的保持軟體開發流程的運行。
例如對軟體各部分叠代進行測試這樣的實踐能有助於專案取得穩定的發展，並且顯示出只涉及該團隊的專案。
但是當敏捷開發專案發展到包含多個團隊的時候，團隊成員工作地點不同，經常會相隔很遠，
此時又會發生什麽樣的變化呢？當團隊成員無法在同一間屋子內工作時，他們該如何一如既往的堅持遵守工作原則呢？
多倫多敏捷諮詢公司Scott Ambler
及其附屬公司的創始人Scott Ambler說：
如果敏捷專案範圍超過一個團隊時，專案運行就會出現問題。
敏捷專案規模擴大，就會增大了敏捷專案起初打算縮減的管理負載。
面臨的挑戰是：軟體公司要如何管理多團隊的敏捷專案，並且不失其敏捷特性。
根據敏捷專案專家所說
完全消除這些風險是不可能的。畢竟，與獨立團隊的敏捷專案相比，多團隊敏捷專案需要投入更多管理。
重複工作是不可避免的，一些技術有助於多團隊在一個專案中協同工作，並保證敏捷軟體開發的高效性。
阿林頓Rothman諮詢有限公司的創始人Johanna Rothman認為
如何設置這些團隊的組織架構，如何分配工作任務以及如何管理這些組織之間的依賴關系是判斷成功還是失敗的標誌。
Rothman的解釋是：“於細微處見真章”。
一、適宜的團隊成員數量
轉向多團隊敏捷專案是個不小的壯舉。敏捷專案諮詢師James Shore說，在沒有完全掌握獨立團隊敏捷專案開發過程之前，
不要採用多團隊敏捷專案，這一點非常重要。這聽上去是很明顯的，
但是Shore曾經見過許多公司在沒有獨立團隊開發敏捷專案經驗的情況下就引入多團隊敏捷專案模式。
他認為，這必然會失敗。“這是在做跳躍式改變。如果企業沒有按照漸進式的方式來開發敏捷專案，那麽很快就會出現溝通和編碼質量問題。”
敏捷專案的獨立團隊一般以少於10人為宜。Shore認為，一旦團隊成員數量達到10或者12人，那麽最好成立兩個團隊。他提到，他的合作夥伴Diana Larsen(俄勒岡州波特蘭市的Future Works敏捷專案諮詢公司的合作夥伴)認為一個團隊最佳的成員數為“五到九人。” Shore說，一旦團隊成員數目過多，就要考慮將一個團隊分為兩個團隊。“即使名義上團隊成員還是屬於同一個團隊，但是他們已經形成兩個小團體，不同時在一個團隊工作了。無論你是否承認，一個團隊都被分成兩個相互依賴的團隊。” 
二、所需的適當技能
Rothman認為，當多團隊專案組開始工作時，保持小型團隊是保證專案敏捷性的關鍵。她建議團隊成員數量以5-7人為最佳。她接觸的一些顧客認為，沒有足夠的人能完全掌握敏捷開發專案所需技能。他們說：”我們沒有足夠多的測試人員、DBA和用戶體驗專家。”Rothman並不建議擴大團隊成員數量，而是建議團隊決定如何增加團隊成員在敏捷專案中所缺乏的技能。Ambler同意以上觀點。他說，企業希望團隊自身具備完成工作所需的技能。“但是這樣做有風險。團隊需要利用企業資源，與企業架構師合作，重複使用工作人員以及數據庫人員。”
文章來源：專案管理者聯盟
