> If you were to envision programming nirvana would it be mostly test coverage and scrum boards?

Far from it. Indeed I think that TDD is vastly over-used and often harmful and SCRUM is more often development poison than anything else. But the fact that these things are popular despite the frequent difficulty of implementing them correctly is, I think, indicative of two things. First, that there is something of serious and fundamental value there which has caused so many people to latch onto such ideas zealously, even without fully understanding where the value in such ideas comes from. And second, that due to their being distanced from the "practice of programming" they are more subject to misinterpretation and incorrect implementation (this is a hard problem in programming as even the fundamentals of object oriented design aren't immune to such problems even though they tend to be baked into programming languages fairly deeply these days).

I think that unquestionably a routine build/test cycle is a massive aid to development quality. It doesn't just facilitate keeping a shipping product on schedule it has lots of benefits that diffuse out to every aspect of development in an almost fractal fashion. For example, having a robust unit test suite vastly facilitates refactoring, which makes it easier to improve code quality, which makes it easier to maintain and modify code, which makes it easier to add or change features, and so forth. It's a snowball effect. Similarly I think that unquestionably a source control system is a massive aid to development quality and the pace. That shouldn't be a controversial statement today though it would have been a few decades ago. More so I think that unquestionably the branching and merging capabilities of advanced source control systems are a huge aid in producing software.

Development velocity has a lot of secondary and higher order effects that impact everything about the software project. It makes it easier to change directions during development, it lowers the overhead for every individual contributor, and so on. Projects with higher development velocity are more agile, they are able to respond to end-user feedback and test feedback and are more likely to produce a reliable product that represents something the end-users actually want without wasting a lot of developer time along the way.

Some people have tried to formalize such "agile" processes into very specific sets of guidelines but I think for the most part they've failed to do so successfully, and have instead created rules which serve a far too narrow niche of the programming landscape and are also in many cases too vague to be applied reliably. But that doesn't mean that agility or increased development velocity in general are bad ideas, they are almost always hugely advantageous. But they need to be exercised with a great deal of thought and pragmatism.

Also, as to testing, it also suffers from the problem of being too distanced from the task of programming. There are many core problems in testing such as the fact that test code tends to be of lower quality than product code, the problems of untested or conflicting assumptions in test code (who tests the tests?), the difficulty of creating accurate mocks, and so on. These problems can, and should, be addressed but one of the reasons why they've been slow to be addressed is that testing is still seen as something that gets bolted onto a programming language, rather than something that is an integral part of coding.

Anyway, I've rambled too long I think, it's a deep topic, but hopefully I've addressed some of your points.