Em um time ágil “todo mundo faz tudo”?
Em times ágeis de produção de software todos devem executar todas as tarefas necessárias?
Isso é um assunto recorrente em times ágeis iniciantes e até mesmo em times já estabelecidos mas com pouca maturidade.
Vamos refletir um pouco sobre o que realmente é este conceito e como encontrar o equilíbrio.
O que diz o Scrum Guide?
Uma excelente referência para equalizar o assunto é o Scrum Guide (link no fim do post):
“Times multifuncionais possuem todas as competências necessárias para completar o trabalho sem depender de outros que não fazem parte da equipe”
A recomendação acima é muito clara: o time possui todas as competências que precisa para completar o seu trabalho. Não fala em momento algum sobre um membro do time ter que possuir todas as competências.
Fica claro quando falamos de Scrum, mas em times ágeis que não estão orientados a Scrum o mesmo raciocínio se aplica, pela lógica.
Vamos entender o motivo.
Indivíduo Multifuncional
Aqui é que mora a disfunção.
Muita gente confunde time multifuncional com indivíduo multifuncional.
Quando falamos do indivíduo multifuncional nos referimos ao profissional que possui todas as competências que o time deve ter (aqui falo mais especificamente do DevTeam, e não do Scrum Team).
Imagine o seguinte cenário:
Na empresa temos um time que suporta um App Mobile de e-Commerce.
Este produto foi desenvolvido utilizando as seguintes tecnologias: Objective C para a versão IOS, Java para a versão Android, C# para o back-end, persistência com parte em Oracle legado e parte já segregada em microservices usando banco NoSQL, Docker etc.
Qual é a possibilidade (salvo raras exceções) de algum profissional dominar todas as tecnologias citadas acima de verdade?
Pelo bom senso, naturalmente que não se aplica.
Equipe multifuncional é diferente de indivíduo multifuncional!
Indivíduos em times multifuncionais
Em times multifuncionais, como falamos no início do post, devemos ter uma composição de pessoas onde todas as habilidades técnicas necessárias para o desenvolvimento do produto estejam presentes, mas cada indivíduo com a sua especialização (podendo ser mais de uma, sempre que possível).
No exemplo do App de e-commerce que falamos poderia ser algo como:
- Scrum Master (é do Scrum Team, não do Dev Team)
- Product Owner (é do Scrum Team, não do Dev Team)
- Dev 1 – Java para Android
- Dev 2 – Objective C para IOS
- Dev 3 – C# com back end e conhecimentos de microservices, Docker, Oracle e NoSQL
No contexto acima teríamos todas as competências necessárias, mas cada profissional voltado para sua especialidade.
Scrum Master e Product Owner como Desenvolvedor?
É relativamente comum em algumas empresas, seja por modelo de processo adotado ou por restrição de custos, dar o “chapéu” de SM ou PO para um Desenvolvedor.
Neste caso também temos o problema do indivíduo multidisciplinar, afinal, eficiência (SM) e eficácia (PO) são disciplinas muito diferentes de Engenharia (Dev).
Em alguns cenários isso pode ser aparentemente viável, mas fatalmente haverão gaps e baixa performance que vão comprometer a capacidade do time de fazer o seu melhor.
Obs1.: estamos falando aqui da Síndrome do Pato (o link fala bem sobre, mas é um site bem humorado, que não necessariamente representa toda a nossa opinião sobre o assunto, ok?).
Obs2.: podemos ter empresas super maduras em termos de agilidade que não tenham PO nem SM (tem alguns poucos casos no Brasil), onde o time é composto apenas de Desenvolvedores e a parte de eficiência fica com um Agile Coach compartilhado e de eficiácia como Product Manager que lida com vários times também.
E se o resultado do Sprint estiver comprometido?
Mais uma vez, vamos usar o bom senso.
Os times não devem ter profissionais com todos as competências necessárias para o trabalho a ser feito, isso não se aplica, não tem sentido.
O time sim, deve ter na sua composição profissionais que possuam todas as competências coletivamente falando.
Mas estamos falando de time e não de equipe.
Num time, ou todos ganham, ou todos perdem. E quando estão perdendo, todos se ajudam.
Em times Scrum é comum situações onde um profissional já terminou sua parte do trabalho mas outro ainda não.
Exemplo clássico (em times que possuem Analistas de Testes): os desenvolvedores terminaram a construção na reta final do Sprint, mas todos passam para o Analista de Testes as entregas para testes ao mesmo tempo.
Resultado = Gargalo garantido e WIP estourado.
Em situações como estas o time deve ser voltar para ajudar o membro que está no sufoco, afinal, a meta do Sprint é algo sério.
Neste caso, não se deve esperar que um profissional especializado em tecnologia A seja veloz e sênior em tecnologia B, mas ele deve ajudar como conseguir o colega da tecnologia B a concluir o seu trabalho.
Precisamos sempre usar o senso crítico.
Veja aqui o Scrum Guide (neste link você pode ver a versão PDF em português).
Abraços!