Courseiva

SAFe-Agilist Establishing Team and Technical Agility Practice Question

An Agile Team on an Agile Release Train has just finished a two-day workshop where they practiced test-driven development, paired programming, and collective code ownership. Six weeks later, the Release Train Engineer notices the team's automated test coverage has plateaued and integration defects are climbing. What should the team's Scrum Master do first to sustain the new technical practices?

⚠ Common exam trap

The trap here is assuming that a one-time training event automatically changes behavior, so the fix must be an external enforcement mechanism rather than embedding the practice in the team's Definition of Done with protected slack.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Help the team make the new practices part of their Definition of Done and create slack in each Iteration for deliberate practice and refactoring.

Technical agility is sustained when new engineering practices become part of the team's working agreements and Definition of Done, with enough slack to practice them. Making test-driven development, pairing, and collective ownership routine, plus reserving capacity for refactoring, prevents the regression the Release Train Engineer observed. External mandates and large rewrites address symptoms rather than building the team's own capability.

Answer analysis

Option-by-option breakdown

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

  • ✗

    Escalate to the Release Train Engineer and request that the System Architect assign a technical coach to the team permanently.

    Why it's wrong here

    Requesting an external coach is a reasonable supporting action, but it places ownership outside the team. The Scrum Master's first move should be to help the team internalize the practices rather than escalate for a permanent external resource. Assigning a coach forever also risks creating dependency instead of building the team's own capability and self-management around Built-in Quality.

  • ✗

    Recommend that the team pause feature development for two Program Increments so they can rewrite the codebase with the new practices.

    Why it's wrong here

    Halting feature work for two Program Increments is a disproportionate response that would starve the Agile Release Train of value and likely be rejected at the Program Increment boundary. Sustained improvement in technical agility comes from incremental integration of practices into daily work, not from a large upfront rewrite. The team's plateau does not justify freezing delivery across the train.

  • ✗

    Ask the Release Train Engineer to add a quality gate to the Continuous Integration pipeline that blocks merges when coverage drops below the agreed threshold.

    Why it's wrong here

    A coverage gate is a control mechanism that can create gaming behavior, such as writing trivial tests to satisfy the threshold. It also imposes enforcement from outside the team, which undermines self-management. While automated checks have value, the scenario calls for sustaining practices the team already learned, and a hard external gate does not build the intrinsic motivation or skills needed.

  • ✓

    Help the team make the new practices part of their Definition of Done and create slack in each Iteration for deliberate practice and refactoring.

    Why this is correct

    Embedding technical practices in the team's Definition of Done and protecting capacity for practice and refactoring is how new behaviors become durable habits. Without slack, teams revert to old shortcuts the moment delivery pressure rises. This directly builds the Built-in Quality competency in the Establishing Team and Technical Agility dimension and keeps the team self-managing rather than dependent on outside help.

Visual reference

Client DHCP Server 1 Discover (broadcast) 2 Offer (IP: 192.168.1.10) 3 Request (I accept) 4 Acknowledge (lease confirmed) DORA — the four-step DHCP lease process

About these practice questions

One of 315 original SAFe-Agilist practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written and reviewed by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

Last reviewed September 2026 · checked against the official Scaled Agile exam blueprint

This SAFe-Agilist practice question is part of Courseiva's free Scaled Agile certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAFe-Agilist exam.