Como usamos o Scrum na Myfreecomm

3

Há algum tempo que a Myfreecomm aderiu ao Scrum e adotou os valores propostos pelo Manifesto Ágil. Nossos resultados tem sido impressionantes. Em pouco tempo, compreendemos o grande valor do Scrum na promoção e intensificação das comunicações entre os colaboradores.

A Migração

A adoção do Scrum, como todo novo hábito, foi gradual. Começamos experimentando as dinâmicas básicas, tentando seguir as sugestões tradicionais até percebermos, nas reuniões de revisão, o que estava dando certo e o que precisava melhorar. Com o comprometimento da equipe, optamos por riscar a palavra errado do nosso dicionário, e definimos que ou algo funcionava bem, ou precisaria melhorar. Esta atitude foi fundamental em nossa caminhada.

Logo no início nosso primeiro desafio foi adaptar o foco do sprint. Não podíamos associar o sprint com um projeto ou produto. Nossa Equipe é bastante heterogênea, composta por especialistas de diversas áreas. Essa é uma característica fundamental para nossos objetivos, mas podem acarretar a sobrecarga de parte da equipe. Por isso, administrar caminhos críticos é muito importante no nosso planejamento, tentando paralelisar ao máximo as pendências, evitando a criação de sprints individuais.

A solução foi organizar o sprint de maneira mais abrangente, criando um sprint para a empresa. Esta estratégia ajudou bastante nosso aprendizado. Enquanto nos acostumávamos com a metodologia, pudemos compartilhar a visão de todos à todo momento, e aprimorar o processo em futuras iterações.

A Reunião de Planejamento

Começamos preparando nossa reunião de planejamento revisando o backlog. Em uma espécie de reunião estratégica, identificamos quais itens tem mais valor para os Donos do Projeto, sem nos preocuparmos em definir esforços. Isso ajuda muito a focar no real valor da tarefa, evitando otimizar o sprint prematuramente, encaixando itens de menor esforço como brinde.

De posse de uma lista com itens que, no chutômetro, parecem caber no sprint de duas semanas, seguimos para estimativa de esforços. Repassamos item por item, definindo o resultado esperado. Neste momento, cada membro da equipe anota tarefas para o item em post-its, e em seguida, consolidamos os post-its de todos, eliminando os repetidos. Agora que temos uma idéia melhor do que será realizado, partimos para o poker onde usamos cartas seguindo a seqüência de Fibonacci de 1 à 55.

Após estimarmos cada item, reavaliamos criteriosamente os itens somando os esforços para certificarmos de que cabem no sprint. A sinceridade e participação de todos neste processo de avaliação é fator crítico. O sprint precisa estar perfeitamente alinhado com a realidade. Só assim a equipe se sente comprometida e faz acontecer. Tentar espremer para “otimizar” ou “alavancar” a produção, é um verdadeiro tiro no pé. Isto por que a equipe passará a não acreditar no sprint, consciente ou inconscientemente, gerando frustração e ceticismo quanto à seriedade do Scrum.

Claro que no início, não sabíamos ao certo quantos pontos de esforço conseguiríamos entregar. Nesta fase, uma certa correlação entre esforço e tempo acaba acontecendo, mas é importante se desprender dessa visão o quanto antes. Esforço é uma medida subjetiva e comparativa. Isolada, ela não tem validade. O esforço só mostra sua utilidade quando você observa comparativamente os itens e a convergência ou divergência das impressões da equipe durante o poker.

O Quadro e o Burndown

Terminada a Reunião de Planejamento, o Scrum Master monta o quadro. A configuração do quadro também varia em cada implementação do Scrum. Aqui na Myfreecomm já experimentamos diversas configurações, e hoje utilizamos basicamente o quadro tradicional, agrupando verticalmente os itens de modo a refletir os segmentos de trabalho da equipe. Nestes grupos, os itens são ordenados de cima para baixo por ordem decrescente de prioridade. Adicionalmente, para comportar tarefas soltas que inesperadamente surgem durante o sprint, possuímos uma linha fixa no quadro com o item “para-quedas“. Neste item registramos as tarefas que literalmente caem do céu.

O famoso gráfico de Burndown exerce um papel puramente motivacional. Ele declara visualmente para a Equipe, se o sprint está fluindo como previsto ou não. A nossa experiência nos mostrou que é preciso ter cuidado com a importância dada ao Burndown. Quando se está iniciando no Scrum, é inevitável confundir alguns conceitos e querer usar o Burndown para controlar o sprint. Isso ocorre principalmente porque o grande valor do Scrum só é percebido com algumas experiências. Lembro bem de algumas vezes em que acabamos perdendo tempo relacionando horas por tarefas e manipulando indicadores para que o Burndown refletisse a visão gerencial do sprint, incorrendo em uma “burrocracia burocracia ágil“. Hoje, com a maturidade do nosso Scrum, abandonamos todas estas idéias e realizamos o controle na medida da nossa necessidade. Assim, nosso gráfico é calculado da maneira mais simples e objetiva possível, sendo atualizando apenas na conclusão de um item, e não a cada tarefa. Basicamente, parafraseando nosso amigo Juan Bernabó: “Não importa quantos passes o Time dê, o que conta é o gol“. E no nosso caso, o gol é a entrega do item.

As Reuniões Diárias

Nossas reuniões diárias acontecem às 9:30. Para nós, este horário se provou tarde o suficiente para que a Equipe chegue, tome um café, leia os e-mails e se libere de tarefas pontuais do cotidiano. E cedo o suficiente para que determinemos as tarefas e possamos concluir algumas delas ainda na parte da manhã. Reuniões depois deste horário tendem à esticar um pouco mais, e o pouco tempo que sobra entre a reunião e o almoço não é suficiente para que a Equipe entre naquele estado produtivo de concentração.

A dinâmica das reuniões diárias é bastante simples. Todos ficam em pé, próximo ao quadro. Então arbitrariamente, cada um vai ao quadro movimentar os post-its falando o que fez ontem, se houve alguma coisa que merece ser destacada, e o que fará no dia de hoje. É um processo lúdico, bastante descontraído.

É importante a consciência de que o objetivo da reunião diária não é prestação de contas, e sim comunicação. Com este processo, a Equipe se comunica, e todos passam a compartilhar a responsabilidade de informar e informar-se. Isso elimina o papel do coordenador, que antes era quem possuía sozinho a visão do que precisava ser concluído, sendo o único responsável por acompanhar individualmente cada tarefa, fazendo o sequenciamento da produção. O ganho com a comunicação estabelecida nestas reuniões é indescritível! E a Equipe acaba ganhando mais um membro ativo na produção, já que aquele que sofria tentando coordenar, agora tem tempo sobrando para meter a mão na massa.

O tempo de duração das reuniões diárias costumava gerar alguma polêmica. Em uma equipe heterogênia como a nossa na Myfreecomm, é difícil respeitar os sugeridos 15 minutos, e é comum as tarefas precisarem de uma certa contextualização. Isso acaba tornando as reuniões um pouco mais longas, gerando reclamações principalmente do pessoal não-técnico, que diz não entender o tecniquês que envolve nossos encontros matinais.

Nos debatemos um pouco até entender a duração ideal das reuniões diárias. Com a experiência, concluímos que as reuniões não devem ser usadas para discutir definições e estratégias de implementação das tarefas. Quando este tipo de debate começa a surgir, alguém saca o cartão vermelho, interrompendo a discussão e adicionando uma tarefa de reunião de definição para os interessados.

No entanto, encorajamos a explicação e contextualização das tarefas, mesmo que o preço seja estender um pouco mais a reunião. Chegamos à esta conclusão quando o Alan, que é responsável pelo conteúdo, corrigiu o Cesinha que cuida do suporte, sobre uma funcionalidade do projeto que havia ficado de fora do sprint. A informação sobre o que estávamos fazendo estava tão bem disseminada, que não foi preciso envolver (e interromper) um desenvolvedor para se informar. Na média, nossas reuniões duram 30 minutos.

Também utilizamos cores para facilitar a organização do quadro. As tarefas definidas na reunião de planejamento são registradas em post-its amarelos. Durante o sprint, algumas tarefas que pertencem a um item do sprint, mas não foram previstas, são registradas com post-its verdes. E tarefas para-quedas ou efeitos colaterais inesperados que não conseguimos bloquear e precisaram ser negociados no sprint são registrados em post-its vermelhos. Isso permite que visualmente tenhamos uma noção da solidez do sprint, e facilita bastante a comunicação com os Donos do Projeto.

A Reunião de Revisão

O sprint segue seu curso até o dia da reunião de revisão, também conhecida como reunião de retrospectiva. Para a revisão, a Equipe se reúne na Távola Oval (nossa mesa de reunião), onde com transparência e igualdade compartilhamos sem censura nossas impressões sobre o sprint. A revisão começa com o Scrum Master traçando uma linha no quadro, marcando o início e término do sprint. Com isso, a Equipe inicia uma retrospectiva dos eventos que marcaram o período, registrando-os cronologicamente no quadro.

Com a memória da Equipe refrescada pela retrospectiva, dedicamos alguns minutos para individualmente registrarmos em post-its tudo o que deu certo, e o que precisamos melhor. Quando todos acabam, um a um, os membros da Equipe se dirigem ao quadro para falar ao Time as suas impressões, colando o post-it na área correspondente do quadro. Impressões repetidas são coladas umas sobre as outras, explicitando sua relevância no sprint.

No final, filtramos os post-its individuais, e re-lemos as impressões coletivas, registradas nos post-its agrupados em dois ou mais. Para fecharmos a reunião, pegamos nossas impressões coletivas do sprint anterior e re-lemos para analisarmos o que conseguimos melhorar de um sprint para o outro, e como fizemos. O resultado desta dinâmica é incrível! Pessoalmente, acredito que grande parte do amadurecimento da Equipe acontece neste momento. Durante o sprint, a correria cotidiana impede essa consciência coletiva, e na hora em que paramos para fechar o ciclo, uma série de “eurekas” ocorre nas pessoas contribuindo para a melhoria contínua do processo.

Bem, é isso! Dúvidas, idéias e sugestões são sempre bem recebidas, basta deixar um comentário.

[]’s!

você pode gostar também
3 comentários
  1. […] artigo Como usamos o Scrum na Myfreecomm, eu descrevi como funciona a retrospectiva, mas como exatamente se dá essa melhoria […]

  2. […] e fundamentos, foram muito enriquecedoras. Fiquei particularmente satisfeito ao constatar que nossos esforços na Myfreecomm estão no rumo […]

  3. Rafael Lima Diz

    Excelente Post!!

    Acho que vale ressaltar que nossa equipe tem mais de 7 pessoas e por isso o Daily demora tanto.

    Abraço

Deixe uma resposta

Seu endereço de email não será publicado.