敏捷项目源于消除广泛、低效率瀑布式方法：软件通常会延迟交付，而且并没有按照设计的那样满足用户的需求。与瀑布式方法不同，敏捷项目只有代码编译完成后才能进行测试，敏捷项目能够很好地保持软件开发流程的运行。例如对软件各部分迭代进行测试这样的实践能有助于项目取得稳定的发展，并且显示出只涉及该团队的项目。
随着开发周期的缩短，团队成员间持续的软件交付、共同承担的角色和职责，使得敏捷软件开发的效率有所提高。但是当敏捷开发项目发展到包含多个团队的时候，团队成员工作地点不同，经常会相隔很远，此时又会发生什么样的变化呢?当团队成员无法在同一间屋子内工作时，他们该如何一如既往的坚持遵守工作原则呢?
多伦多敏捷咨询公司Scott Ambler及其附属公司的创始人Scott Ambler说：“如果敏捷项目范围超过一个团队时，项目运行就会出现问题。”敏捷项目规模扩大，就会增大了敏捷项目起初打算缩减的管理负载。面临的挑战是：软件公司要如何管理多团队的敏捷项目，并且不失其敏捷特性。
根据敏捷项目专家所说，完全消除这些风险是不可能的。毕竟，与独立团队的敏捷项目相比，多团队敏捷项目需要投入更多管理。重复工作是不可避免的，一些技术有助于多团队在一个项目中协同工作，并保证敏捷软件开发的高效性。
阿林顿Rothman咨询有限公司的创始人Johanna Rothman认为，如何设置这些团队的组织架构，如何分配工作任务以及如何管理这些组织之间的依赖关系是判断成功还是失败的标志。Rothman的解释是：“于细微处见真章”。
1、所需的适当技能
Rothman认为，当多团队项目组开始工作时，保持小型团队是保证项目敏捷性的关键。她建议团队成员数量以5-7人为最佳。Rothman并不建议扩大团队成员数量，而是建议团队决定如何增加团队成员在敏捷项目中所缺乏的技能。她接触的一些顾客认为，没有足够的人能完全掌握敏捷开发项目所需技能。“他们说：‘我们没有足够多的测试人员、DBA和用户体验专家。’”
Ambler同意以上观点。他说，企业希望团队自身具备完成工作所需的技能。“但是这样做有风险。团队需要利用企业资源，与企业架构师合作，重复使用工作人员以及数据库人员。”
2、适宜的团队成员数量
转向多团队敏捷项目是个不小的壮举。敏捷项目咨询师James Shore说，在没有完全掌握独立团队敏捷项目开发过程之前，不要采用多团队敏捷项目，这一点非常重要。这听上去是很明显的，但是Shore曾经见过许多公司在没有独立团队开发敏捷项目经验的情况下就引入多团队敏捷项目模式。他认为，这必然会失败。“这是在做跳跃式改变。如果企业没有按照渐进式的方式来开发敏捷项目，那么很快就会出现沟通和编码质量问题。”
敏捷项目的独立团队一般以少于10人为宜。Shore认为，一旦团队成员数量达到10或者12人，那么最好成立两个团队。他提到，他的合作伙伴Diana Larsen(俄勒冈州波特兰市的Future Works敏捷项目咨询公司的合作伙伴)认为一个团队最佳的成员数为“五到九人。” Shore说，一旦团队成员数目过多，就要考虑将一个团队分为两个团队。“即使名义上团队成员还是属于同一个团队，但是他们已经形成两个小团体，不同时在一个团队工作了。无论你是否承认，一个团队都被分成两个相互依赖的团队。”