越大型的项目，敏捷团队的体积可能越大，迭代的次数越多，产品的架构也更容易产生变化，设计的复杂度也更大。因而，我们需要更加重视产品架构建设，代码重构策略和加强团队间的协作。
最好的设计来自团队而不是某个人，无论是代码还是架构设计还是测试方案都很大程度的依赖于团队的共同承担。而实际项目经验告诉我们，敏捷模式下，往往因为各个团队具有较为独立的活动能力和决策力，团队成员通常更关注所属团队的责任范围内工作，无论是开发人员还是测试人员都潜意识的将依赖于其他团队开发和测试的工作放到靠后的开发周期，寄希望于所有需要的前提和依赖条件最终一定得到解决，而那时后再开始这部分工作也不迟。因此，这种弱势的团队协作成为项目进度不能保障的罪魁祸首。
在我们项目中，也曾经因为某些组件间接口定义时没有做好统一规划，以致产品整合阶段测试和开发进展非常缓慢，回归现象频繁出现，团队的士气受到了极大的伤害。因此作为敏捷团队，特别是敏捷测试团队应该更早的暴露接口缺陷，来设计适量的测试用例覆盖这些耦合部分的活动将为产品的整合带来更小的风险。帮助开发人员尽早认识到其后果的严重性，项目将最终受益。而敏捷原则中提到的不断的整合的思想正是我们克服这个困难的最佳实践。
除了项目管理层通过干预手段解决这部分问题外，鼓励团队成员主动承担额外的工作也是做好协调团队间工作，降低总体风险的最佳途径。