Falcon: the hardening sprint that never goes away
Team Falcon builds payment-authorisation services in two-week Scrum sprints. Sprint reviews are skipped because, the team says, the demo environment is unstable. After every fourth sprint the team stops feature work for a three-week stabilisation phase, hands a build to a separate QA group and fixes whatever that group finds. The product owner visits refinement once a month and approves scope changes through a written change-request form; on average a story sits 11 days between ready and in progress. The delivery manager publishes velocity weekly (Falcon: 42 points per sprint, target 50) and ranks teams. Testers begin writing detailed scripts only after code freeze, so the last three days of each sprint are spent executing scripts derived from the specification rather than from the code. Two of the last three releases reached production with severity-2 defects, both in retry logic.
1. Which agile principles are being violated, and what are the two most damaging structural anti-patterns? Justify each with evidence from the setup.
Read the worked answer
- Deliver working software frequently and working software over comprehensive documentation: the three-week stabilisation phase plus a separate QA group means a change can wait up to eight weeks before anyone outside the development team exercises it. Feedback latency that long turns cheap defects into expensive ones and makes the sprint review pointless.
- Business people and developers must work together daily: a product owner who appears monthly and approves change through a written form is a command-and-control interface, not collaboration. The 11-day ready-to-in-progress queue is the visible symptom of that batching.
- Continuous attention to technical excellence: quality is outsourced downstream, so developers have no incentive to build testability or automated checks. The two structural anti-patterns doing most of the damage are (1) the mini-waterfall phase gate, where a stabilisation phase and an external QA group replace continuous verification, and (2) velocity as a comparative target, 42 against 50, which rewards point inflation and penalises refactoring and test work. A third, smaller one: scripts written from the specification after freeze encode the author's assumptions rather than the code's behaviour, so they confirm rather than challenge. The two escaped severity-2 defects are the proof: retry and error-handling paths are exactly what component checks and exploratory charters around failure modes expose early, and exactly what scripted happy-path execution misses.
2. You are the team's tester. Propose a 30-day plan with three actions and the signal you would use to know each one worked. Explain why you would not simply ask for more testers.
Read the worked answer
- Action 1, weeks 1 to 2: pair with the developer who owns retry logic and write component-level checks for the failure paths before the next feature touches them. Signal: every new retry branch arrives with at least one automated check, and no retry defect escapes in the next two releases.
- Action 2, weeks 1 to 3: run three-amigos sessions on the three riskiest stories at refinement and convert acceptance criteria into concrete examples, including at least one error example each. Signal: stories rejected at the sprint review fall, and ready-to-in-progress time drops below three days.
- Action 3, weeks 2 to 4: put the stabilisation phase on a visible burndown and refill it with sprint-level automation and exploratory work instead of a big-bang fix window; invite one member of the separate QA group to the daily standup. Signal: stabilisation shrinks from three weeks to under one, and the sprint review happens in both sprints. I would not open with a headcount request because the constraint is feedback latency and batch size, not test execution capacity. Adding testers to a phase-gated process widens the queue and lengthens the delay, and it reinforces the belief that quality belongs to a group rather than to the team. Headcount is a defensible argument only once the loop is short and the automated checks exist to absorb new capacity.