Involvement during requirements

Let’s get this out of the way: I have a real issue with the term “shift left.”

“Jeremy, why the strong feelings? Isn’t shift left the latest and greatest thing to make software development smoother?”

It’s not the concept I dislike—it’s the buzzword status and the way we’re glorifying what is, at its core, an old idea dressed up in new packaging.

Don’t get me wrong: the principle behind shift left is solid. There’s plenty of research showing that the earlier a team gets involved in a project, the better the execution. Whether you’re building a house or launching a new software product, it just makes sense to bring everyone in early.

And it doesn’t matter what methodology you use—Waterfall, iterative, Agile, DevOps, whatever. The truth is, QA should always be involved from the start. They don’t need to dictate requirements (that’s a whole other blog post), but they should ask for details and clarifications upfront. This not only preps the testing effort but also helps developers get clear direction and ensures the whole team is aligned.

But here’s the catch: early involvement isn’t a magic fix. It’s just one tool in the toolbox. To truly deliver faster and higher-quality products, you need to integrate early QA with automation, effective stakeholder management, robust governance, and more.

Perhaps in my next blog, I’ll delve deeper into my thoughts on why we continue to repackage old methods instead of refining what works.

On another note, I’m genuinely grateful for the surge in blog visitors this year. When I started this a few years back, consistency was a challenge—until I became a regular guest on the SPaMcast podcast. It’s been a fantastic year, and I’m excited to be gathering material for my upcoming book.

If there’s a topic you want to hear my take on, let me know—I’d love to hear from you!