Only one specialist can change the parking-meter firmware, so every firmware story waits on that person. What should the Scrum Master/Team Coach coach?
Select an answer to reveal the explanation.
Short Explanation
One meter tech with the only key is a single point of failure downtown. Pair, share the key, grow collective ownership. Queuing a month of firmware or hiding it on a private board just makes the line longer.
Full Explanation
Specialist bottlenecks destroy flow and concentrate quality risk. When only one person can change parking-meter firmware, every firmware story waits on that person—public meters stay stuck behind a single civic specialist. The Scrum Master/Team Coach should coach pairing and growing collective ownership so knowledge spreads, the bottleneck shrinks, and firmware quality is no longer trapped in one head.
Queuing all firmware work until the specialist has a free month fails by concept: it maximizes delay for meter fixes instead of expanding capacity. Outsourcing every firmware change without sharing knowledge fails by concept because the team remains dependent and learns nothing for the next interrupt. Giving the specialist a private board so others never touch firmware fails by concept: it institutionalizes the bottleneck and hides the wait from the team system.
Exam caveat: SAFe and Lean coaching treat knowledge silos as flow constraints; pairing and collective ownership are preferred over hero queues. Collective ownership does not mean reckless edits—it means shared standards, paired changes, and a growing bench for critical civic firmware.
Operational check: schedule paired firmware sessions, document the change path on the team board, measure aging of firmware stories waiting on the specialist, and confirm at least one additional teammate can complete a supervised meter firmware change.