Oi pessoal, no post de hoje eu falo sobre mudanças na equipe. No atual contexto do dinamismo de equipes e projetos, é MUITO raro ter um projeto com a mesma equipe do início até o fim. Na verdade, eu mesmo nunca passei por essa experiência. Em todos os projetos em que trabalhei o tamanho da equipe sempre mudou em algum momento.
Esse é o cenário! E aí, como fazemos? O que podemos esperar dessas mudanças? Quais são os problemas que podem acontecer e como nos prevenimos?
No contexto do desenvolvimento tradicional de software, onde não há uma entrega contínua, os atrasos devido à mudança de tamanho da equipe são percebidos somente ao final do desenvolvimento, ou podem nem sequer serem notados. Porém, quando trabalhamos com agilidade, entrega contínua e timebox (Sprint de 15 dias, por exemplo), há uma transparência maior e os atrasos são perceptíveis.
Coletei através do Scrumhalf os relatórios com os pontos realizados pela minha equipe nos últimos 12 meses. Alguns eventos ocorreram nesse tempo modificando o tamanho da equipe. Optei por utilizar esses eventos como um separador de águas e assim pude identificar 4 períodos diferentes nesses últimos 12 meses.
Seguem os dados para melhor visualização:
Durante o primeiro período a equipe era constituída por 4 membros trabalhando juntos há mais de 1 ano. A equipe se encontrava estabilizada, com experiência na tecnologia utilizada e no Scrum. Nesse período obtivemos uma média de 41 pontos realizados, com desvio padrão de 10,79.
O marco para a troca de período foi a entrada de um novo membro na equipe, sem experiência na tecnologia e no Scrum. E um membro experiente da equipe assumiu a função de Scrum Master. Nesse período a média da equipe ficou em 42 pontos realizados, com desvio padrão de 13,56. Podemos dizer que essa foi uma mudança sutil, a equipe conseguiu absorver o novo membro e a média se manteve razoavelmente estável.
Destaco que, na minha visão, um dos fatores para o sucesso dessa transição foi manter o membro antigo como novo Scrum Master. A equipe foi capaz de dar o treinamento e a ajuda necessária para o novo membro se familiarizar com o projeto sem impactar no andamento das Sprints.
O marco para o início do terceiro período foi a saída de um dos membros antigos e experientes do projeto. Para “piorar a situação” no meio desse período aquele novo membro que havia recentemente entrado também saiu do projeto, ao mesmo tempo em que houve a chegada de uma nova pessoa. Nesse período a média da equipe caiu para 33 pontos, com desvio padrão de 11,93. Uma redução de 20% em relação aos períodos anteriores.
Na minha opinião, o fator mais impactante que resultou no decréscimo dos pontos realizados foi a saída do desenvolvedor mais experiente, pois é necessário um tempo de adaptação para que as pessoas que estão chegando consigam entrar num bom ritmo de trabalho e entrosamento com a equipe.
O quarto período tem seu início com a entrada de 2 novos membros no projeto. Como ocorreram mudanças recentes, a equipe agora já sabe lidar melhor com a entrada de novos membros e consegue eliminar os problemas mais comuns de maneira mais rápida, o que facilita o aprendizado dos novos membros. Esse é o período atual do projeto em que trabalho e, até o momento, estamos com uma média de 39 pontos e desvio padrão de 8,31.
No gráfico a seguir podemos ver a distribuição dos pontos realizados em cada Sprint. A linha vermelha representa a quantidade de pontos realizados e a linha azul é uma linha de tendência polinomial sobre esses pontos.
Conforme o gráfico nos sugere, existe uma tendência para que, no período em que minha equipe se encontra, a velocidade vá aos poucos aumentando até que se mantenha estabilizada. Já é possível notar a melhora em relação ao período anterior, mas ainda não ultrapassamos a média dos 42 pontos. A boa notícia, pra gente, é que nos encontramos na subida da curva 🙂
Se você já passou por situação semelhante em seu projeto, compartilhe sua experiência conosco. Até o próximo post!
