May 23, 2024

How To Learn From a Disagreement About Agile - Mike Cohn

5 minutes

A reply I got recently to one of these weekly email tips began with, “Mike, you’re wrong.” The reply then went on to summarize that person’s experience and how it led to his conclusion that I’m wrong.
But I wasn’t wrong.
And neither was he.
Whenever I disagree with someone, I try to begin from the perspective that we are both right. (Except in the case of whether Han shot first. He did.)
If you and I disagree and begin with the assumption that we are both right, we’re going to have a better conversation. Instead of each trying to persuade the other that we’re right, we instead try to figure out why we view something differently.
Putting this in an agile context, our different opinions have been formed by the projects and teams we’ve worked with. Since our experiences were different, the conclusions we draw and opinions we form can be different.
As an example, suppose two people are arguing about how much upfront design should be done on agile projects. Their different opinions could arise from one having experience building very simple websites and the other having experience developing large systems in highly regulated domains.
As another example, I have a different opinion than those advocating “No Estimates.” But rather than thinking they’re wrong, I want to understand how their and my experiences could have led us to different opinions.
Maybe we’ve worked on projects of different sizes. Or we worked with companies with different cultures and attitudes toward planning. Or we were required to make more or fewer commitments to customers, marketing, or external stakeholders such as public or private investors.
When people disagree, I don’t find it very useful to engage in a bare-knuckle brawl to determine who is right. That’s often fruitless, frustrating, and just leads to more entrenched thinking on both sides.
Figuring out why we may disagree is much more productive, and a surer way to succeed with agile.