Recently I presented  “The Art Of Saying No” to the Chicago Quality Assurance Association.  The material was a synthesis of work published on the Software Process and Measurement blog, wisdom from the podcast interviews, and hard-won experience. As one of the exercises in the workshop, I asked the participants to identify the reasons they found it difficult or impossible to say no in their business environment. Three reasons that elicited passionate debate were:

The first is a history of performance. The fact that you have said yes to similar requests in the past sets expectations that you will accede to the request now.  First, every individual request is a unique event. Different contexts require different answers. That said, precedence sets powerful expectations that are hard to shift without effort and potential consequences. Techniques such as Socratic questioning coupled with probing using specific clean language questions (clean language helps to define metaphors) are useful to help the person asking to understand that the context has changed and that answer might not be the same. Even if you can’t shift the context, it is important to recognize that not controlling your work intake puts the team at risk. Another approach to this scenario is to explore whether a subset of the work (akin to a minimum marketable product) can be accepted with less disruption.

The second reason was “We are required to drop everything and tackle significant security holes when they are discovered.”  The person making the statement was not saying how dare we be required to tackle problems, but rather how can a team anticipate the impact of having to deal with defects. The first response is that testing, including testing against security requirements, needs to be incorporated into the definition of done AND work that does not meet the definition of done should not be promoted to production. If an occasional severe defect pops up, the team will need to flex to deal with the issue — understanding that there are consequences for other work.  If defects popping up is a chronic problem (in this case it was), consider creating a second team that specifically tackles production issues. Another approach is to carve out periodic sprints to work on reducing technical debt that is causing problem tickets. One approach that I rarely recommend is setting aside capacity for defects — set aside capacity will almost always be used before problem tickets emerge, causing dislocations when they emerge.

The third problem that caused a participant to have difficulty saying no happened due to a very large client demanding changes and adding new functionality even during a sprint and that the sales team says yes without any technical input.  One of the implicit promises in Scrum is that a product backlog is dynamic until a team draws work into a sprint. While the story can and should be tuned, wholesale changes, deletion, and additions to the sprint backlog are inappropriate. Violation of this basic agreement means that a team will not be able to deliver predictably.  Two approaches present themselves to help control work entry. The first is to shorten the sprint length to a week. That way the team can say no until the next sprint without causing significant concerns. Second, large client sales teams should include a sales engineer (someone with current technical knowledge) so that work that is sold is feasible and the sales team understands the implications of promised timing.

Saying no is not an easy matter.  Saying no starts with listening and probing for information,  It might require negotiating but in the end, it is going to require saying no to something.  

I would be happy to do the Art of Saying No workshop for you, if interested drop me a note at