Recently this statement raised my inner alarms: “We’ve got lots of problems! For example, nobody is pair programming.”
Why would this rub me the wrong way? That nobody is pair programming? After all, I am indeed a huge fan of pairing up. I witness this practice’s many benefits every single day at work. But no, that’s not the point. My alarms went off because “lack of pair programming” was presented as an actual problem. It’s not.
Let me repeat that: As much as I love pair programming, not doing it is not a problem in and of itself. Rather, pair programming is a possible solution to a host of problems an organization might be having such as:
- Low quality / many defects
- A truck factor of one
- Poor onboarding
- Lots of misunderstandings
And depending on the actual underlying problem there are different solutions available, one of which could be pair programming.
Nobody who’s not already a convert will start pair programming just “because”. Instead go looking for the actual problem. Ask “So what?” That phrase is magical and you can use it repeatedly. Just like there’s the Five Whys, dig deeper with five “So what’s”:
“Our problem is that nobody’s pair programming!”
“So what? Why is that a problem?”
“Nobody knows anybody else’s code. It’s 1 system = 1 developer.”
“Whenever a developer is sick or on holiday development in their area comes to a screeching halt. And there’s always someone sick or on holiday. Makes us super slow to release. And I dread the day someone quits.”
“Well, that does seem like a pickle…”
Okay, it weren’t five “So what’s” because I suck at making up examples but you get the point.
This is not specific to agile practices either, though Agile folks have a reputation for dogmatism. Here’s a recent example from the field of web analytics: “We’ve got a huge problem: We can’t do cross-domain tracking.” Soooo …? What are the questions I want answers to and that we can’t answer because we lack this?
I’ve learned “So what?” in the context of Henrik Kniberg’s Cause-Effect-Diagrams and have since used it whenever I suspect that a “problem” someone presents is actually their (preferred) solution. It’s the same as with product features:
“Love the Problem, Not Your Solution”
– Ash Maurya