Team and Technical Agility

The best approach is to offload the infrastructure responsibilities to a Platform Team and consume the capabilities via self-service components.

Reasoning:
According to SAFe and the Team Topologies patterns adopted by the framework, the primary goal of a Stream-aligned team is to deliver flow of value. When the cognitive load becomes too high due to the complexity of the underlying technology stack (like maintaining a custom delivery pipeline), the flow slows down and quality suffers. The specific purpose of a Platform Team is to provide internal services and underlying infrastructure as a product (often via self-service), thereby reducing the cognitive load on Stream-aligned teams. This allows the Stream-aligned team to focus on customer functionality rather than 'plumbing.'

Why other options are incorrect:

• Expand the team size: Simply adding more specialists to the team often violates the intent of small, agile teams (the 'two-pizza' rule). Increasing team size increases communication overhead and does not fundamentally solve the issue of the domain complexity being too large for a single unit to manage effectively.
• Reclassify as a Complicated Subsystem Team: While Complicated Subsystem teams handle heavy cognitive load for specific components, reclassifying the entire group would mean they stop delivering business value (Stream-aligned work). Additionally, a delivery pipeline is generally considered 'Platform' infrastructure rather than a specific subsystem component (like a physics engine or face-recognition module).
• Implement a rotation policy: Rotating members might temporarily alleviate individual burnout, but it does not reduce the total cognitive load required to manage the system. The structural complexity remains, continuing to drag down the team's overall velocity and ability to focus on value delivery.

The correct organizational design strategy is to optimize the Cognitive Load by restructuring the team to focus on a single domain.

In SAFe, which incorporates concepts from the book Team Topologies, 'Cognitive Load' refers to the amount of mental effort required by a team to understand and maintain their systems. When a team is required to work across three distinct and unrelated business domains, the context switching and breadth of knowledge required often exceed the team's cognitive capacity. This state, often described as being technically overwhelmed, is the root cause of low quality, as the team cannot effectively master the intricacies of all three areas simultaneously.

By restructuring the team to focus on a single domain (creating a Stream-aligned team with a manageable scope), you align their responsibilities with their mental capacity, allowing them to achieve mastery and improve quality inherently.

Why the other answers are incorrect:

• Implement comprehensive Test-Driven Development...: While TDD is an excellent technical practice for ensuring code quality, it does not address the root organizational issue. If the team is cognitively overloaded, they will struggle to write effective tests or maintain the discipline required for TDD across unrelated domains.
• Establish a continuous Pair Programming rotation...: Pair programming is useful for knowledge sharing, but it does not reduce the total volume of unrelated domain knowledge the team must possess. It treats the symptom of knowledge silos but not the cause of excessive scope.
• Assign a dedicated System Team...: The System Team in SAFe is primarily responsible for building the development infrastructure, toolchain, and helping with end-to-end integration, not taking over maintenance for specific business features. Moving maintenance to another team discourages the DevOps mindset of 'you build it, you run it' and creates handoffs rather than fixing the team's scope.

The correct answer is to adjust the team topology to ensure the required cognitive load remains within the team's effective capacity.

This question addresses the concept of 'Cognitive Load' as defined in Team Topologies and adopted by SAFe. When a team, even a highly skilled one, is responsible for too many disparate technological domains (e.g., mobile, mainframe, and analytics), the intrinsic and germane cognitive load exceeds their capacity. This leads to bottlenecks, quality issues, and burnout.

According to SAFe principles regarding team organization, the breakdown of responsibilities must respect the team's limits. If a single stream-aligned team cannot handle the breadth of the solution, the organization must restructure—perhaps by creating a Complicated Subsystem team for the mainframe or a Platform team for the analytics feed—so that the stream-aligned team can focus on the flow of value without being overwhelmed.

Why the other answers are incorrect:

• Implementing a rigorous rotation strategy does not reduce the total complexity the team must manage; it often increases the burden of context switching and reduces the depth of ownership required for complex systems.

• Expanding the team size significantly violates the Agile principle of small, high-performing teams (typically 5-11 members). Larger teams suffer from increased communication overhead and reduced decision-making speed, often worsening the flow problems rather than solving them.

• Standardizing the development environment is a good long-term architectural goal to reduce extraneous cognitive load, but it is rarely a sufficient or immediate structural fix for a team drowning in the conceptual complexity of three distinct and heavy domains like mainframes and mobile apps.