Processes implemented to save lives are the product of death, and the process is put there to slow things down. Ask your friendly agile consultant how much their process is going to slow down your company.
They will tell you that Agile will make you faster. They might even be right, if it's replacing a bigger, worse process that already exists on top of the process of software development. But if it's adding a layer, it's going to slow you down and get in your way.
Any professional has some process, explicit or implicit: it's the observable regularities in the way they work.
Any team is going to have some explicit process, because there's no way people will converge on the maximally effective way of working together without some discussion.
So as far as I can tell, what you're saying is that it's impossible to take any process ideas from an external source, because every team is already maximally efficient. That doesn't make much sense to me.
In our case, the process we've converged on is the most efficient one we can find. But we're always looking for ways to make it more efficient.
So as far as I can tell, what you're saying is that it's impossible to take any process ideas from an external source, because every team is already maximally efficient.
Nope. I'm saying that the process of programming is what we should focus on getting better at. We should take improvements from wherever we can find them. Getting better at the process of Agile or Waterfall or Scrum or XP or Kanban or whatever else is dreamed up is tangential to our progress as programmers.
I agree that nobody should focus solely on getting better at, say, Agile. I also agree we should work hard at getting better at programming.
However, I don't think that focusing on programming alone is sufficient. A lot of projects fail for reasons other than bad coding, and almost no project exists where programming is the end purpose. You can do all kinds of great programming, but if you make the wrong thing, you're screwed. Ditto if you have a bunch of individuals doing great programming that doesn't add up to a functioning project.
I also think you're creating a bit of a false dichotomy. When I first tried XP, it wasn't for the sake of doing XP. It was because I wanted to improve how we made things for our users. So exploring XP wasn't tangential to better programming; for me it was closely related, in that programming was a big part of making.
They will tell you that Agile will make you faster. They might even be right, if it's replacing a bigger, worse process that already exists on top of the process of software development. But if it's adding a layer, it's going to slow you down and get in your way.