Continuous Integration Is Always Red
Northwind Commerce has seven Developers working in two-week Sprints. Its continuous integration build has been red for 3 of the last 10 working days. A full build and test run takes 55 minutes, and automated test coverage is 18%, mostly unit tests written after the code. Developers work on feature branches that live an average of 9 days; code review waits another 2 days because only the tech lead approves pull requests. The team releases every six weeks after a three-day manual regression cycle performed by two testers. In the last quarter, 42 defects escaped to production, and 31% of Sprint capacity went to unplanned production support. The Scrum Master wants to 'stabilize' by adding a code freeze two weeks before release. The Product Owner asks why the team cannot release more often. The Developers say they need the freeze because merging branches near release is risky and the test environment cannot support parallel work.
1. Identify the most important development practices for this team and sequence their adoption. Justify the order.
Read the worked answer
The most important practices are not a menu; they address the system constraint. The red build for 3 of 10 days means the team lacks a trustworthy signal, so fix CI first. A red build is a stop-the-line condition: the team should swarm to restore it, keep the build fast, and not merge onto a broken mainline. Until that is true, test automation and code review improvements will be built on sand.
Second, reduce batch size and branch lifetime. Nine-day branches plus two-day review waits mean integration happens late, where defects are expensive. Adopt trunk-based development or short-lived branches (under one day), small pull requests, and a pull-request WIP limit.
Third, grow automated testing where risk is highest - critical checkout, payment, and data-integrity paths - rather than chasing a coverage number. Use the test pyramid: many fast unit tests, fewer integration and API tests, very few end-to-end tests.
Fourth, make code review a team practice, not a tech-lead queue: rotate reviewers, pair on risky changes, and automate style and static checks so humans review design and behavior. Sequence matters because branch reduction without a green build increases chaos, and automation without small batches still produces long feedback loops. A code freeze treats the symptom and increases batch size.
2. What should the team do about the 55-minute build and the 2-day code review wait without asking for a code freeze?
Read the worked answer
Build time: profile the pipeline and parallelize independent stages; cache dependencies and build artifacts; run fast unit and static checks on every pull request and the full regression suite after merge or nightly; split slow end-to-end tests and run them in parallel; remove redundant tests; use incremental builds. Target a fast feedback loop under 10 minutes for the pull request and a full run that does not block the team.
Review wait: the two-day wait is a queue, not a capacity problem. Shrink pull requests to a few hundred lines, limit work in progress, rotate reviewers, define a review service level (for example, first response within four working hours), and let any qualified Developer review - not only the tech lead. Pairing or mobbing on complex changes removes review latency and spreads knowledge.
A code freeze is the wrong tool: it increases batch size, delays feedback, and hides integration risk until the most dangerous moment. The team should instead make integration continuous and prove it with a short-lived branch experiment over two Sprints. Measure pull-request age, build duration, and escaped defects before and after.
3. How should the Definition of Done and Sprint Review change to make the impact of these practices visible?
Read the worked answer
The Definition of Done should include 'CI green, automated regression for changed behavior passes, and the Increment is deployable from trunk by the team.' That makes the practices enforceable rather than aspirational. The Sprint Review should show a working Increment in a production-like environment, not slides, and should include the Product Owner's assessment of value and the metrics that matter: escaped defects, build health, lead time from merge to deploy, and percentage of Sprint capacity spent on production support.
Reasoning: the team's current Definition of Done stops at unit tests, so manual regression and code freezes are invisible work outside the definition. The Review then becomes a demo of unfinished product, and stakeholders cannot see the real cost of the release process. By making deployability and automated regression part of Done, the team creates transparency. The Review can then discuss why 31% of capacity goes to support and what to order next. The Scrum Master should help the team use these metrics for improvement, not as a performance scoreboard.