A vendor library used by the property-appraisal site has no tests, and every upgrade freezes the team. How should the Scrum Master/Team Coach treat that risk?
Select an answer to reveal the explanation.
Short Explanation
An untested vendor library under the appraisal site is a rotten piling under the pier. Pretending it is fine, never touching it, or blaming the vendor does not keep the pier open. Put tests and a plan around the upgrade so the freeze stops owning the sprint.
Full Explanation
Untested vendor dependencies are technical risk that must be managed as flow work. A property-appraisal site library without tests that freezes the team on every upgrade is an interrupt factory for civic valuation work. The Scrum Master/Team Coach should treat the dependency as visible risk: add characterization tests, isolate the library, and plan upgrades so freezes shrink instead of surprising the board.
Ignoring the library until an upgrade fails in production fails by concept: production is the worst place to discover appraisal-site breakage. Banning all upgrades forever fails by concept by accumulating security and compatibility debt until a forced, larger freeze. Assigning blame to the vendor and stopping visualization of the freeze fails by concept because hiding the interrupt removes the coaching signal without reducing risk.
Exam caveat: SAFe and DevOps thinking manage external dependency risk explicitly; “vendor’s fault” is not a flow strategy. Isolation seams and automated verification are preferred over hope or permanent upgrade freezes on public-facing appraisal systems.
Operational check: add a thin automated characterization suite around the library’s use on the appraisal site, schedule a controlled upgrade in a non-production path first, visualize upgrade risk on the board, and measure freeze duration before versus after isolation/tests.