Tag: agile planning

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

Olá Pessoal,

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

Lets go…

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 estarem remotos 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, foram  os demais pontos e isso eu já esperava, na verdade eu ficaria muito surpreso se a estória e o Sprint fosse entregue com qualidade. 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, heim? Fora quando tinham que ser dois devs trabalhando no mesmo blocker para tentar resolver rápido, ai era pior eram 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 uma Sprint rica de aprendizado. O time se comportou muito bem em se adaptar e responder aos problemas mais criticos 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 como foi a sua primeira Sprint ? Comente sua experiência… 🙂

Abraços, see ya!!

Scrum Remoto: Praticando Planning Poker

Olá Pessoal,

O post de hoje é bem mais uma dica. Mas a pergunta é: como fazer estimativa se meu time está remoto? Ou melhor, como se beneficiar do planning poker?

Lets go..

Starting…

Aqui na ITS temos projetos presenciais e remotos, mas a maioria é remoto, ou seja, o time trabalha de casa. Depois farei um post sobre como é o nosso trabalho remoto. Voltando ao problema, como fazer as estimativas com planning poker se o time está remoto? Pesquisando sobre alguma ferramenta que pudesse nos auxiliar, encontrei http://www.planningpoker.com/ realmente sensacional. Além de ser free, é muito simples de usar. Aqui na ITS estamos usando a ferramenta e está sendo uma boa experiência.

Como funciona?

  1. Você faz o cadastro, que é simples e rápido;
  2. Você escreve a estória;
  3. E dá um start;

As cartas aparecem e você escolhe a sua estimativa. Quando todos estimarem, o resultado aparece e o time discute. Se for aceito, a estimativa é associada com User Story.

Simples, não?

Era isso que queria compartilhar com vocês, mais uma experiência com gerenciamento de projeto Scrum Remoto.

Abraços, See ya!!