Slow down in scrum
Agile teams are largely unaware of the benefits of not advancing an activity. I recently asked a team I was coaching to imagine the slowest possible way they could fix a high-priority defect. While the initial response was one of bewilderment, what emerged was actually a higher-quality process than the one that the team was currently following. This team went on to formally publicise their slow version as what would constitute a “good defect fix”, a process that included test automation, code review, and refactoring of legacy code. They were genuinely amazed at how much their defect-fixing process improved as a result of having explicit permission to consider a slower fix rather than a quicker one.