Olá Pessoal,
Estou começando mais uma série no blog e a ideia é compartilhar com vocês o que venho aprendendo no meu último projeto, que é ter um time Scrum 100% remoto. Será que rola? Não é difícil achar essa discussão e ouvir opiniões bem diferentes. No final do post eu vou dar a minha. A ideia da série é compartilhar o aprendizado, e a cada post da série vou compartilhar com vocês como foi a última Sprint e a semana do time. As Sprints são curtas, não duram mais que 2 semanas. Não pretendo entrar nos detalhes durante os posts e também vou omitir informações confidenciais de negócio do projeto. Dúvidas? Deixem nos comentários.
Lets go…
Starting…
Eu venho trabalhando em projetos Scrum desde 2011, mas sempre foi presencial, ou seja, o time estava alocado fisicamente, e o melhor: todos bem próximos e se possível na mesma mesa. Mas mesmo assim sofríamos de vários problemas que não está realizado ao framework. Até porque o Scrum não te diz como vamos implementar as soluções para cada problema que temos. E já ouvi muito isso aqui:
“Scrum só funciona se o time estiver fisicamente junto”
“Scrum não funciona remoto, não tem como fazer daily meeting e nem um quadro de como estão as coisas”
“Não dá para fazer Scrum usando ferramentas on line, já o framework diz que não devemos usar ferramentas” (sério que diz isso? Nunca vi isso).
Enfim, há muitas outras que é comum ouvir por ai. Mas iai, rola ou não rola?
Minha Experiência – Projeto Case
Eu sempre tive essa dúvida, mas nunca afirmei alguma das frases acima ou algo parecido, até por que é complicado afirmar algo assim já que há N variáveis. Mas agora estou em um desafio onde recentemente (julho/2013) entrei em um projeto onde todo o desenvolvimento será remoto e usaremos Scrum framework como ferramenta.
É isso mesmo que você está pensando, a daily meeting, planning etc, será tudo remoto. Não tem como os membros do time estarem fisicamente no mesmo local, a única coisa em comum é o timezone, por ser um projeto nacional.
Quando caí no projeto, apesar de já ter trabalhado assim, mas não usando Scrum, eu parei e pensei: “e agora, como será tudo remoto?”
Começando…
Começamos o projeto agora no inicio de agosto, pois em julho foi mais preparação do ambiente, equipe, reuniões estratégicas, budget e coisas administrativas do projeto. Depois de algumas semanas em reuniões para resolver assuntos administrativos, e também o valor disponível para saber onde podemos usar com eficiência, definimos o inicio do Sprint 0, que seria uma Sprint de setup de ambiente, análises tecnológicas e pequenos testes.
O que fizemos no Sprint 0
Aqui definimos se íamos ter um ambiente de desenvolvimento local ou remoto com base no nosso budget e optamos em ter tudo usando cloud computing, pois foi o que saiu melhor em custo x benefício. Para isso temos:
- Integrator VPN (show de bola o serviço oferecido, vou fazer um post comparando cada solução de cloud que testamos – jelastic, openshift etc)
- É nele que teremos nosso ambiente de continuous integration, deploy para test e homologação.
- GitHub (repositório privado)
- RealTime Board: usamos esse cara para evitar compartilhar a tela e ter um whiteboard em tempo real. É fanstástico. Dá para usar um kanban nele. Usamos para retrospectiva. Mas usamos ele na Sprint 0 para jogar todas as tasks que tínhamos que fazer para preparação de ambiente.
- Planning poker: usamos para estimativas das estorias
- Rally Dev: de ferramenta online, usamos e aprovamos. Vai ter um post exclusivo.
Por enquanto é isso que precisamos para iniciar o Sprint 1. Vamos adicionados mais soluções à medida que avançamos nas entregas, adicionando mais carne no esqueleto do projeto.
Vou escrever um post sobre como montar um ambiente de desenvolvimento remoto visando custo x beneficio.
Os problemas
Nem tudo são flores. Como o team é novo com Scrum e algumas soluções técnicas como o Git, GitHub, CI etc, preciso respeitar o tempo de aprendizado e ensinar aos membros como o Scrum funciona, a importância de usarmos Git e termos um ambiente de CI, etc. Então não tenho a velocidade de entrega do meu time, não sei se eles são capazes de entregar 5 ,10, 15 pontos por Sprint, e não quero pressioná-los para entregar de qualquer jeito, já espero que até o terceiro Sprint eles se adaptem e errem bastante. Duvido também que consigam fazer o Sprint passar, mas considero esse tempo como investimento e aprendizado: quanto mais cedo eles errarem e aprenderem melhor.
E o tamanho do Sprint? Ainda não sabemos também, é outro problema. Como definir se o team é novo, se estamos remotos e ainda preciso ensinar aos poucos sobre o Scrum, ambiente etc? Dificil, né? Usar o fator foco pode não funcionar, porque não trata só se está focado na task e sim outros fatores. Iai o que fazer? Nada. Pega a primeira estória que está no topo do product backlog e coloca para o time fazer, mas não crie expectativa que será entregue e não pressione sua equipe para vender a alma e entregar a estória. Isso pode frustrar os iniciantes e bloquear o aprendizado deles. E você não quer isso. Quer que eles aprendam no menor tempo possível.
Outro problema foi encontrar uma ferramenta scrum. Há varias no mercado, porém o mais importante é escolher aquela que se adapta bem ao seu time, e não adquirir uma que é famosa. Então minha primeira decisão foi não adotar uma ferramenta online antes do Sprint 1. Daí usei um XLS que gera o burndown e é compartilhado via dropbox. Só isso.
E no final rolou ou não?
Por incrível que pareça rolou. Tínhamos reuniões diárias, extra meeting, planning e retro, tudo remoto usando o Google hangout. Terminamos o Sprint 0 com o ambiente de desenvolvimento pronto, ou seja, todo o setup finalizado e apto para começar a desenvolver na Sprint 1. Nesse timebox do Sprint 0, o team pode discutir e testar várias soluções e frameworks que seriam utilizados no projeto e decidir qual seria o ideal para o nosso projeto e o porquê. Cada um tinha que defender a sugestão e no final o time entrava em um consenso e a tecnologia era escolhida. Não temos uma pessoa que vai enfiar a tecnologia pela garganta do time, quem vai decidir somos nós. E foi muito divertido ver a discussão do que usar ou não e cada um defendendo. O melhor de tudo foi que sugiram tecnologias que os membros do time não têm conhecimento e nunca trabalharam, mas que é o ideal para o projeto e será adotada. O team agora é responsável por aprender a tecnologia e fazer o bom uso para atingir o objetivo final que temos até o final do ano.
Conclusão
Não importa se você faz scrum presencial ou remoto, o mais importante é o seu time. Esse sim é quem define se vai funcionar usando Scrum ou qualquer outra técnica Agile. Claro que a estrutura base para o time trabalhar é importante e ajuda, mas não define. Aqui trabalhamos com uma estrutura mínima e usamos muitos serviços de cloud computing que nos ajuda a não ficar preocupados em gerenciar ou cuidar de atividades administrativas. Aquilo que não é importante para o negocio, mas é importante para o projeto, buscamos automatizar. Por exemplo, ter um servidor local. Talvez financeiramente seja barato, caso já tenha o servidor na empresa, mas você tem vários problemas relacionados em cuidar desse servidor; se você tem na cloud evita vários micro trabalhos que não agregam valor ao negócio.
Vou ficando por aqui. Até o próximo post da série.
Abraços.
