Coordination at Scale

Coordination across ARTs is where Large Solution SAFe earns its keep—or fails. Several patterns help:

1. Communities of Practice (CoPs) — Cross-ART groups organized around skills or domains (e.g., frontend CoP, security CoP, data engineering CoP). CoPs share knowledge, align standards, and reduce duplication. They meet regularly but don't own delivery—teams do.

2. Shared Services — Small teams that provide capabilities used by all ARTs. Examples: platform team, DevOps/SRE team, data platform team. These teams operate on their own cadence but align with the Solution Train's PI rhythm.

3. System Teams — Dedicated teams that own integration, build infrastructure, and system-level testing. They ensure the solution-level CI/CD pipeline works and maintain integration environments.

4. Release Management — Coordinating when and how the solution is released. In large solutions, release may happen on a different cadence than the PI cadence. A release may include work from multiple PIs, or a PI's work may be released incrementally.

5. Architecture Councils — Solution Architects from all ARTs meet regularly to align on architectural direction, resolve cross-ART technical decisions, and maintain the solution-level architecture runway.

The common thread: these patterns create lightweight, persistent coordination structures that operate continuously, not just during planning events. PI Planning is essential, but it's not enough—coordination must happen between planning events too.

Many large solutions involve external suppliers—hardware vendors, third-party software providers, outsourced development teams. Coordinating with suppliers adds complexity because you have less control.

Strategies for supplier coordination:

1. Align on cadence: If possible, align supplier delivery cadence with your PI cadence. Even if the supplier doesn't use SAFe, regular delivery points create integration opportunities.

2. Define contracts as interfaces: Instead of specifying how the supplier should work, define clear interface contracts (APIs, protocols, data formats). Test against the contract, not the implementation.

3. Include supplier representatives in PI Planning: Invite key supplier contacts to Pre-PI and Post-PI Planning. They don't need to attend the full ART PI Planning, but they need visibility into plans and dependencies.

4. Create integration stubs: Build mock versions of supplier components so your teams can develop and test without waiting for the real thing. This decouples your development pace from the supplier's.

5. Regular integration checkpoints: Schedule regular integration sessions (weekly or bi-weekly) where your system integrates with actual supplier deliverables. Don't wait until the end of the PI.

Supplier coordination is often the most frustrating part of Large Solution SAFe because you can't mandate how external organizations work. Focus on what you can control: interface definitions, integration testing, and clear communication of expectations.

ART boundaries aren't permanent. As the product and organization evolve, you may need to reorganize:

Signs you should split an ART:

• More than 12 teams—the ART is too large for effective PI Planning
• Two distinct value streams exist within one ART
• Most dependencies are within subgroups, not across the whole ART
• The System Demo has become too long and unfocused

Signs you should merge ARTs:

• Two ARTs have extensive dependencies that create constant coordination overhead
• A value stream has been artificially split across ARTs
• One ART is too small (fewer than 3 teams) to justify the overhead
• Teams are frequently "loaned" between ARTs

Signs your ART boundaries are wrong:

• Cross-ART dependencies outnumber within-ART dependencies
• ARTs don't align with the architecture (Conway's Law violation)
• PI Planning produces more inter-ART dependency strings than intra-ART ones

Reorganizing ARTs is disruptive, so don't do it casually. But don't avoid it either—living with wrong boundaries creates ongoing coordination tax that compounds every PI. The best time to reorganize is at a PI boundary.