Bike-share backend developers never talk to the customer-service clerks who hear rider issues. What performance trait should the SM/TC restore?
Select an answer to reveal the explanation.
Short Explanation
Backend work with no clerk in the loop is a bike shop that never talks to the people holding the broken chains. Riders already told customer service what failed. High-performing teams stay close to that feedback, not just to the ticket queue.
Full Explanation
High-performing teams stay connected to customer and user feedback. Bike-share backend developers who never talk to customer-service clerks who hear rider issues lose the signal that should steer technical work. The Scrum Master/Team Coach should restore direct or frequent feedback loops with clerks (and riders via the Product Owner) so APIs and services solve real civic mobility pain.
Isolating backend work from clerks so developers stay focused on tickets fails by concept: ticket focus without user signal optimizes the wrong work. Letting the Product Owner summarize clerk complaints only once a year fails by concept by starving empiricism between annual summaries. Measuring performance only by API call volume fails by concept because volume is not rider-value or issue resolution.
Exam caveat: SAFe emphasizes customer-centricity and feedback; team performance includes learning from those who hear users daily. Connection can be office hours, shared reviews, or embedded feedback—not only executive dashboards for a bike-share program.
Operational check: schedule recurring clerk feedback sessions or shadowing, feed top rider issues into backlog refinement with the Product Owner, and show at least one backend change driven by clerk-reported problems.