Scrum指南建议有3到9名成员实际执行sprint backlog，但是实际情况中，一个产品背后常有几十甚至上百人投入支持。为了方便管理，这些成员通常会被划分为不同的团队，这个时候，如何可视化，管理以及进一步减少团队间的依赖关系就成为一个关键的且必须解决的问题。这影响到产品特性交付的及时性以及可靠性。
一般来说有这个几个方法：
使用看板标明团队的角色，开发进程，以及团队之间的依赖关系，并且将看板公开给大团队的所有成员，使得任何进程或者需求变化，因为依赖关系而对其他团队造成的影响都能够在看板上得到体现。
但是这个只是将依赖关系可视化了，并没有真正降低团队的依赖性，使团队的运作更加灵活。要从根本上解决问题可以从技术，需求，团队三个方面下手。
1. 技术：用技术工程手段，软件模块解耦，开发前进行模块设计，更多使用战略编程而不是战术编程。降低接口的复杂度，暴露更少信息给调用者。把简单留给别人，把复杂留给自己。增加代码的可读性和可维护性和接口的可扩展性。
2. 需求：重新调整需求领域，做好业务架构设计，让需求去驱动更加模块化，独立化的代码编写以及系统的优化和重构。具体请参加DDD - Domain Driven Development.
3. 团队：可选择应用大型敏捷框架，如LeSS (Large Scale Scrum)。组建特性团队使得每个团队都可以相对独立地交付端到端地业务价值。同时对于团队之间的协作要持续强调集成纪律。
