SSM Introducing Scrum in SAFe Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Instruct the System Architect to stop responding to team members and route all questions through the Scrum Master.

  Why it's wrong here

  Blocking direct communication with the System Architect damages the technical guidance flow the train depends on. The Scrum Master should not become a communication gatekeeper, because that slows technical decisions and creates a bottleneck. The goal is to strengthen the team's internal collaboration while preserving appropriate access to architectural expertise when the team genuinely needs it.

• ✓

  Coach the team to resolve technical disagreements internally first, escalating to the System Architect only when a train-level decision is needed.

  Why this is correct

  This builds the team's self-management and keeps architectural escalation meaningful. The System Architect sets intentional architecture and supports emergent design across the train, so teams should resolve local technical choices themselves and escalate only cross-team or train-level concerns. Coaching this distinction reduces duplicated decisions and rework while preserving the architect's role in enabling the train's technical direction.

• ✗

  Ask the Release Train Engineer to assign one team member as the sole technical decision maker for the team.

  Why it's wrong here

  Creating a single technical decision maker concentrates authority and undermines the team's collective ownership of design. In SAFe, technical decisions emerge from the team, guided by the System Architect's intentional architecture. Appointing an internal authority figure may reduce visible conflict but replaces it with dependence, and it does not address the root cause of bypassing the team's own problem-solving.

• ✗

  Document every escalation in the team's Retrospective board and review the list with the System Architect at the end of the PI.

  Why it's wrong here

  Tracking escalations for a later review delays correction and turns a behavior problem into an administrative exercise. The Retrospective can be a useful forum to discuss patterns, but waiting until the end of the Program Increment allows duplicated design decisions and rework to compound. The Scrum Master should coach the desired behavior promptly and directly rather than logging it for future discussion.