I will try to illustrate some aspects that have not been addressed by other answers and that, IMO, are important.
The basic issue is this: Some developers are primarily motivated by the joy of taking a piece of difficult work, thinking through a design, thinking through potential issues, then solving the problem piece by piece, with only minimal interaction with others, over an extended period of time. They generally complete work to a high level of quality and in a timely way; their work is maintainable and fits with the overall architecture.
This kind of developers may find it difficult to adapt to an agile environment and their attitude is often dismissed as "unwillingness to change", possibly related to ego or to being old-fashioned.
What is often ignored is that in order to solve complex problems one needs to handle a lot of information, and that this may need a lot of analysis, thinking, trying, sketching a solution, throwing it away, trying another one.
Such a complex problem may require from a few hours to a few weeks of focused work until you have a finished solution.
One approach is that a developer takes the problem specification, goes to her room, and comes back two / three weeks later with a solution. At any time (when needed), the developer can initiate some interaction with other members of the team or with stakeholders (asking questions on specific issues) but most
of the work gets done by the developer who is assigned the task.
What happens in an agile scenario? The team breaks up the problem into small chunks (user stories) after a quick analysis (grooming). The hope is that the user stories are independent from each other but often this is not the case: in order to break up a complex problem into really independent chunks you would need a knowledge that you normally only get after working on it for several days.
In other words, if you are able to break up a complex problem into small independent parts, it means you have basically solved it already and that you only have diligence work left. For a problem that requires, say, three weeks work, this will probably be the case during the second week, not after a couple of hours grooming done at the very beginning of the sprint.
So, after a sprint has been planned, the team works on different chunks of a problem that have probably dependences between each other. This generates a lot of communication overhead trying to integrate different solutions that may be equally good but are, well, different from each other. Basically, the trial-and-error work is distributed over all the team members involved, with an additional communication overhead (increasing quadratically).
I think some of these problems are illustrated very well in this article by Paul Graham, in particular point 7.
Of course, sharing the work between team members reduces the risk related to one team member leaving the project. On the other hand, knowledge about the code can be communicated in other ways, e.g. using code reviews or giving technical presentations to the colleagues. In this respect, I do not think there is a silver bullet valid for all situations: shared code ownership and pair programming are not the only option.
Furthermore, "delivery of working functionality within shorter intervals" results in an interruption of the work flow. This may be OK if the chunk of functionality is "add a cancel button in the login page" that can be completed by the end of a sprint, but when you are working on a complex task you do not want such interruptions: it is like trying to drive a car 100 km as fast as you can and stopping every 5 minutes to check how far you have gotten. This is only going to slow you down.
Of course, having frequent checkpoints is meant to make a project more predictable, but in some cases the interruption can be very frustrating: one can barely gain speed that it is already time to stop and present something.
So, I do not think that the attitude described in the question is related only to ego or resistance to change. It can also be that some developers consider the approach to problem-solving described above more effective because it allows them to have a better understanding of the problems they are solving and of the code they are writing. Forcing such developers to work in a different way can result in cutting down their productivity.
Also, I do not think that having some members of the team work in isolation on specific, difficult problems is against agile values. After all, teams should be self-organizing and use the process that they have found to be the most effective over the years.
Just my 2 cents.
There’s a great story of a manager of a Coca-Cola plant whose numbers were far better than his peers. When asked what his “secret” was, he said simply that rather than take a best practice and modify it to meet what the plant did, he instead modified the plant to match the best practice.You're not doing agile until you understand why youre doing it.