Top Posts

Série NZ:Processo Intercâmbio

Continue lendo

Série Scrum Remoto: Time Evoluindo Sprint 3

Posted by camilolopes | Posted in Agile/Scrum/TDD, Series | Posted on 01-05-2014

0

Olá Pessoal, 

Mais um post da série Scrum Remoto e hoje estamos na Sprint 3. O objetivo é mostrar para vocês como foi a nossa Sprint, o que aprendemos e o mais legal é o fato de que ser remoto não impactou no objetivo. Então, para quem fala que times distribuídos com Scrum não funcionam, é importante ver o que tem de errado, mas não buscando colocar problemas no framework, ferramentas etc. Há outro fator envolvido, chamado de pessoas. 

Let’s go…

 

Scrum Remote Team Sprint 3 

Esse Sprint não foi um dos melhores para o time, porém melhor que os outros dois, uma vez que o time está aprendendo e pegando o jeito de trabalhar Agile, então estou considerando até um bom resultado. Conforme já falei em outros posts da série, a equipe nunca trabalhou com Agile, estavam acostumados sempre no lado “o meu está pronto” ou “eu sou desenvolvedor e não tenho que realizar teste se não for em minha máquina, quem faz isso é um tester”. E do lado técnico, o pessoal também estava aprendendo algumas práticas, como TDD, CI etc. Aqui todos metem mão na massa desde code até infraestrutura, o projeto é de todos e temos vários chapéus para ir usando até o final do Sprint.  Há desenvolvedores que no Sprint 1 nem sabiam para que servia o Jenkins, e hoje no Sprint 3 já mexem com a ferramenta, apresentam plugins que podem facilitar o processo de CI, etc. Vamos agora ao resultado: 

Iai, como foi o Sprint 3? 

Não pior que o Sprint 2, mas longe ainda de um Sprint ideal. A seguir o burndown nos fala isso. Vamos analisar 

<img sprint3handson> 

sprint3handson

O team prometeu uma entrega de 16 pontos. Se olharmos o Sprint 2, é uma capacidade maior do que havia entregado. 

 

sprint2handson

Tudo começou bem na primeira semana do Sprint, na verdade mandaram muito bem, quase mataram o Sprint rápido demais. Eu já havia suspeitado que tinha algo de estranho ai, mas preferi não comentar e ver o que ia acontecer. Quando chegou no dia 01/09, por algum motivo alguma estória voltou e faltavam poucos dias para terminar o Sprint, a equipe trabalhou duro e conseguiu fazer entrega no mesmo dia e nos próximos, mas observe que eles começaram a entregar somente faltando poucos dias do término do Sprint e no último dia de desenvolvimento, trabalharam duro para entregar. 

Velocity Chart

sprinthandsonvelocity

Foi bom?

Se comparar com a Sprint 2 e Sprint 1 foi um avanço muito bom da equipe. Percebo que agora eles estão pegando o jeito da coisa, e claro que há pontos para melhorar, mas eu sei que não é a mesma equipe que tinha no Sprint 1. É uma equipe melhorada. Tivemos um risco alto de acontecer alguma coisa ali no final e não entregar nada, ou pior, demoramos demais para entregar 5 dias depois do Sprint, ou seja, se temos 9 dias de desenvolvimento só entregamos quando já passamos da metade do tempo, não é muito bom isso. Exceto se está seguro que a estória não pode voltar e aconteceu isso: ela voltou, mas o time soube como contornar o problema e resolveu rapidamente entregando. 

Resultado

Saímos da Sprint 3 muito feliz com o resultado, pois tínhamos  no passado só tempestades, mas parece que está passando, porém o céu ainda não está ensolarado para o pessoal poder ir para praia. Aqui na ITS gosto muito que o team aprenda com eles mesmos, apesar de que algumas situações eu consigo ver que vai acontecer algo, mas prefiro que aconteça. Isso pode ser ruim para o negócio da empresa, mas para o aprendizado do team considero superimportante, pois vai impactar no negócio e no projeto. Às vezes há perdas financeiras por uma questão de contrato, mas não me importo muito com isso, até porque quando a ITS nasceu não foi por dinheiro, e sim por paixão pelo que fazemos. Não posso limitar nossos profissionais por uma questão financeira. Claro que vamos fazer um bom uso disso e sempre analisar para que não aconteça o pior de um drop do projeto. O pior é que um drop do projeto não é a grana envolvida e sim a oportunidade de aprendizado que deixamos de ter. Acredite ou não é a nossa cultura. Qualidade técnica é mais importante que seguir um contrato comercial. E mais interessante aqui é que quem faz parte do nosso comercial concorda com isso. Não temos aquela briga entre um grupo de nerd com business.

Vou ficando por aqui, e espero que tenha gostado desse post. 

 

Abracos, see ya!!

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

Posted by camilolopes | Posted in Agile/Scrum/TDD, Series | Posted on 28-04-2014

0

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!!