Equilibrando generalistas e especialistas - construindo equipes ágeis de sucesso

Não é surpresa para ninguém, que a agilidade incentive os membros da equipe a fazerem "coisas" fora do escopo de suas habilidades. Para ter vontade de fazer o trabalho, não estão familiarizados nem têm as habilidades certas. As equipes ágeis equilibram tamanho e habilidades para garantir que possam agregar valor, mas será que são sempre perfeitas ao fazerem isso? Não, na verdade nem deveriam ser. A estrutura da equipe é um problema complexo e não há resposta certa para esta questão. Mas, como tudo dentro da agilidade, a melhor maneira de resolver o problema é "fazer alguma coisa" e depois analisá-la, avaliar e adaptar através da transparência. Mas essa ideia simples nem sempre funciona quando olhamos a composição da equipe. Então, vamos falar sobre alguns cenários.

E o trabalho que requer habilidades técnicas avançadas?

Imagine que estamos construindo um produto de ressonância magnética que requer profundo conhecimento em física. Nós colocaríamos físicos dentro da equipe Scrum? A resposta é: Depende. Se o trabalho exigir muita teoria física, faria sentido incluir esse cientista na equipe, já que o trabalho requer uma quantidade significativa de contribuição de um físico, onde existem inúmeras dependências deste trabalho com outros membros, o custo do atraso técnico aumentaria exponencialmente, a possibilidade de falhas de comunicação e as sinergias gerais de ter essa pessoa na equipe, superam quaisquer questões departamentais. Se, no entanto, o trabalho não estiver focado nas questões relacionadas à física, ou seja, está mais focado na implementação das ideias, é possível que não precisemos do físico na equipe, ajudando apenas quando necessário. Na verdade, o físico não estaria apenas ajudando, mas também agregando oportunidades de aprendizado onde poderiam ajudar os colegas de equipe a se tornarem melhores profissionais, ajudando-os a entender a física, agregando valor à todos. A escolha principal que a equipe faz na composição não deve se basear nos limites tradicionais dos departamentos, mas sim no trabalho que está sendo feito. Se o trabalho for totalmente desconhecido, podemos continuar com o que temos dentro do time e ver o que acontece. Aprenderemos rapidamente se devemos ter um especialista ou não dentro da equipe.

O ponto principal é que, em um mundo ideal, se uma equipe precisa de habilidades técnicas avançadas, essas habilidades precisam estar na equipe. Caso contrário, as habilidades criarão um grande número de dependências, o que acabará por minar a capacidade da equipe de agregar valor.

E quando temos situações em que não temos habilidades suficientes para dar um jeitinho?

O Scrum não é mágica e não resolverá esse problema. Se não possuímos as habilidades suficientes para fazer o trabalho ou terminar com excelência a atividade de trabalho, não criaremos magicamente essas habilidades. O que faremos é tornar esse problema evidente no Incremento (no material entregue), na Revisão da Sprint, na Retrospectiva, no Planejamento da Sprint e no Scrum Diário. Na verdade, será evidente em todos os eventos do Scrum, que não é algo mágico, mas torna os problemas muito evidentes, incentivando a equipe a resolvê-los. As habilidades são um conjunto de desafios que as equipes enfrentam e o Scrum deixará escancarado a necessidade dessas habilidades. Isso, no entanto, significa que as escolhas precisam ser feitas pela equipe e pelo gerenciamento do ambiente em que a equipe trabalha. Não há como culpar o sistema usando o Scrum.

Muitas equipes que usam o Scrum descrevem a sensação de estar em uma equipe Scrum, como estar em uma startup. É raro que uma startup tenha todas as habilidades para oferecer o melhor produto, mas elas possuem o suficiente para entregar algo e irão buscar, emprestar e até mesmo roubar o conhecimento e a experiência necessárias para preencherem as lacunas. Quantas vezes visitamos um amigo que trabalha em uma startup para descobrir que as próximas duas horas estão cheias de perguntas e oportunidades de revisão? Podem comprar uma cerveja para você, ou convidá-lo para jantar, mas no final das contas, estão preenchendo as lacunas das equipes. Nunca criaremos uma equipe perfeita, isso é a verdade absoluta de uma startup, e também de uma empresa. Quanto mais complexo o problema, menor a probabilidade da equipe ser perfeita no primeiro dia. Mas o melhor do Scrum é que temos muitas oportunidades de aprender, mudar e melhorar. Existe uma crença falsa nas abordagens tradicionais de gerenciamento de projetos de que é possível não apenas planejar todo o trabalho antecipadamente, mas também determinar quem deve estar envolvido e quais habilidades precisamos. O Scrum aceita a realidade de não saber qual ideia estamos planejando, e o que precisamos em termos de trabalho e composição da equipe para avançarmos no projeto.

Mas isso não significa que as pessoas estão ociosas

Muitas pessoas temem que, quando incluímos na equipe todas as habilidades necessárias para entregar o trabalho, os membros possam ficar ociosos. Afinal, a distribuição do trabalho nunca é homogênea, sempre será um pouco irregular. Por exemplo, programadores aguardam especificações, testadores um produto para testar e especialistas em implantação não podem fazer nada até que tenham algo para implantar. A realidade é que o Scrum não cria o sistema mais eficiente para as pessoas com base nas habilidades existentes. Isso significa que as pessoas terão que ajudar trabalhando fora da zona de conforto ou com a experiência passada. Seria ideal, se todos trabalhassem com pessoas que já fizeram o trabalho antes e podem compartilhar essa experiência. Essa "bagunça" pode ser bastante desconcertante para os gerentes de projeto tradicionais que desejam otimizar o trabalho por meio de "recursos", garantindo que a "utilização" seja maximizada. O Scrum "utiliza" a equipe incentivando a transparência, permitindo o planejamento frequente do trabalho e quem o faz.

Em termos práticos, isso significa que uma equipe está ansiosa para que as pessoas trabalhem juntas nas tarefas e sempre ficam de olho no que vem a seguir na Sprint para garantir que todos estejam sendo o mais eficientes possível. A equipe está analisando as habilidades, garantindo que estejam espalhando o conhecimento por todos os membros. Isso, em particular, é muito diferente das abordagens industriais tradicionais que incentivam o conhecimento e a habilidade para criar escassez e uma forte dependência de uma pessoa.

E quanto aos cargos?

Para muitos, a falta de cargos detalhados no Scrum pode ser confusa. Contratamos, recompensamos e promovemos as pessoas baseadas em cargos. O modelo industrial de trabalho requer descrição detalhada das atividades, que são agrupados por cargos, que então são compensados e fazem parte de uma carreira. A abordagem ágil é diferente, pois não descreve os títulos detalhados dos trabalhos com base nas tarefas executadas, porque um trabalho complexo significa que a equipe não conhece realmente, em detalhes as tarefas que serão executadas. Em vez disso, o Scrum cria alguma flexibilidade na estrutura da equipe para dar suporte a trabalhos complexos. Uma equipe Scrum é formada por três funções: O Dono do produto, que descreve a ordem, a prioridade e o valor do trabalho, o Scrum Master que garante que o Scrum esteja sendo seguido, o que significa um processo empírico, auto-organizado e melhoria contínua, e por fim, os membros da equipe de desenvolvimento, que são o grupo de pessoas que realmente fazem o trabalho e entregam o valor. Qualquer pessoa pode ser um membro da equipe de desenvolvimento e quem for necessário irá colocar a mão na massa. Os cargos oferecem uma ótima pista para decidir quem está na equipe, mas não deve determinar o que e quando as pessoas devem fazer as atividades. A ideia principal é que os membros da equipe sejam flexíveis.

Obviamente, os indivíduos ainda precisam de uma carreira e a construção de habilidades avançadas é importante. Mas deve ser equilibrado com uma cultura de compartilhamento de conhecimento. Os indivíduos prosperarão não porque são um gargalo com habilidades únicas, mas com a capacidade de ajudar os outros e desenvolver as habilidades de toda a comunidade.

Isso significa que as equipes podem mudar?

Um mito sobre o Scrum é que a equipe nunca muda. Sim, a mudança tem um custo. O custo de novas pessoas aprendendo a fazer parte da equipe. Mas esse custo precisa ser equilibrado com o custo final de não ter as pessoas certas no time. Além disso, é importante que as equipes e seus membros escolham onde trabalham, e não que não dependam de um grupo de planejamento de recursos que possui poderes mágicos para encontrar as pessoas certas para resolver o problema. As comunidades práticas podem ser uma ótima ferramenta para apoiar as necessidades de mudança das equipes Scrum, com os líderes da prática não apenas fornecendo orientação e desenvolvimento, mas também ajudando equipes que precisam de habilidades ou pessoas diferentes. Assim como o restante da agilidade, a alocação de pessoas, também conhecida como gerenciamento de recursos, é transmitida às pessoas mais próximas, as equipes e os grupos de equipes agregam valor.

Então, não existe um sistema mágico para formar equipes perfeitas?

Lembro-me do Santo Graal do gerenciamento de recursos, onde o trabalho era roteado com base nas habilidades e disponibilidade, e o trabalhador podia pegar o trabalho e com base no processo, fazê-lo sem qualquer conhecimento real de todo o processo ou resultado final, o processo industrial baseado nas atividades de conhecimento. Mas a realidade é quanto mais complexo o trabalho, mais difícil é construir a equipe certa com antecedência. E a ideia de que, em vez de formar uma equipe real, o trabalho pode ser conduzido com diferentes especialistas por um gerente de projetos, não apenas exige que o trabalho tenha limites legais, mas também ignora o benefício fundamental que pessoas diferentes trabalhando juntas para criar algo único e especial. Concentremos em uma equipe de generalistas altamente motivados que podem implorar ou emprestar o conhecimento para obter o valor entregue. E depois inspecionamos a equipe, o trabalho e as habilidades que precisam e adaptamos quando percebermos que está faltando alguma coisa.

Sobre o autor

Dave West é o Product Owner e CEO da scrum.org. É um palestrante frequente e um autor amplamente publicado de artigos, além de co-autor de dois livros, 'The Nexus Framework For Scaling Scrum' e 'Head First Object-Oriented Analysis and Design'. Seu twitter é @davidjwest.