Courseiva

SAFe-Agilist Establishing Team and Technical Agility Practice Question

During a Program Increment, an Agile Team's Continuous Integration pipeline takes over four hours to run, so developers batch their commits and merge only at the end of the day. Integration failures now surface late, and the team misses several Iteration Goals. Which action best addresses the root cause while preserving the team's ability to deliver value each Iteration?

⚠ Common exam trap

The trap here is treating the symptom of pipeline contention by adding capacity, when the real issue is feedback latency that drives developers to batch commits in the first place.

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

✓

Split the pipeline into a fast commit stage that runs in minutes and a slower comprehensive stage that runs in parallel, so developers get rapid feedback.

The root cause is a slow feedback loop that forces batching. Splitting the pipeline into a fast commit stage and a slower parallel comprehensive stage lets developers integrate small changes frequently and learn about failures in minutes. More environments, local full runs, or nightly centralized testing all preserve the long feedback delay and therefore keep the batching behavior intact.

Answer analysis

Option-by-option breakdown

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

  • ✗

    Move integration testing to the System Team and have them run the full pipeline nightly after all teams have merged their work.

    Why it's wrong here

    Nightly integration by a separate team reintroduces large batches and delays feedback by up to a day, which is the opposite of continuous integration. It also transfers responsibility for integration away from the developers who created the change, weakening collective ownership and Built-in Quality. The team's missed Iteration Goals stem from late failure detection, and this approach makes detection even later.

  • ✗

    Require developers to run the full pipeline locally before every commit and block merges until each developer reports a green run.

    Why it's wrong here

    Local full-pipeline runs duplicate the same four-hour cost on each developer's machine and create uneven environments, so results would still differ from the shared pipeline. Blocking merges on self-reported local runs adds manual coordination and slows integration further. The problem is feedback latency in the shared system, and pushing that latency onto individuals does not resolve it.

  • ✓

    Split the pipeline into a fast commit stage that runs in minutes and a slower comprehensive stage that runs in parallel, so developers get rapid feedback.

    Why this is correct

    A staged pipeline with a fast commit gate and a broader parallel stage is the standard way to shorten feedback time without abandoning comprehensive testing. Developers can integrate small changes frequently because the critical feedback arrives in minutes, while deeper tests still run. This restores small-batch integration and the continuous flow needed to meet Iteration Goals, directly strengthening the Continuous Delivery Pipeline competency.

  • ✗

    Increase the number of integration environments so multiple developers can run the full pipeline simultaneously.

    Why it's wrong here

    Adding environments may reduce queuing, but the four-hour pipeline remains the fundamental constraint. The team would still batch commits because the feedback loop is too slow to run on every change. This treats a symptom of capacity contention rather than the root cause, which is the time it takes to get feedback on an integration. Faster feedback, not more parallel slow pipelines, restores small-batch integration.

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.