A transit department org chart keeps fare-engine, map, and accessibility specialists in separate pools so each specialist stays fully utilized, and the fare-app Product Owner sees multi-Sprint waits to assemble one citizen-facing Increment. What should the Product Owner argue the structure should optimize for?
Select an answer to reveal the explanation.
Short Explanation
Keeping every specialist “busy” is like keeping every airport gate occupied while planes sit on the taxiway. Utilization looks great on a chart and terrible to the rider waiting on a fare-app Increment. Optimize the org for flow of citizen value, not for keeping specialists 100% booked.
Full Explanation
Structures that maximize specialist utilization typically lengthen queues between skills that a single citizen-facing Increment needs. When fare-engine, map, and accessibility specialists sit in separate pools so each stays fully utilized, the fare-app Product Owner sees multi-Sprint waits to assemble one usable Increment. Advanced Product Ownership argues for organizational design that optimizes value-delivery flow: a cross-functional Scrum Team that can produce a usable Increment without waiting on specialist pools. Utilization dashboards are a local optimum that often destroys Time-to-Market and empiricism for riders.
Optimizing for higher specialist utilization percentages fails because busy experts behind queues still leave riders waiting. Keeping a component-team model with utilization dashboards as the primary constraint fails by design. Larger specialist pools sequenced by a PMO fail by scaling the handoff problem while utilization stays high.
Exam caveat: Optimize org design for flow of citizen value, not for 100% specialist utilization. Operational check: Form or staff a fare-app team with enough fare, map, and accessibility skill to finish an Increment in-team, and compare cycle time to the prior pool-wait baseline.