Como podemos tornar o ágil agradável para desenvolvedores que gostam de possuir pessoalmente, de forma independente, grandes blocos do início ao fim

Estamos a meio caminho de nossa transição de cascata para ágil usando scrum; mudamos de grandes equipes em silos de tecnologia / disciplina para equipes multifuncionais menores.

Como esperado, a mudança para o ágil não se adequa a todos. Existem alguns desenvolvedores que estão tendo dificuldades para se adaptar ao agile. Eu realmente quero mantê-los engajados e desafiados e, finalmente, gostando de vir trabalhar todos os dias. São pessoas inteligentes, felizes e motivadas que respeito tanto no nível pessoal quanto no profissional.

A questão básica é a seguinte: alguns desenvolvedores são motivados principalmente pela alegria de realizar um trabalho difícil, pensando em um design, pensando em possíveis problemas e, em seguida, resolvendo o problema, peça por peça, com apenas uma interação mínima com os outros, por um longo período. período de tempo. Eles geralmente concluem o trabalho com um alto nível de qualidade e em tempo hábil; seu trabalho é sustentável e se ajusta à arquitetura geral. Fazendo a transição para uma equipe multifuncional que valoriza a interação e a responsabilidade compartilhada pelo trabalho e a entrega da funcionalidade de trabalho em intervalos mais curtos, as equipes evoluem de modo que toda a equipe elimine esse problema difícil. Muitas pessoas acham que isso é uma mudança positiva; alguém que adora enfrentar um problema e enfrentá-lo de maneira independente do início ao fim perde a oportunidade de trabalhar dessa maneira.

Este não é um problema com as pessoas abertas a mudanças. Certamente já vimos algumas pessoas que não gostam de mudanças, mas nos casos em que me preocupo, os indivíduos são bons desempenhos, genuinamente abertos à mudança, fazem um esforço, vêem como o restante da equipe está. mudando e eles querem se encaixar. Não é o caso de alguém ser difícil ou obstrucionista, ou querer acumular o trabalho mais suculento. Eles simplesmente não encontram alegria no trabalho como costumavam.

Tenho certeza de que não podemos ser o único lugar que não esbarrou nisso. Como os outros abordaram isso? Se você é um desenvolvedor motivado por possuir pessoalmente uma grande parte do trabalho de ponta a ponta e se adaptou a uma maneira diferente de trabalhar, o que fez para você?

Eu direi que existem muito poucas lojas de software que têm a sorte de ter a rara distinção em que o Agile realmente não faz sentido como metodologia. Se toda a sua equipe é formada por desenvolvedores de software verdadeiramente excepcionais, com um profundo entendimento dos aspectos dos negócios e da longevidade da empresa e entre si, e se os requisitos de negócios e as necessidades dos clientes são sempre sempre semelhantes e raramente sujeitos a alterações no meio de um processo. liberação, você tem a sorte de trabalhar em um ambiente tão raro, onde o Agile provavelmente pode realmente se machucar.

Ele foi projetado para ser a abordagem mais eficaz em meio a requisitos de negócios caóticos e em constante mudança e necessidades dos clientes, evoluindo ou alterando os recursos do projeto e prazos apertados ou variáveis. Esse ambiente significa certa desgraça para o desenvolvimento típico de cascata, pois é vulnerável a mudanças de equipe no meio do projeto, vulnerável a mudanças de requisitos e extremamente vulnerável a uma data de mudança.

Sinto por seus valiosos membros da equipe que não encontram mais alegria em seu trabalho. Eles podem muito bem ser pessoas excepcionalmente talentosas que se envolvem em seu trabalho, mas no final, vários fatores fora do seu melhor controle ainda podem matar o projeto. A melhor maneira de abordar o desenvolvimento de recursos é perder a atitude e a expressão individual e pensar em termos da abordagem de equipe.

Se você achar que isso não funcionará para eles, poderá encontrar um uso especial para eles. Se eles são excepcionalmente talentosos e experientes, veja se eles estariam interessados ​​em uma função arquitetônica, apresentando projetos de alto nível, abordagens, experimentando novas tecnologias e desenvolvendo as melhores práticas. Faça com que essas pessoas controlem e revisem a documentação do projeto.

Se isso ainda não lhes convém, talvez eles trabalhem separadamente em refatorações técnicas extremamente complexas em um ramo separado, protótipos e provas de conceitos extremamente envolvidos ou outro trabalho pioneiro que às vezes precisa ser feito, mas não se encaixa bem no escopo de um único projeto ou release.

Eles simplesmente não encontram alegria no trabalho como costumavam.

Corrigir.

Esse é um grande sintoma de que você está fazendo errado.

O Agile não deve impor uma nova ordem ruim às pessoas.

O Agile deve permitir que a equipe se organize de maneira a torná-la mais eficaz.

Auto-organização significa que o gerenciamento não impõe regras estranhas. Não impõe horários ruins e não impõe interação desnecessária.

Alguns desenvolvedores são motivados principalmente pela alegria de realizar um trabalho difícil, pensar em um design, pensar em possíveis problemas e depois resolver o problema, peça por peça, com apenas uma interação mínima com os outros, por um longo período de tempo.

Por que eles não podem continuar fazendo isso?

Por que mudá-los?

Por favor, leia o Manifesto Ágil algumas vezes.

O Manifesto Ágil diz

Indivíduos e interações sobre processos e ferramentas

Não diz que força as pessoas a trabalharem de uma maneira desconfortável e improdutiva.

Se você está forçando as pessoas a ter muita "interação" de baixo valor, você foi longe demais.

software que trabalha sobre uma documentação completa.

Eles estão fazendo isso? Então deixe-os em paz.

Colaboração do cliente sobre negociação de contrato.

Você já está fazendo isso? Então não mude.

Respondendo a mudanças após seguir um plano.

Onde essas pessoas já são capazes de responder à mudança? Nesse caso, eles já eram ágeis. Eles não precisavam mudar.

minha empresa tentou (e ainda tenta, depois de anos tentando) fazer a mesma transição e, até agora, pessoalmente, não tive muito sucesso com ela. Durante essa transição, li bastante sobre desenvolvimento ágil e diferentes maneiras / aspectos / preocupações / técnicas, e uma coisa com a qual concordo plenamente é que o desenvolvimento ágil puro é mais adequado quando toda a equipe é composta por pessoas sênior e de alta qualidade (ou pelo menos todas as pessoas do mesmo nível).

Na última versão, eu estava em uma equipe "ágil" que tinha IMHO muitos desenvolvedores com níveis de habilidade em todo o lugar e tentamos envolver todos no mesmo projeto. Foi um desastre. Conversamos / discutimos mais do que trabalho e, no final, o que a equipe produziu foi um trabalho comum (leia Peopleware ou Mythical Man Month sobre como obter média). Esqueça os padrões de design, esqueça o baixo acoplamento ou a quebra de código em pequenas classes e métodos. Esqueça de tentar tornar qualquer coisa interessante porque a) que não podia ser explicado e compreendido por todos os membros da equipe (pelo menos não de maneira oportuna) eb) já que éramos ágeis, qualquer que fosse o início da iteração, alguém com absolutamente nenhuma compreensão continuaria na próxima iteração. Pessoalmente,

Eu odiava absolutamente o fato de não poder fazer nada com modelos C ++ ou escrever algumas bibliotecas de estrutura de baixo nível interessantes (mas um tanto complexas) que tornariam nossas vidas muito mais fáceis. Como algo assim pode ser feito quando ninguém mais na equipe é capaz de ler os arquivos de cabeçalho da STL, mas todos devemos trabalhar em uma coisa de cada vez. O projeto inteiro acabou sendo brutalmente forçado, recurso a recurso, porque é isso que o ágil parece enfatizar.

Ao mesmo tempo, há poucas (muito poucas) pessoas na minha empresa com as quais eu adoraria trabalhar lado a lado e compartilhar todo o meu código.

Mas agora você enfrenta uma escolha. R) Pegue todos os seus bons desenvolvedores seniores que produzem código de alta qualidade e os coloque em sua própria equipe e coloque o restante em uma equipe separada. Ou B) tente equilibrar as equipes e colocar as boas com as não tão boas. Em (A), o problema é que uma de suas equipes terá um desempenho abaixo do esperado e não captará boas habilidades / hábitos dos mocinhos. Em (B), seus mocinhos (em ambiente ágil puro) se sentirão frustrados e começarão a trabalhar em seus currículos. O meu está atualizado.

Então, o que você deve fazer?

Não sei se esta é a solução certa. Pergunte-me novamente em mais ou menos um ano. Mas e se, em vez de "puro ágil", você formou uma equipe, mas identificou claramente quais pessoas têm mais influência (design, revisões de código ...) e certifique-se de que essa pessoa entenda isso e seja recompensada por responsabilidades extras. À medida que os membros da equipe começam a trabalhar juntos, identifique aqueles que estão adotando bons hábitos / práticas e eleve-os ao mesmo nível que o seu bom pessoal. Esperançosamente, à medida que as pessoas passam uma versão ou duas trabalhando juntas, elas aprendem o que a outra pessoa pensa e como trabalham, para que sejam mais compatíveis para trabalhar no mesmo código ao mesmo tempo. Mas até que isso aconteça, se você simplesmente lançar as pessoas para um projeto, será apenas frustração (novamente, apenas minha opinião).

Alguns dos meus pensamentos são baseados em como eu comecei profissionalmente em software. Quando eu era cooperativo, trabalhei com um cara que era meu mentor. Ele me ensinou tudo, desde a ética em codificação ao bom design até a leitura de milhares e milhares de linhas de código que você não escreveu. No começo, não estávamos nem perto do mesmo nível e seria ridículo se fôssemos colocados em uma equipe ágil e dissessem que podemos trabalhar no código um do outro. Mas com o tempo (alguns anos), começamos a pensar muito parecidos. Eu pude entender seu código com um simples olhar e ele me disse várias vezes que não tinha absolutamente nenhum problema (e ficou surpreso com isso) ao navegar pelo meu código que ele nunca viu antes. Isso levou anos, não algo que aconteceu durante a noite. Depois de experimentar desastre após desastre em ambiente ágil nos últimos anos,

Esta não é realmente uma resposta, mas resume minha experiência / observações. Eu quero ver o que os outros diriam sobre isso.

O que é Agile?

É isso:

• um conjunto de regras que você deve seguir para alcançar o que os criadores de regras pretendiam?

• uma abordagem de melhor palpite para fazer as coisas de acordo com seus pontos fortes, requisitos e limitações?

Se você acha que o Agile é o primeiro, e sempre segue todas as regras do Scrum e se preocupa constantemente se está fazendo certo ou não, talvez esse link o esclareça um pouco.

Se você acha que é mais sobre o segundo, parabéns - você 'fica' Agile. Qualquer metodologia Agile pode ser apenas uma sugestão de como fazer as coisas. Se algum aspecto do método ágil escolhido não lhe parecer adequado, você deverá parar de usá-lo, alterá-lo ou ser ágilsobre isso. O importante é que você consiga algo, que não seja impedido por restrições artificiais - não apenas aquelas que todos conhecemos e amamos em nossos velhos dias de cachoeira, onde o PM o incomodaria por diagramas documentados completos que ninguém jamais faria leia apenas porque "é isso que o processo diz para fazer", mas também pelas restrições do que você está usando. Se um scrum diário parecer uma restrição, então não os pisque! Tê-los cegamente porque as regras o dizem não é mais ágil do que nos velhos tempos.

Agora, se você tem alguns caras que fazem as coisas sendo trancados em uma sala com apenas um galão de cola e uma escotilha para pizza, utilize esse fato. Dê a eles uma parte do sistema que seja praticamente independente e bloqueie-os. Quando eles terminarem, você deverá fazer com que eles integrem esse trabalho (ou que outra pessoa faça isso, se preferir) com o restante do sistema.

Alistair Cockburn descreveu isso em seus métodos. Se você tem "profissionais de nível 3", um método ágil perfeitamente válido é o seguinte:

“Coloque 4-6 pessoas em uma sala com estações de trabalho e quadros brancos e acesso aos usuários. Faça com que eles entreguem software testado e em execução aos usuários a cada um ou dois meses e os deixem em paz. ”

Como você tem uma mistura de pessoas, você precisa encontrar uma maneira de fazê-las trabalhar construtivamente juntas, e isso significa que uma abordagem de tamanho único provavelmente não será muito eficiente. Portanto, você precisa dividir as tarefas, o tempo todo, garantindo que o objetivo comum seja enfatizado. Não há problema em enviar esses caras para o código, mas eles precisam estar cientes de como suas coisas serão parte integrante do resto do trabalho da equipe e que não conseguir isso é uma falha do que quer que eles estejam produzindo. . Depois que eles entenderem isso (ou seja, eles não podem simplesmente fazer o que querem e entregar algo inutilizável), então seu trabalho está feito.

Digamos que o ágil não é para todos e o ágil não é para todos os projetos. Ao mesmo tempo, ágil é um termo muito amplo e Scrum é apenas uma implementação de um processo ágil - posso de alguma forma dizer a implementação com provavelmente a maioria das restrições que tenta configurar processos padronizados com etapas conhecidas.

Outra área em que pensar é qual é o objetivo do ágil? É ágil a maneira como os desenvolvedores trabalham? Talvez - algumas metodologias realmente vão nessa direção. Mas o ágil em si abrange áreas fora do desenvolvimento. Agile é mais sobre conduzir todo o processo, a maneira como uma interação funciona, a maneira como você entrega o produto de trabalho com os recursos mais importantes no prazo e a maneira como você controla os recursos, como vê onde está no projeto atualmente, etc.

Existem metodologias que não tentam mudar nada do seu processo de desenvolvimento - o Scrum não é esse. Todas as metodologias ágeis enfatizam a melhoria contínua. Você detectará algum passo ineficiente no seu processo e tentará aprimorá-lo / alterá-lo - é o caminho ágil. Confira outra metodologia ágil popular - Kanban.

Você / Sua empresa decidiu usar o Scrum e isso pode levar ao fato de que algumas pessoas não vão gostar e vão embora. Você deve lidar com cada um de seus desenvolvedores separadamente. Você deve falar sobre isso com cada um e tentar encontrar alguns interesses que lhes permitam apreciar o trabalho novamente.

Eles podem ter o papel de mentores, podem ensinar outros, mostrar como refatorar o código para melhorar a arquitetura ao trabalhar iterativamente. Eles podem formar juntos algum uso do blueprint da arquitetura global em todos os projetos. Eles também podem trabalhar na prova de conceitos, participar da RFI (solicitação de informações) quando os clientes fazem perguntas para pensar sobre a viabilidade dos requisitos. Eles podem trabalhar em pares com desenvolvedores menos qualificados e realizar tarefas complexas juntos, etc. Seu principal valor deve estar no uso de suas habilidades e permitir que outras pessoas aprendam com elas.

Scrum e ágil globalmente, de alguma forma, afastam os indivíduos e priorizam as equipes - as equipes entregam aplicativos, não os indivíduos. Essa idéia é baseada no fato de que você nunca terá uma equipe em que todos tenham o mesmo conjunto de habilidades e experiência.

Se sua transição para o Scrum for bem-sucedida, eles devem ver que o processo geral melhorou, os prazos de entrega foram reduzidos, a qualidade melhorou e os clientes estão mais satisfeitos. Eles ainda podem acreditar que os aplicativos desenvolvidos são muito piores do que poderiam ser, mas esse é o ponto - o cliente não deseja o melhor código já escrito. Os clientes desejam o código de trabalho mínimo / mais barato / o mais rápido desenvolvido, que atenda às suas necessidades. Se a força bruta é suficiente para isso, então seja. Isso é algo que pode causar problemas a desenvolvedores altamente qualificados, mas não é uma falha do ágil, é o lugar onde as demandas de negócios e o perfeccionismo se opõem.

Beneficiará toda a equipe se você pegar alguns dos principais problemas e entregá-los a um grande desenvolvedor. Todos podem se atualizar rapidamente e aprender alguma coisa no processo. Só não crie um aplicativo inteiro dessa maneira.

Você não dilui o código no menor denominador comum. Você faz com que os inexperientes alcancem os melhores desenvolvedores.

Houve muita discussão sobre o que é ou não "ágil" e muitos sentimentos, experiências e dúvidas pessoais sobre o processo ágil compartilhado aqui, mas eu realmente não vi uma resposta real para a pergunta. A questão original era como manter os principais desenvolvedores motivados quando eles vêem o código que eles escreveram no nível da arte pura e investiram seu suor e sangue, invadidos por outra pessoa e "corrompidos". Observe que, ágil ou não, isso vai acontecer em algum momento, é apenas mais visível agora, porque eles ainda estão trabalhando no código ao mesmo tempo que os outros, em vez de haver uma transferência típica de suporte, nesse ponto eles simplesmente não veriam essas mudanças sendo feitas.

O que eu consideraria a chave aqui é expandir a responsabilidade desses desenvolvedores e ajudá-los a mudar seu foco para o cenário geral. Talvez isso signifique um novo título, como Arquiteto de software, Líder de equipe ou Engenheiro de software sênior. Em seguida, mostre a eles que essa é uma oportunidade de ter um impacto maior, não apenas em um único projeto de cada vez, mas em vários projetos. O senso de propriedade ainda pode estar presente, mas seu foco não deve mais ser o fornecimento de um único grande projeto, mas a ajuda a definir o padrão para TODOSprojetos. Ajude-os a entender seu forte desejo de criar algo ótimo, mas mude o foco para desenvolver as práticas de engenharia de software da sua empresa e os outros desenvolvedores. Em vez de se encolher com o pensamento de seus colegas de trabalho cortando seu código em pedaços, essa pode ser uma chance para eles avançarem para o próximo nível e orientarem seus colegas de equipe e elevá-los ao seu nível.

Tentarei ilustrar alguns aspectos que não foram abordados por outras respostas e que, na IMO, são importantes.

A questão básica é a seguinte: alguns desenvolvedores são motivados principalmente pela alegria de realizar um trabalho difícil, pensando em um design, pensando em possíveis problemas e, em seguida, resolvendo o problema, peça por peça, com apenas uma interação mínima com os outros, por um longo período. período de tempo. Eles geralmente concluem o trabalho com um alto nível de qualidade e em tempo hábil; seu trabalho é sustentável e se ajusta à arquitetura geral.

Esse tipo de desenvolvedor pode achar difícil se adaptar a um ambiente ágil e sua atitude é frequentemente descartada como "falta de vontade de mudar", possivelmente relacionada ao ego ou a ser antiquado.

O que geralmente é 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 pronta.

Uma abordagem é que um desenvolvedor pega a especificação do problema, vai para o quarto dela e volta duas / 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 as partes interessadas (fazendo perguntas sobre questões específicas), mas a maior parte do trabalho é realizada pelo desenvolvedor ao qual foi atribuída a tarefa.

O que acontece em um cenário ágil? A equipe divide o problema em pequenos pedaços (histórias de usuários) após uma análise rápida (limpeza). A esperança é que as histórias de usuários sejam independentes umas das outras, mas geralmente não é o caso: para dividir um problema complexo em partes realmente independentes, você precisará de um conhecimento que normalmente só obtém depois de trabalhar nela por vários dias. Em outras palavras, se você é capaz de dividir um problema complexo em pequenas partes independentes, significa que já o resolveu basicamente e que só resta um trabalho de diligência. Para um problema que exige, digamos, três semanas de trabalho, provavelmente será o caso durante a segunda semana, não depois de algumas horas de limpeza feita no início do sprint.

Assim, depois que um sprint foi planejado, a equipe trabalha em diferentes partes de um problema que provavelmente dependem entre si. Isso gera muita sobrecarga de comunicação, tentando integrar soluções diferentes que podem ser igualmente boas, mas que são bem diferentes umas das outras. Basicamente, o trabalho de tentativa e erro é distribuído por todos os membros da equipe envolvidos, com uma sobrecarga de comunicação adicional (aumentando quadraticamente). Eu acho que alguns desses problemas são ilustrados muito bem neste artigo por Paul Graham, em particular no ponto 7.

Obviamente, compartilhar o trabalho entre os membros da equipe reduz o risco relacionado a um membro da equipe sair do projeto. Por outro lado, o conhecimento sobre o código pode ser comunicado de outras maneiras, por exemplo, usando revisões de código ou fazendo apresentações técnicas aos colegas. A esse respeito, não acho que exista um marcador de prata válido para todas as situações: a propriedade compartilhada do código e a programação em pares não são a única opção.

Além disso, a "entrega da funcionalidade de trabalho em intervalos mais curtos" resulta em uma interrupção do fluxo de trabalho. Isso pode ser bom se a parte da funcionalidade for "adicionar um botão de cancelamento na página de login" que pode ser concluída no final de um sprint, mas quando você estiver trabalhando em uma tarefa complexa, não deseja essas 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.

Obviamente, ter pontos de verificação frequentes visa tornar um projeto mais previsível, mas em alguns casos a interrupção pode ser muito frustrante: mal se pode ganhar velocidade, já que é hora de parar e apresentar algo.

Portanto, não acho que a atitude descrita na questão esteja relacionada apenas ao ego ou à resistência à mudança. Também pode ser que alguns desenvolvedores considerem a abordagem para a solução de problemas descrita acima mais eficaz, pois permite que eles tenham uma melhor compreensão dos problemas que estão solucionando e do código que estão escrevendo. Forçar esses desenvolvedores a trabalhar de uma maneira diferente pode resultar em 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 consideraram mais eficaz ao longo dos anos.

Apenas meus 2 centavos.

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

Parece que eles são "Lone Rangers". No Scrum canônico, essas pessoas simplesmente não se encaixam no time (elas perdem o pouco da "interação").

Se eles não são "Lone Rangers", então há esperança. Se você estiver executando o Scrum corretamente, eles deverão fazer parte do design do recurso em que estarão trabalhando (durante o Sprint Planning). É a única vez que eles precisam interagir com os outros. Você pode até "atribuir" todas as histórias relacionadas a esse recurso para elas.

Durante o Sprint, eles só serão "incomodados" pelo Scrum diário ... até que você possa provar (por ações, não por palavras) que serão apenas 15 minutos do tempo deles, e apenas para garantir que tudo esteja funcionando suavemente. Mantenha-se próximo das três perguntas e a maioria das pessoas deixará de cumprir.

Em nossa equipe, temos um grupo especial apenas para aprimoramentos de desempenho. Não os vemos muito, apenas no início do sprint para falar sobre as mudanças a serem feitas e no final da retrospectiva. Eles têm seu próprio "líder de scrum", que se reporta à equipe Scrum of Scrum. Eu posso lhe dizer, eles estão se divertindo.

Se Joe (seu desenvolvedor do Hero) for um pouco flexível, não vejo problema:

Como dito acima, deixe a equipe se auto-organizar: se alguns problemas são mais bem resolvidos, deixando Joe mastigar sozinho, então você esperaria que uma equipe de auto-organização de mente aberta chegasse a essa conclusão por conta própria.

Os únicos desafios que permanecem dentro das poucas restrições que o Scrum impõe:

1. Entregando funcionalidade em intervalos regulares: se você deixar Joe pensar em um problema por meses, sem nada para mostrar até o fim, Joe não será realmente ágil: ele está levando o proprietário do produto como refém e não lhe dando uma oportunidade de voltar a especificar essa parte do produto. Com essa prática, há também o risco de ele estar atrasado e ninguém perceber. (Mas de acordo com a sua descrição, isso não é tão provável). Solução: Seria pedir muito a Joe, sentar-se junto com o OP, terminar a história do usuário e concordar com resultados intermediários, de preferência (mas não necessariamente) com o valor do usuário?

2. Honrando as prioridades definidas pelo proprietário do produto: Se partes de código pertencerem a especialistas, você corre o risco de uma situação em que a evolução do produto é determinada pela disponibilidade de cada especialista, e não pelas prioridades comerciais: O resto da equipe pode estar trabalhando em recursos menos importantes, enquanto os três principais estão parando porque "apenas Joe pode fazer isso". Isso é ruim. Nesse momento, a equipe deve (temporariamente) mudar de hábito e dividir o trabalho de Joe por mais membros da equipe.

Resumindo: se Joe, o herói-desenvolvedor, concordar com o PO como ele mostrará o progresso a cada sprint, a equipe poderá atribuir certas histórias a ele e deixá-lo em paz. Mas se o PO tem muito trabalho para Joe, e não o suficiente para a equipe (ou vice-versa), Joe e a equipe precisam se adaptar, não o PO.

As regras para uma equipe ágil devem ser personalizadas para se ajustarem à equipe - isso pode ser uma personalização realmente pessoal; Por exemplo, trabalhei em uma equipe em que a regra era:

Todo o código deve ser escrito por um par, exceto David pode escrever o código sozinho.

David era um desenvolvedor / arquiteto sênior, que trabalhou principalmente em ferramentas que outros usariam em seu próprio código. Ele possuía muito o código que escreveu. Era sustentável e testado, e todos na equipe sabiam que ele provavelmente era o melhor codificador de lá, e que a equipe seria melhor atendida, deixando-o construir certas partes da estrutura e apresentá-las como completas à equipe.

Não tenho uma resposta para introvertidos de variedades de jardins, mas para introvertidos excepcionais, a equipe adotará regras diferentes para obter o benefício.