On the building-permits team, pairing is framed as “we go half as fast.” How should the Scrum Master / Team Coach reframe the quality debate?
Select an answer to reveal the explanation.
Short Explanation
“Pairing makes us half as fast” counts keystrokes and ignores the bounce-back from failed inspections. Permits that come back are slower, not faster. Measure the whole trip, including rework, not how quickly someone types alone.
Full Explanation
On a building-permits team, pairing framed as “we go half as fast” measures local typing speed and ignores rework when inspections fail. Built-in quality improves end-to-end flow time for residents waiting on permits. The Scrum Master / Team Coach reframes speed as total cycle time including bounce-backs, defects, and knowledge transfer—so pairing can be evaluated as a quality practice that shortens the whole trip, not as wasted keystrokes. That system measure is the relevant conflict frame for permit flow and protects applicants from a false local-speed win.
Agreeing that pairing halves throughput and dropping it protects a local-speed illusion while lengthening reopen rates for applicants. Mandating pairing every hour by policy ends debate without inspecting when pairing helps most and when solo work is fine. Scoring only individual story-point velocity makes collaboration look like lost capacity and rewards the wrong civic outcome.
Exam caveat: SASM favors flow and quality measures over individual utilization when quality practices are under attack. Operational check: compare permit cycle time and reopen rates for paired versus unpaired slices before deciding pairing “slows” the bureau.