Facing a tight retail launch date, the Developers on a home-robot company's Scrum Team agree among themselves to stop writing automated tests for new app features for the rest of the release, planning to "catch up on testing later." Does self-management give them the authority to make this change on their own?

Whether the Developers can change a practice on their own hinges on whether that practice is embedded in the team's Definition of Done: internal technique choices are self-management territory, but the Definition of Done is a shared Scrum Team commitment about what "Done" genuinely means, and lowering it — even under real deadline pressure — isn't something a subset of the team, or even all the Developers acting alone, gets to do quietly. If automated testing is part of that Definition of Done, dropping it changes the meaning of every Increment produced afterward, which is a bigger and more visible decision than ordinary day-to-day self-management. The first wrong option treats testing approach as unconditionally within Developer authority, ignoring that its status depends on whether it's written into the Definition of Done. The second wrong option mistakes unanimity for legitimacy — the whole Scrum Team, not just the Developers, holds the Definition of Done, and consensus among Developers alone doesn't change that. The fourth option correctly senses a problem but wrongly hands sole approval power to the Product Owner; the Definition of Done is a whole-Scrum-Team artifact, not one accountability's alone to gatekeep. An operational check: before treating a practice change as routine self-management, check whether that practice is named in the Definition of Done — if it is, the change needs to go through the whole Scrum Team, openly, not around deadline pressure.