Estou surpreso que todos pensem que isso é uma coisa tão boa. Os autores do Peopleware (que, na OMI, ainda é um dos poucos preciosos livros de gerenciamento de projetos de software que realmente valem a pena ler) discordam totalmente. Quase toda a parte IV do livro é dedicada a essa mesma questão.
A equipe de software é uma unidade funcional incrivelmente importante. As equipes precisam gelificar para se tornar realmente produtivas. Leva tempo ( muito tempo) para os membros da equipe ganharem o respeito uns dos outros, aprenderem os hábitos e peculiaridades, pontos fortes e fracos.
Certamente, por experiência pessoal, posso dizer que, depois de um ano trabalhando com certas pessoas, aprendi a rir de certas coisas que costumavam me irritar, minhas estimativas como líder de equipe são muito melhores e não é muito difícil. distribuir o trabalho para fazer todos felizes. Não era assim no começo.
Agora você pode dizer: "Ah, mas não estamos dividindo a equipe inteira, apenas movendo algumas pessoas". Mas considere (a) quão cegamente improdutivas serão as substituições deles no começo e (b) quantas vezes você se encontrará ou outras equipes dizendo, sem nem pensar: "Eu realmente gostei de X" ou "Isso teria foi mais fácil com Y ainda por perto " , ofendendo sutil e inconscientemente os novos membros e criando cismas dentro da equipe existente, até semeando descontentamento entre os membros" antigos ".
As pessoas não fazem isso de propósito , é claro, mas isso acontece quase sempre. As pessoas fazem isso sem pensar. E se eles se forçam a não fazê-lo, acabam se concentrando ainda mais na questão e ficam frustrados com o silêncio forçado. Equipes e até sub-equipes desenvolverão sinergias que se perdem quando você mexe com a estrutura. Os autores da Peopleware chamam isso de uma forma de "teamicide".
Dito isto, mesmo que os membros da equipe rotativa sejam uma prática horrível, a equipe rotativa é perfeitamente adequada. Embora as empresas de software bem administradas devam ter algum conceito de propriedade do produto, não é tão perturbador para uma equipe mover toda a equipe para um projeto diferente, desde que a equipe realmente termine o projeto antigo ou, pelo menos, um nível que eles estão felizes.
Ao ter períodos de equipe em vez de de desenvolvedor , você obtém todos os mesmos benefícios que você esperaria obter com desenvolvedores rotativos (documentação, "polinização cruzada" etc.) sem nenhum dos efeitos colaterais desagradáveis em cada equipe como uma unidade. Para quem realmente não entende de gerenciamento, pode parecer menos produtivo, mas tenha certeza de que a produtividade perdida ao dividir a equipe diminui totalmente a produtividade perdida ao mudar a equipe para um projeto diferente.
PS Na nota de rodapé, você menciona que o líder técnico pode ser a única pessoa a não ser rotacionada. Isso é garantido para atrapalhar as duas equipes. O líder técnico é um líder, não um gerente, ele ou ela tem que ganhar o respeito da equipe e não é simplesmente concedido autoridade por níveis mais altos de gerenciamento. Colocar uma equipe inteira sob a direção de um novo líder, com quem eles nunca trabalharam e que provavelmente têm idéias diferentes sobre coisas como arquitetura, usabilidade, organização do código, estimativa ... bem, será estressante como o inferno para o líder tentando construir credibilidade e muito improdutivo para os membros da equipe que começam a perder coesão na ausência de seu antigo líder. Às vezes as empresas têmfazer isso, ou seja, se o lead sair ou for promovido, mas fazê-lo por escolha parece insano.