I definitely agree with alot of your points. I guess what I meant to say was that for alot of organizations it seems to be useless paradigm gibberish. For our

I definitely agree with alot of your points. I guess what I meant to say was that for alot of organizations it seems to be useless paradigm gibberish. For our organization it doesn't seem to be, and my purely unscientific observation would be that getting devs on board is more about tools and channeling them through a process. That, you can get someone through pretty quick because its primarily logistics based. We have tickets that are tied to pull requests you have to submit your PRs for test tickets before you can submit your PRs for feature tickets we have a CI server that will run those PR's against the tests at which point we merge everything. This makes it pretty straight forward how development has to get done. Where as, getting people who aren't code driven on-board requires complex paradigm adoption about how we design projects and road-map the business. Some of these people end up at these types of trainings because they are the people who need the indoctrination the most. Developers we have faced have a tendency to either just sort of shrug and go "ok" or to want to totally fight the system and tear it down and replace it with X. We do our best to weed the violent opposition types by using test writing as examples during interviews the violent opposition types usually get visibly frustrated by the "test then code" approach of TDD so we haven't had to much trouble identifying people like this. The long and short would be: I think that the thesis of the OP that lack of dev's is a problem can be rejected because engineering unit employees don't face the same hill climb to adoption that business unit employees do and that this has been enabled by the fact that: developers have at this point written them selves tools to automate their own side of the paradigm... i.e Jira Github and so on