Série Scrum Remoto: Time Evoluindo Sprint 3

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?

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

Série Scrum Remoto: Terminado a Sprint 0

Olá pessoal,

Vamos ver hoje como foi a Sprint 0. Será um post rápido.

Lets go…

Como foi o Sprint 0

Conforme já falei em outros posts da série, foi nessa Sprint que definimos o Sprint 0 como uma Sprint de setup e discussão sobre quais tecnologias eram ideais adotar para o projeto. Como por exemplo: vamos de Sprint MVC ou Vraptor? Fora outras discussões de infraestrutura, arquitetura inicial, etc. Claro que não definimos tudo aqui e pronto, mas o básico que precisamos para iniciar o Sprint 1, visando o baixo risco de ter que trocar amanha a versão ou framework escolhido por algum motivo específico, então vários pontos são analisados e discutidos com a equipe. Outro ponto interessante é que muitos membros do time criam POCs para mostrar o quanto a tecnologia X que ele defende pode ajudar. A única coisa requerida é que você apresente argumentos que convença o time da escolha da tecnologia, se conseguir ela é adotada e não precisa entrar em processo nenhum (que vai para “aquele cara” que em algumas empresas é considerado “o deus” que vai ter que dar o ok). Removi isso, não existe isso aqui. Odeio qualquer coisa que seja engessada. É o time técnico que define. Claro, nada impede de consultar especialistas, etc, mas no final é o team que decide as tecnologias que eles vão trabalhar nos próximos N Sprints que estão por chegar. O case aqui é de um projeto que participei em julho/2013.

A seguir o Burndown do Sprint:

scrumremotoburndownsprint0

Podemos ver que foi um Sprint bem apertado, mas a equipe conseguiu entregar bem na trave. Então concluímos ela acreditando que tudo que foi entregue já nos permite começar a Sprint 1 e meter a mão na massa na primeira estória. Vamos ver o que acontece no Sprint 1.

A retro do Sprint 0

Fizemos a retro usando a realtimeboard. Encontrei essa ferramenta por acaso e achei muito bacana para time remoto. Uma das funcionalidades que acho show é não precisar compartilhar a tela e a atualização é em tempo real para os convidados. Possui um chat e na versão free permite criar tres projetos privados. Olha o que rolou:

 scrumremotesprint0retro

Vou ficando por aqui. Espero que tenham gostado do post.

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

Série Scrum Remoto: Adotando uma ferramenta online ideal para o time

 

Opa Pessoal, 

Vamos a mais um post da série Scrum Remoto. Nesse primeiro projeto aqui na ITSLabs com Scrum remoto realmente não sabíamos qual ferramenta adotar, e como há várias no mercado e algumas se demonstraram até como a solução ideal, preferimos analisar com cautela. 

Lets go…

Qual a ferramenta ideal para Scrum? 

Ouço e vejo muito essa pergunta. Eu digo sempre que não há ferramenta ideal. Uma que funciona bem para um determinado projeto e equipe, pode não funcionar bem para outra. Em um ambiente físico eu ainda gosto de ter as coisas na parede, quadro, etc. Mas e em um time remoto? Aí temos que usar uma ferramenta que pode ser uma planilha eletrônica, uma aplicação, um software desktop, etc. A escolha é da equipe. Mas qual adotar? Vou pelo custo ou por aquela que é famosa na comunidade?

O custo tem que ser analisado sim, e nem sempre o mais caro é o melhor. Pense nisso sempre. O mesmo vale para a segunda pergunta, o fato de ser famosa na comunidade também não quer dizer que é a melhor, e o fato de todo mundo usar não quer dizer que é a ideal ou a melhor do mundo. Há estratégias de marketing por detrás de qualquer produto e é preciso extrair e olhar apenas para o produto seco. É o que faço sempre antes de adquirir qualquer produto, busco identificar essa parte, ignorar e tomar uma decisão com base na razão e necessidade.

E como eu fiz aqui na ITSLabs?

Aqui tínhamos um problema como esse. Uma lição que aprendi é não tomar uma decisão corrida para a escolha da ferramenta apenas porque o Sprint 1 começa amanhã. É uma decisão importante e cara, mas também não posso deixar o team sem nada e as informações precisam estar compartilhadas de alguma forma para termos um tracking do Sprint corrente e saber como estamos indo. E pesquisando no velho Google achei um template feito no Microsoft Excel que parecia atender ao que precisávamos enquanto não tínhamos uma ferramenta ideal para o nosso time. Vejam o template dela:

scrumxls

Claro que não íamos ficar trocando emails com essa planilha, daí, o que usar? O dropbox. Então sempre que ela for atualizada todos são notificados.

O problema

Na planilha que encontrei acima descobri que é ideal para um projeto pequeno e rápido, mas não se encaixa no nosso. Por quê? Simples. Como fazer o tracking de todos os Sprints? A cada release os investidores querem saber como fomos nas últimas 3 Sprints. Quanto tempo gastamos, número de bugs, etc. Iai o que fazer? Mandar cada XLS do Sprint por email e dizer para ele olhar? Ou melhor, criar um novo XLS com essas informações compiladas e mandar pra ele. Mas terei que fazer isso a cada release, e quanto tempo vai custar para isso?

Outro problema que tivemos com a sincronização do DropBox: em alguns casos não funcionava bem. No IOS não atualizava às vezes e aconteceu de um membro da equipe ficar com  o XLS desatualizado.

Em projetos que já trabalhei com Scrum, já usei várias ferramentas, muitas já eram default nas empresas, outras estavam em testes, etc (como Jira, Scrumworks, IceScrum, Mingo etc), mas para o projeto que estou agora a ferramenta ideal foi a Rally pelo seguinte ponto:

– Atende ao nosso projeto;

– O team achou muito fácil de usar e ela se encaixa bem para o nível do projeto;

– Customização da tela;

– Custo x benefício;

É possível saber como as coisas estão muito facilmente.

O que precisa melhorar? 

– Sincronização. Se uma informação é atualizada, é preciso dar reload na página para ser atualizada; a ferramenta deveria atualizar automaticamente;

– Adicionar novo usuário. Se o usuário tem cadastro no rally, não conseguimos adicionar ele ao projeto. Acho que a ferramenta deveria permitir buscar usuários já cadastrados e adicionar ao projeto.

Depois de uma análise, decidimos usar a ferramenta no Sprint 2. Fizemos alguns testes antes com projetos fake para entender e ver se realmente nos ajudaria.

Conclusão 

Nessa busca de ferramenta online para projetos Scrum descobri que não importa a ferramenta que você usa, mas sim se o time está confortável com ela e se a mesma agrega valor para o seu projeto. Não adianta querer empurrar uma ferramenta para o time ou projeto só porque alguém do comercial fez um bom negócio com a criadora da ferramenta. O motivo? A ferramenta pode atrapalhar a equipe, principalmente na curva de aprendizado. Outro aprendizado que ficou é que para cada projeto o melhor é sempre analisar qual ferramenta se adéqua melhor, usar um X tudo pode ser mais fácil, e em alguns casos parece ser mais barato, porém hoje há varias opções onde que você contrata serviços apenas para o que precisa e acho que ter a ferramenta ideal por projeto é mais importante do que querer ter uma ferramenta “for all”.E lembrando que as pessoas são mais importantes que as ferramentas, não adianta investir milhões em aquisição de ferramentas “inovadoras” enquanto não se valoriza e não investe nas pessoas.

Vou ficando por aqui. E você, qual ferramenta Agile tem usado em seus projetos? O que tem considerado para a escolha?

Abracos, see ya!