Saying No, Productively
Why is turning down a request so difficult? There are several reasons. Developers pride themselves on being able to solve problems, to deliver new features and functionality, to fix problems and defects. When they are made aware of a problem, their natural instinct is to fix it, improve it, or invent a new solution.
Additionally, the "cost" of a single disruption can seem minimal; spending a few minutes, or even a few hours, taking care of a stakeholder seems like the right thing to do. The team rarely calculates that a disruption, even one that is exactly related to the task at hand, comes with a switching cost that may be more expensive than the work itself. This leads to a bad combination—the team is naturally inclined to accept the new task, while simultaneously underestimating the cost of doing it.
In many team’s retrospectives, in answer to the question What we can do better next time?, is some variant of getting better at saying ‘no’—declining some requests, or playing defense against churn and disruption. At this point, the team will seek to support each other better, ask their scrum master for help, and maybe start to escalate to their managers in an effort to meet commitments by staying focused and remaining on track. But the problem isn’t that the team doesn’t know what they should be doing
Please log in or sign up below to read the rest of the article.