How to Say Yes and No
I’ve been an agile coach for 10+ years. Before that I led teams as a product owner or principal UX consultant for 15 years. Whether I’m coaching or leading teams, one of the biggest challenges is always how to say “No.” Sound familiar?
It’s inevitable. Whether agile teams or not, whether Scrum or not, whether teams or individual contributors, someone will always show up with a “small request” or “just one more thing” or my personal favorite, “Can you do me a favor?”
Ideally, if we all worked in psychologically safe, collaborative environments, then the answer to these injections of work could easily be deferred to a more appropriate time in the future.
The truth is, of course, we don’t, and these requests are almost always answered with some form of “Ok, we’ll fit it in” even if we know that fitting it in just isn’t possible. But why?
Coercion Not Collaboration
The reason is simple: rank and privilege.
These requests for injected work don’t come from peers or teammates. They come from managers, directors, VPs, or others with title and authority. No matter how teal an organization is, most people aren’t going to say no to higher ranked coworkers when they ask for a favor. It just ain’t gonna happen. Psychological safety all but disappears when power dynamics enter the picture.
Whether they intend to or not, the people making these requests are using their rank and privilege coercively to forward their own agenda. They weren’t in the planning or scoping meetings. They didn’t contribute their needs early. They don’t know the potential negative impact of their requests.
Unfortunately, even the most caring and empathetic of them don’t care about the impact. If they did, they would’ve gone through the proper, collaborative channels to get their request into the workflow. They know they have a personal agenda item, and they know they have enough authority to make the request, so they do.
I understand that I’ve made some generalizations in this scenario, and that not everyone with rank and privilege behaves this way, but neither am I suggesting that their behavior is intentionally nefarious. The lack of safety and collaboration that prevents teams from saying no is the same as that which created the request in the first place. Someone above the requestor most likely asked them for a favor or even gave them an offer they couldn’t refuse a la Don Corleone.
Just Say No
After years of preaching the gospel of learning how to say no, I’ve realized that the advice is as useful as former First Lady Nancy Reagan’s famous 80s catchphrase against kids using drugs, “Just Say No.”
It’s never that easy.
If it were, I believe that agile coaches would be out of a job overnight. The premier party foul of most organizations is having too much Work In Progress (WIP). The majority of antipatterns and bad practices in organizations are caused by working on too many things at once. There is so much WIP that critically examining its impacts simply isn’t possible.
To make matters worse, high WIP is inversely proportional to a work culture that permits saying no. That is the higher the WIP the lower the permissibility of saying no.
Ok, if exercising the Power of No isn’t possible, then how do we combat too much WIP and injected work? If no isn’t possible, then what is?
Let me introduce the concepts of Qualified Yeses and Negotiated Noes.
Qualified Yeses
Even if your organization fully enables saying no, I highly recommend adopting the practice of Qualified Yeses. A Qualified Yes is saying yes and then defining how and when the work will happen.
It’s not a blank check yes that might suggest completing the work as soon as possible regardless of what else it may impact. It’s a thoughtful yes that recognizes that requests have impacts and makes those impacts known along with a timeframe in which the request will be fulfilled.
In fact, it’s such a powerful tool that it’s relevant to all commitments, not just injected work.
Think of them as another aspect of Definitions of Done and Acceptance Criteria. This is how we will honor the request/commitment. This is when we will honor it. This is how you and we will know when it’s done.
Qualified Yeses define the terms under which the work will be done. They provide clarity and enable collaboration through the conversations they create.
Not a “yes, but …” but a “yes, and …” (A topic that deserves its own post. Stay tuned!)
And if used wisely, Qualified Yeses can enable Negotiated Noes.
Negotiated Noes
When teams learn how to say yes without upsetting the apple cart and stakeholders know what they’re getting and when they’re getting it, the possibility of saying no becomes more plausible.
This happens because of the conversations and collaborations required for Qualified Yeses. When teams learn how to say yes and provide qualifiers for when/how the work will be delivered, those same conversations can start to include negotiations of not only the work to be done now, but also the work to be done later.
That’s where Negotiated Noes come in to play. Negotiated Noes simply state, “We can’t do this right now, but here is how/when we can.” They can be used in prioritizing. They can be used in mitigating risk. They can be used to collaboratively reduce WIP. They can be used when not enough is known about a potential solution. They can, and should, be used anytime there is a valid reason to not work on something right now.
Just like Qualified Yeses aren’t a blank check, Negotiated Noes don’t give teams permission to say no to everything that comes their way. Negotiated Noes are about teams controlling the flow of work and having the space to investigate solutions and maintain the necessary slack in the system to prepare for the unexpected. They are also about satisfying stakeholder demands … just not right now.
If you and your teams are struggling to keep injected work out of your workflow, Qualified Yeses and Negotiated Noes might help in maintaining sanity and creating better, healthier relationships with stakeholders.
More Reading
How Successful Teams Limit Work in Progress - Members-only content for Scrum Alliance certificants
