Abstract: The Agile community has many obsessions, some good, some damaging. One of the most hurtful to stakeholder relationships is the propensity to say, “No,” more than, “Yes!” Our community needs to grow up a bit, and we need to put our money where our mouth is when we say we value People over Process.
We say “People over Process”
We all know this is not an either-or statement, as it is not saying process is bad. Instead, it is meant to convey that we value addressing the human system first, and then looking at the process as a secondary measure. Sometimes a process is causing frustration, but we learn about that by talking to the person and understanding the human impact as the starting point.
Why then do we take a different approach with some people than other people? Should we not be addressing the person before the thing that person is trying to do? It is hypocritical of our craft to always look out for the best interests of the team over the stakeholder. I know that may seem like a controversial statement, but let me put it more plainly: The team is at the service of the people who matter in a given project. These are the same people who define what quality is.
If a stakeholder needs help with something we feel might be detrimental to the team, it is our job to explain the possible impacts of those risks. If the stakeholder persists with their desire, then we have escalation techniques we can employ.
If your manager comes back to you and says that this is the priority, then it is no longer our job to keep trying to find ways around it. It is our job to help the team understand the impact, make the work visible, and do the best job possible with the direction we have been given. We may not agree with every decision, but disagreement does not give us permission to become adversarial.
This is where I think many Agile practitioners get confused. We have been taught to empower teams, and rightly so. But empowerment does not mean isolation from the people who fund, sponsor, use, and ultimately depend on the work of that team. It does not mean the team gets to decide that the needs of a stakeholder are unimportant simply because those needs are inconvenient.
People over Process has to include all people. The team matters. The stakeholder matters. The customer matters. If we only use Agile principles to protect one group from another, then we are not serving people over process at all. We are simply choosing which people we value most.
I Must Protect The Team
Some folks look at protection of the team as the most important thing they do. This is noble, and well-intentioned most of the time, but if we think about the word protection, I think about an awning to shield people from the rain, or perhaps a shield to minimize bodily harm.
This protection provides a barrier, a preventative measure in order to reduce the chance of harm coming to someone or something. Protection does not lash out, or go on the offense. This is something some folks feel justified doing, a quid pro quo; however, it only serves to hurt the stakeholder relationship more.
Protecting the team should mean helping them maintain a sustainable pace, ensuring that important work is visible, and helping them understand the decisions being made around them. It should not mean teaching the team that every stakeholder request is a threat, or that saying no is the only way to preserve their autonomy.
A healthy team needs someone who can translate the business need, facilitate hard conversations, and help everyone understand the tradeoffs. Sometimes that person needs to push back on a stakeholder. Sometimes they need to push back on the team. The role is not to take sides. The role is to help people work together toward the right outcome.
The Impact of No
There are certainly times when the answer needs to be ‘No’. Not every request is reasonable. Not every idea is valuable. Not every deadline is possible, and saying ‘no’ when you have data to protect the outcomes and deliverables will actually be respected. The problem is not that we say no; the problem is when no becomes our default posture.
A stakeholder usually does not come to a team with a request just to make their lives harder. They have a problem that matters to them, or they themselves are being asked to do something hard from their own leadership, possibly that they may not even fully understand. They may have a customer issue. They may have seen something that is creating risk for the business. When their first interaction with the team is a quick no, what they hear is, “Your problem does not matter to us.” That may not be what we mean, but it is often what they experience.
Over time, this changes the relationship. The stakeholder stops seeing the team as a partner and starts seeing them as a barrier. Then they begin looking for ways around the team. They escalate. They bring work directly to individual engineers. They hide urgency until the last possible moment because they expect resistance. None of these are healthy outcomes, but they are understandable when someone has learned that asking for help usually leads to rejection.
The most damaging version of no is when we hide behind process: “That is not how the backlog works.” “We cannot change the sprint.” “The team has already committed.” These may all be technically accurate statements many times, but they do not address the actual human need sitting in front of us. Process should help us have better conversations, rather than become a weapon used to win them.
In my experience, most of the time I have found that ‘Yes’ is not only the correct answer, but easily doable with some slight adjustments and flexibility on the part of a few. Sometimes the answer is still no, but there is a major difference between saying, “No, we cannot help you,” and saying, “I understand why this matters. Here is what it would cost, here is what we would need to move, and here are the options available to us.” One shuts down a relationship. The other begins (or strengthens) a partnership.
The Impact of Yes
There are numerous studies that show positive affirmation has a much more powerful influence in humans than negative reinforcement when it comes to relationship building. When taking a new role and being introduced to new stakeholders, I look for commonalities that bind us. I capitalize on those in our discussions, whatever they are related to: work experience, family, hobbies, common interests, etc.
The phrase, “Someone will not value what you have to offer until they value who you are,” comes to mind every time I meet a new business partner. I have to establish some kind of links on a personal level before I can even be called on for service. Once that connection happens, they will then feel able to call on me for help. How I respond to these initial requests locks in a first impression of if they can count on me to be a partner.
The stakeholder will have a need that solves a problem that matters to them. I need to make that problem matter to me. In the same way those commonalities can bond you to someone, being of great help to them can do the same.
Yes does not always mean yes to the exact request as it was presented. It may mean, “Yes, let us understand the problem.” It may mean, “Yes, we can look at the tradeoffs together.” It may mean, “Yes, we can find a smaller solution that helps you now while protecting the larger work.” The point is that the stakeholder leaves the conversation knowing they were heard and that the team is trying to help.
This is especially important early in a relationship. The first few requests a stakeholder brings to a team become the story they tell about that team. If they are met with resistance, process language, and reasons why something cannot be done, then they will learn not to involve the team until they have no other choice. If they are met with curiosity, transparency, and a genuine desire to help, then they will involve the team sooner. That gives everyone a better chance to make good decisions together.
The best teams I have worked with are not teams that say yes to everything. They are teams that make it easy for people to bring them problems. They are teams that can explain risk without making someone feel foolish for asking. They are teams that understand the business need, not just the ticket in front of them.
We should not be known as the people who protect the process from everyone else. We should be known as the people who help the organization solve hard problems. Sometimes that means saying no. But it should almost always begin with, “Yes, let us figure this out together.”
