Vou tentar ilustrar alguns aspectos que não foram abordados por outras respostas e que, IMO, são importantes.
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.
Esse tipo de desenvolvedores pode achar difícil adaptar-se a um ambiente ágil e sua atitude é freqüentemente descartada como "falta de vontade de mudar", possivelmente relacionada ao ego ou à antiquada.
O que muitas vezes é ignorado é que, para resolver problemas complexos, é preciso lidar com muita informação, e isso pode exigir muita análise, pensar, tentar, esboçar uma solução, jogá-la fora, tentar outra.
Um problema tão complexo pode exigir de algumas horas a algumas semanas de trabalho focado até que você tenha uma solução finalizada.
Uma abordagem é que um desenvolvedor leva a especificação do problema, vai até o quarto dela e volta duas ou três semanas depois com uma solução. A qualquer momento (quando necessário), o desenvolvedor pode iniciar alguma interação com outros membros da equipe ou com partes interessadas (fazendo perguntas sobre questões específicas), mas a maioria
do trabalho é feito pelo desenvolvedor que é atribuído a tarefa.
O que acontece em um cenário ágil? A equipe divide o problema em pequenos pedaços (histórias de usuário) após uma análise rápida (preparação). A esperança é que as histórias dos usuários sejam independentes umas das outras, mas freqüentemente isso não é o caso: para dividir um problema complexo em partes realmente independentes, você precisaria de um conhecimento que normalmente só é obtido depois de trabalhar nele por vários dias.
Em outras palavras, se você é capaz de dividir um problema complexo em pequenas partes independentes, isso significa que você já o resolveu e que você só tem trabalho de diligência. Para um problema que requer, digamos, três semanas de trabalho, este provavelmente será o caso durante a segunda semana, não depois de algumas horas de preparação feitas no início do sprint.
Assim, depois que um sprint foi planejado, a equipe trabalha em diferentes partes de um problema que provavelmente tem dependências entre si. Isso gera muita sobrecarga de comunicação tentando integrar diferentes soluções que podem ser igualmente boas, mas que são diferentes entre si. Basicamente, o trabalho de tentativa e erro é distribuído por todos os membros da equipe envolvidos, com uma sobrecarga de comunicação adicional (aumentando de forma quadrática).
Eu acho que alguns destes problemas são ilustrados muito bem em este artigo por Paul Graham, em particular o ponto 7.
Naturalmente, compartilhar o trabalho entre os membros da equipe reduz o risco relacionado a um membro da equipe deixar o projeto. Por outro lado, o conhecimento sobre o código pode ser comunicado de outras maneiras, e. usando revisões de código ou dando apresentações técnicas aos colegas. A esse respeito, não creio que exista um marcador de prata válido para todas as situações: a propriedade de código compartilhado e a programação em pares não são a única opção.
Além disso, "entrega de funcionalidade de trabalho em intervalos mais curtos" resulta em uma interrupção do fluxo de trabalho. Isso pode ser OK se o pedaço de funcionalidade é "adicionar um botão de cancelamento na página de login" que pode ser concluído até o final de um sprint, mas quando você está trabalhando em uma tarefa complexa você não quer tais interrupções: é como tentando dirigir um carro 100 km o mais rápido possível e parando a cada 5 minutos para verificar até onde você chegou. Isso só vai te atrapalhar.
É claro, ter pontos de verificação freqüentes é feito para tornar um projeto mais previsível, mas em alguns casos a interrupção pode ser muito frustrante: dificilmente se pode ganhar velocidade que já é hora de parar e apresentar algo.
Portanto, não acho que a atitude descrita na pergunta esteja relacionada apenas ao ego ou à resistência à mudança. Também pode ser que alguns desenvolvedores considerem a abordagem da solução de problemas descrita acima como mais eficaz, pois permite que eles entendam melhor os problemas que estão resolvendo e o código que estão escrevendo. Forçar esses desenvolvedores a trabalhar de maneira diferente pode resultar na redução de sua produtividade.
Além disso, não acho que ter alguns membros da equipe trabalhando isoladamente em problemas específicos e difíceis seja contra valores ágeis. Afinal, as equipes devem se auto-organizar e usar o processo que eles descobriram ser o mais eficaz ao longo dos anos.
Apenas meus 2 centavos.