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!

Série Scrum Remoto: Fazendo retro usando realtimeboard

Olá Pessoal,  

No post de hoje da série Scrum Remoto vamos ver como fazemos as nossas retros na ITSLabs. Era um ponto que não fazia ideia como faria ao iniciar o projeto, mas sabia que deveria achar uma solução antes do final do primeiro Sprint.  

Lets go… 

Como fazer retrospectiva com time remoto? 

Essa é uma pergunta que muitos devem fazer e que eu também fazia, mas um dia reservei 1hr do tempo para buscar ferramentas que pudessem auxiliar para atingir esse objetivo, pois não bastava ter uma conferência sem saber como o time ia colocar os posts-its. Aí veio algumas ideias do time: 

– Podemos usar o google docs e criar uma planilha e as respectivas colunas: Good | Bad | Should be better.  Assim todos iam vendo;  

– Podemos usar o whiteboard e desenhar como fazemos fisicamente.  

E então, qual delas? 

 Para ser sincero não estava confortável com nenhuma das opções acima. Elas seriam minha última opção e eu queria algo melhor, com um custo x benefício aceitável dentro do orçamento do projeto.

RealTime Board 

Esse cara ai foi a melhor solução que achei e caiu como uma luva. Muito bom. Ele tem templates prontos e um deles era o KanBan. Algumas vantagens que identifiquei:

– Podemos ter 3 projetos private; 

– Sem refresh em browser ou algo do tipo; atualização realmente em tempo real; 

– Nada de share de tela; 

– Muito fácil de usar; 

– A versão paga possui um custo x beneficio aceitável;  

Vejam a seguir como foi a retro da Sprint 0 e o time todo colocando os posts-it remotamente durante a call. 

retrosprint

Fantástico, não? 

Conclusão 

Achei o RealTime uma ótima ferramenta quando queremos refletir um ambiente fisico KanBan em um ambiente remoto, e para quem já estava acostumado não vai sentir diferença.

E você, como tem feito suas retrospectivas com time Scrum remoto? 

Abracos, see ya!!!

Série Scrum Remoto: Team remoto com Scrum rola ou não?

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.