A leader came to me frustrated. Their engineering organization had been struggling for months. Sprints were consistently blowing past forecast. Leadership was asking hard questions. And the loudest complaint was that testing cost too much and took too long.

It was an easy diagnosis to get wrong.

The obvious answer would have been to cut test coverage, hire faster testers, or push the team harder. Instead, I asked to look at the data before we touched anything.

What I found wasn’t a testing problem. It was a systems problem with testing as the symptom.

What the data actually showed

When we mapped sprint cycle times against the number of test cycles a release went through before it shipped, the pattern was clear. Long sprints correlated directly with high test cycle counts across one or more branches of code. The team wasn’t slow because they lacked discipline. They were slow because code was bouncing back and forth repeatedly before anyone was confident enough to ship it.

When we dug into why, two things stood out.

First, the testing coverage was heavily weighted toward the user interface layer. This runs directly counter to the testing pyramid, a well-established framework in software engineering that recommends the bulk of testing happen at the unit and API levels, where tests are fast, cheap, and precise. UI and end-to-end tests sit at the top of the pyramid for a reason: they are slow, fragile, and expensive to maintain. When an organization inverts this and tests everything at the UI layer while skipping the foundation, defects get caught late, after code has already moved downstream, which forces repeated cycles of fix, retest, fix again.

Second, nobody on the testing team had a clear picture of what had actually changed in a given release. Standard testing practice starts with a simple question: what changed, and what is already known to be unstable? That combination of change impact plus risk defines where to focus. Without that lens, the team was testing everything, every release, every feature, regardless of relevance. The scope was impossible to sustain.

And test automation? That was always the next thing. After the rush. After this sprint. It never happened, which meant the manual burden kept compounding release after release.

The part nobody wanted to say out loud

This wasn’t a testing team problem. It was a political and process problem that had calcified over time. Developers weren’t writing unit tests because sprint pressure left no room for it. Testers weren’t pushing back on scope because they feared being blamed if something slipped through. Leadership was measuring output instead of asking what was actually slowing the system down.

Everyone was behaving rationally given their incentives. The result was collectively irrational.

What changed

Once we had a clear picture, the path forward was straightforward. Shift unit testing responsibility upstream to developers as part of the definition of done. Train the testing team to work from a risk-based model: what changed, what is fragile, what actually needs coverage right now. Give them permission to push back on scope. Start building automation deliberately, not someday.

Sprint forecasts got more accurate. Test cycle counts dropped. Testing costs came down. Not because the team worked harder, but because they stopped spending effort on the wrong things.

Why this matters

The reason a diagnostic works is that it creates permission to be honest. Leaders can’t always see what’s stuck inside their own organization. The political dynamics, the unspoken incentives, the workarounds that became process are invisible from the inside.

This is exactly the kind of engagement I do with clients. In thirty days, we identify the real constraint, build the business case for addressing it, and lay out a practical roadmap forward. Not what you want to hear, but what is actually happening.

If your team is consistently missing commitments and you are not sure whether the problem is people, process, or something deeper, that is the conversation to have.

Learn how the diagnostic works.