Changing ways of working is hard - it's why nearly two decades after the publication of the Agile Manifesto we're still talking about it. Yes, you read that correctly; we're getting old. After all, Agile is not a solved problem, it's a framework for stepwise process improvement.

Resistance to process improvements come in many forms. A more insidious form is that of Fear, Uncertainty and Doubt. FUD stops change from getting out the blocks. It can manifest in many ways, but for argument's sake let's use the following example:

In response to a proposed change to a way of working, a team member expresses concern that this will introduce another problem. They refuse to commit to the change until that concern too is addressed. Rinse and repeat.

It is not helpful to dictate changes to process. All team members should buy in to a change. For the skeptical in the group, they may need some convincing. Their FUD is most likely coming from somewhere, such as a prior bad experience. Bringing this team member along means we cannot simply dismiss their contribution to the discussion. Acknowledging their concerns have been recognised is important for psychological safety - raising concerns, however well-founded, requires a level of trust and goodwill. You wouldn't want to recklessly erode that as it will make the future more difficult. Healthy skepticism should be encouraged, as through questioning we can challenge assumptions, refine our understanding and gain clarity on our goals.

So, what can we do?

The proposal to change the ways of working is coming from somewhere - most likely an actual problem the team is currently experiencing. Reiterating that this is the thing that is currently trying to be fixed will refocus the discussion. Problems that may come about as a result of making this change are, at this stage, entirely hypothetical. They may, or may not happen. In reality, we won't know until we've tried it. We can dismiss this as counterfactual, but it's more useful to acknowledge these concerns and the uncertainty around our solutions. This is why we need the ability to experiment! It will take trust on both parts - knowing that the team is invested in improving itself, that we don't have all the answers up front, and we may not get it right on the first try. Never have I seen a magic one-size-fits-all solution that can be applied without negative consequences.

The 'disagree and commit' management philosophy aims to ensure that disagreements are aired. This discourages groupthink, allows teams to consider alternative viewpoints, but ensures that a lack of consensus doesn't lead to inaction. It does ask that when the team makes a decision, all the members align to making a success of it. Critics say this introduces cognitive dissonance, but thankfully that can be alleviated by the agile processes frequent inspect and adapt checkpoints. These let us course correct based on learning. Just as easily as we can start doing something, we can stop. This helps with the buy-in as it's not necessarily for the long term (unless it works).

Software developers will be familiar with Donald Knuth's infamous quote:

Premature optimization is the root of all evil

He was talking about spending too much time in the weeds of small optimizations, instead focusing on the more critical areas. We can generalise this statement further to encompass making decisions ahead of time when we're not fully informed. It's far better, and more efficient, to defer decisions until as late as possible. An additional problem introduced by a change may not have as much impact as the initial problem. Even if it eventually does have more impact, it's still theoretical until it's manifest, so we can't even measure this up front. By trying to solve it in advance and in an uninformed manner, we're essentially gambling on something that might not happen. Wouldn't you rather observe, listen, learn and then decide?

That's the power of agility. The more we do it, the better we get at it. The better we get at it, the more we stop letting FUD cause our teams to rot through inaction. Focus today on the problems you have today. Focus tomorrow on the problems you may have tomorrow.