Three Teams, One Shared Integration Environment
Three teams - Accounts, Payments and Notifications - build a single customer platform using Scrum on the same two-week cadence but with different start days. All three deploy to one shared integration environment booked through a spreadsheet; Payments holds it for four days each sprint for end-to-end testing. Accounts cannot complete integration testing until Payments releases it, so its stories often fail the definition of done. There are frequent 'works on my machine' defects because each team mocks the others' services differently. The six-weekly cross-team release train has slipped twice. Test data is created manually per team and sometimes collides. Each team has its own tester, and there is no shared test strategy; the release train manager collects status in a weekly meeting.
1. Diagnose why the shared integration environment is causing delivery problems and propose structural alternatives.
Read the worked answer
The environment is both a bottleneck and a substitute for design. Four days of exclusive booking creates a queue, different sprint start days create wait states, and because each team mocks dependencies differently, integration defects surface only when everyone finally deploys together. Manual test data with collisions adds a second source of interference.
Structural alternatives include consumer-driven contract tests so each team can verify its assumptions about the others without deploying together; service virtualisation for dependencies that are unavailable; test data provisioned through APIs with unique namespaces per team; and ephemeral environments created on demand from infrastructure as code.
Keep one shared environment for a small, deliberate end-to-end suite, not for every story. Align sprint cadence or introduce a flow-based cross-team synchronisation for integration work. The goal is to remove the need for exclusive booking rather than to refine the spreadsheet.
2. What should change in each team's definition of done to reduce cross-team integration failures?
Read the worked answer
The definition of done should require that a story's consumer contracts are published and verified, and that the story is tested against stubs or virtual services for dependencies that are not yet available. It should also require self-provisioned, isolated test data and a successful build in an ephemeral environment.
Add explicit integration criteria: no new flaky cross-team checks, dependencies recorded, and the integrated build passing before the story is called done. This shifts integration left into each team rather than deferring it to the shared environment.
The change must be agreed by all three teams and their product owners; otherwise one team's 'done' still blocks another. The testers should facilitate a joint workshop to write the definition of done and the contract-testing approach, and then audit adherence rather than assume it.
3. The release train has slipped twice. How would you use testing to give earlier warning?
Read the worked answer
Provide warning continuously, not at the weekly status meeting. Run a cross-team smoke and synthetic suite on every merged build, with contract tests as the earliest signal of incompatible assumptions. Publish a release-readiness dashboard showing risk coverage, open cross-team defects, dependency slippage and the number of consecutive green integrated builds.
Define release readiness criteria in advance, for example no open severity 1 or 2 defects, smoke green for five consecutive builds, rollback rehearsed, and all high-risk contracts verified. Trend data then shows slippage weeks before the train date rather than after it.
Also test the integration assumptions early with mocks and virtual services, so 'works on my machine' is caught at merge time. The release train manager should consume the dashboard, not collect status manually.