Olá, pessoal!

Estou começando mais uma série 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 artigo eu vou dar a minha. A ideia da série é compartilhar o aprendizado e a cada artigo vou compartilhar com vocês como foi a última Sprint e a semana do time. As Sprints são curtas, não duram mais do que duas semanas. Não pretendo entrar nos detalhes durante os artigos e também vou omitir informações confidenciais de negócio do projeto. Dúvidas? Deixem nos comentários.

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 que “Scrum só funciona se o time estiver fisicamente junto”, ou que “Scrum não funciona remoto, não tem como fazer daily meeting e nem um quadro de como estão as coisas”, ou “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, essas e outras frases são comuns de se 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ç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

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 teste 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 www.planningpoker.com.

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 artigo 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. Vai muito além… E aí, 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á várias 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 negócio, 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 artigo da série.

Abraços!