越大型的項目，敏捷團隊的體積可能越大，迭代的次數越多，產品的架構也更容易產生變化，設計的復雜度也更大。因而，我們需要更加重視產品架構建設，代碼重構策略和加強團隊間的協作。
最好的設計來自團隊而不是某個人，無論是代碼還是架構設計還是測試方案都很大程度的依賴于團隊的共同承擔。而實際項目經驗告訴我們，敏捷模式下，往往因為各個團隊具有較為獨立的活動能力和決策力，團隊成員通常更關注所屬團隊的責任范圍內工作，無論是開發人員還是測試人員都潛意識的將依賴于其他團隊開發和測試的工作放到靠后的開發周期，寄希望于所有需要的前提和依賴條件最終一定得到解決，而那時后再開始這部分工作也不遲。因此，這種弱勢的團隊協作成為項目進度不能保障的罪魁禍首。
在我們項目中，也曾經因為某些組件間接口定義時沒有做好統一規劃，以致產品整合階段測試和開發進展非常緩慢，回歸現象頻繁出現，團隊的士氣受到了極大的傷害。因此作為敏捷團隊，特別是敏捷測試團隊應該更早的暴露接口缺陷，來設計適量的測試用例覆蓋這些耦合部分的活動將為產品的整合帶來更小的風險。幫助開發人員盡早認識到其后果的嚴重性，項目將最終受益。而敏捷原則中提到的不斷的整合的思想正是我們克服這個困難的最佳實踐。
除了項目管理層通過干預手段解決這部分問題外，鼓勵團隊成員主動承擔額外的工作也是做好協調團隊間工作，降低總體風險的最佳途徑。