“If you follow Scrum, you’ll deliver better software”
“If you do TDD, you’ll deliver better software”
Both of those statements may be true, but they’re unhelpful at their core.
For one thing, the person speaking them generally has survivorship bias; it worked for them so it should work for you too, QED.
Besides the bias inherent in that statement, they also tend to ignore that the ample evidence around us that not all teams are successful with scrum, and not all teams are successful with TDD.
But let’s flip that statement around.
Is the process responsible for your success?
the process can fail you, and you can fail. Those are independent variables; and though some processes do tend towards helping teams fall in the pit of success, The process can’t guarantee an outcome, and blind reliance on a process is a sure path towards failure.
The reason why the robots haven’t taken our jobs is that Software Development is, at its core, about turning human desires into an automated and useful system.
It’s that human aspect that we try to create processes to counteract or channel. The human aspect is why we make mistakes when we’re developing code; and why TDD can help. The human aspect is why double-entry bookkeeping is the accepted method for accounting. The human aspect is why software is so darned useful in the first place. It was made for us.
Before you chide a process, or point towards a process for your success, remember that it started with humans. It started with you and your team. You’re the success story, not the process.
P.S., I started a new podcast that is centered around helping software leaders enable their team to build better software. I recently spoke with Ben Mosior about Wardley Mapping, a technique for contexualizing your team, your business, or your software stack to better understand the landscape. It’s hard to think strategically if you can’t model where you’re at, and Wardley Mapping helps with that. Check out the episode here.