Agile

17 set, 2014

Série Scrum Remoto: Primeira Sprint – falhou e agora?

Publicidade

Olá, pessoal!

Mais um artigo da série Scrum Remoto e chegamos ao final do primeiro Sprint – que falhou. Mas por que? Alguns podem pensar que era porque o time estava remoto. Será?

Começamos falhando

Fico feliz que a gente não começou diferente de alguns projetos Scrum que falham no primeiro Sprint. E umas das razões que já vi em projeto presencial com Scrum foram:

  • Estimativas;
  • Não saber a velocidade do Sprint;
  • Time aprendendo Scrum;
  • Blockers longos;
  • Comunicação;
  • Não saber o timebox do Sprint.

Quando falham em um projeto com Scrum remoto, muitos vão dizer o seguinte: “falhou porque o time não estava presente fisicamente”. Será? Ou estamos buscando uma desculpa para não enxergar os erros?

E porque falhamos aqui na ITSLabs?

Falhamos por todos os problemas que há no Scrum Presencial, exceto um. O de comunicação. Por incrível que pareça, por estar remoto, o time se comunicava com maior frequência via chat, call, fazendo share da tela e pedindo ajuda do outro. Tudo isso em tempo muito curto comparado com o que já vi em times presenciais. O problema real era os demais pontos e isso eu já esperava (na verdade eu ficaria muito surpreso se a estória fosse entregue). Um dos pontos foi não saber qual o tamanho do Sprint ideal. Começamos com 2 semanas e não deu muito certo, pois parte do time ficou ocioso e houve desperdício de tempo no final do Sprint 0. Tentamos de 1 semana, e a Sprint falhou porque o time teve bastante blocker e tinha que parar a task em development para resolver e depois retornar para task e alguns blockers duraram quase 6hrs do dia. Ruim, hein?! Fora quando precisava de dois devs trabalhando no mesmo blocker para tentar resolver rápido (aí era pior, pois tinha dois membros parados em função de um problema).

O final

Isso já sabemos, né? Todos com aquele feeling ruim por não terem entregue o Sprint como acordado e pensando em como resolver os problemas. De qualquer forma, foi um Sprint rico de aprendizado. O time se comportou muito bem em se adaptar e responder aos problemas mais críticos e ajudar o outro colega que ficou blocker. O espírito de team e foco no projeto e não na “minha entrega” era algo forte e isso me deixou muito feliz ao término do Sprint.

Veja como ficou o gráfico do Sprint 1:

scrumremotoburndownsprint1

E fomos para retro…

Teve a retro do Sprint, mas vou deixar para o próximo artigo da série para vocês verem o que saiu de lá.

Abraços!