My friend Joep Schuurkes wrote a great response to my chapter in Taking Testing Seriously last year, but thanks to LinkedIn’s fantastic algorithm, it didn’t come into my feed and I only saw it when someone sent it to me via email – about a week ago!

His review focuses on the line where I said modern delivery seems obsessed with “continuous everything” except continuous thinking.

“So much today is about “continuous everything” – continuous deployment, continuous integration – and speed. The pace at which people are doing things is really, really disruptive to thinking deeply about problems. Then the goal gets displaced from getting good products and services to customers quickly, and turns into, “How do we back something out quickly when we inevitably screw up?” It’s continuous everything – except continuous thinking.” – Taking Testing Seriously

Being able to deploy as safely as possible should be a business decision, and being able to get that information quickly and respond is very valuable.

And I also agree with Joep that risk appetite matters and changes/adapts to your project and business context. A startup changing website copy is not doing the same job as a bank changing their payments infrastructure.

So yes, technical capability should not determine release cadence. Risk should.

But here’s where I disagree with Joep about how continuous integration/delivery/deployment is positioned or delivered by the Agile industrial complex.

The continuous integration and deployment folks do a little more than “imply speed”, and that has a direct result in how it’s implemented.

In the purest textbook version, CI/CD might be about reducing delivery risk, but that’s not how it’s sold. It’s sold as “faster time to market,” “code releases happen faster,” “ship better quality code faster,” “run pipelines in minutes, not hours,” and “get code to production faster.”

And in my experience, that is exactly how I’ve encountered it in the wild.

In enterprise tech, that gets translated into velocity targets, throughput measurement, increased deployment frequency, dopamine dashboards, and pressure to ship if everything’s green.

That’s what I’m talking about.

As well, CI/CD evangelists just like XP bros or most agilistas, seem to love gaslighting people trying to use this stuff with the same “my process isn’t broken, you’re just doing it wrong”, which only makes cutting corners more likely.

So the best version of “continuous anything” may be sensible, but the common version I see teams struggling to implement (or living with the consequences of test automation elevated to a quality strategy) has the business (and testers) losing the time and agency required to think – continually.

Anyway, thanks for the feedback Joep!