Look at sports... I've seen both cases, players that are good within one system horribly underperforming in others, and players that don't look that great meshing with other castouts and creating a surprisingly good team.

I suspect the same can happen with software developers.

Of course, there are people that will be bad anywhere and top guys that will be great anywhere.

Then it would be good to figure that out, measure that, and then at least we can put the best people on the most important projects. It's perfectly possible to imagine a world where e.g. developer IQ was the only thing that mattered and the quality of software that got produced was simply proportional to the average IQ of the developers who worked on it, sure.

I don't think that's the world we live in though. I've seen smart, sociable, effective developers fail in misorganised teams, and I've seen teams of ordinary people produce very good software by getting their processes right.

How do you know they are coming from "good" teams? And if so, isn't it reasonable to suppose that they might carry over good practices in their new environment?

I don't doubt that there are bad developers---I've definitely encountered them. But software development is a team sport, and it makes no more sense to just "recruit good people and leave them alone" in software than it would to do the same in basketball. Great teams have both talented people and winning strategy.

Because people regularly do "recruit good people and leave them alone". At my first job I was the only developer working on the project and I rarely spoke with my boss. He came back from a month long vacation and I had not noticed he was gone.

That's surprisingly common across the field. Most developers work on small teams doing small but often very long lived projects. Code staying in production for 30 years is surprisingly common outside of SV.

Those people, in those positions, probably don't need much in the way of process. If you really can just sit down with the owner of the business, hash things out with them, and then go build something that does what they need then you're golden. And guess what, you're probably doing agile without even knowing it, because agile is attempting to reproduce that in organisations where you can't just put a single developer and a the CEO in a room and expect that to happen.

They also regularly "recruit good people and leave them alone" and they fail. And then we look on those people as "bad" people. Which was my original point above.

I wrote more in my sibling comment. I generally agree that there aren't any strict guidelines for becoming a good team, but I disagree that replacing most of the team is the solution in any but the most extreme cases. I would venture a guess that, most of the time, there's one person to remove and one person to add: a new leader. If that doesn't solve the problem, potentially looking at developer contributions and seeing if there's someone who isn't pulling their weight and has no interest in learning how to. (I've only encountered these types of people a handful of times in my career. Most of the time it was shoddy leadership)