It's actually very interesting that you had automated tests - of course I can see it working, but it must have been quite a bit of effort to make them, keep them updated in the face of new code changes, and so forth. Impressive given the tools available at the time, for sure, and just as impressive that Carl signed off on all these things under (presumably) pressure to keep time and costs down. He really does sound like a fantastic leader to work for (and a good company, as well, to give him so much room to manage the team in the way he saw fit). I don't know that that makes a team 'agile' per se - but whatever it was, it was evidently good. (It may just be quibbling over definitions a bit there, anyway.)
I can't say I have ever worked for any *bad* leaders, but I also find that most leaders today don't really... 'engage' with devs as much as they should, in terms of finding out what their devs thinks the team could be doing better, or checking in about specific things for reasons other than checking deadlines. I don't think it was because they didn't care or didn't want to per se, but more that they simply had far too much work already and didn't have the time to think about it - if it isn't quantifiable it will get very little priority in the current workplace, though that's not exactly a new problem. The few times meetings occurred for feedback purposes, almost anything that wasn't an instant quick fix would be dismissed as too costly. (I spent several months lobbying our team lead endlessly to switch our project management to JIRA, as we were using a client-visible system designed for business analysts to track code tickets... how that ever came about to begin with, I have no idea. Got it eventually though.)
One thing that has *definitely* contributed to a lack of developer productivity is open plan offices... hearing you talk about developers having private offices practically sounds like an alternate universe, it's that luxurious. It's been a long time since that was something developers got as far as I know, and with video calling being prevalent now, even devs working from home don't have that kind of quiet space anymore (though working from home is definitely a vast improvement, imo - and attitudes on how that's managed are certainly changing). It's a shame in many ways - there are so many benefits to even small private offices for developers and companies.
There's something in your article/writing on it here I don't quite understand: why would implementing language features from a backlog make a team agile? Presumably, no matter how the project was managed, you would have a list of features to implement; what's different about this? Or was each item on the backlog relatively well defined, as opposed to being a literal list of features?