menu

A saga para aumentar o volume de entregas – Parte I

Por

Para os que não me conhecem, nos finais de semana que o tempo permite, pratico voo livre de asa delta. Neste esporte há um provérbio que relaciona diretamente o nível de pressão psicológica que uma pessoa sente com o aumento em sua criatividade. A versão publicável vai mais ou menos assim: “quando o estomago aperta a mente expande”.

Faz alguns dias tive um longo papo com um colega do trabalho, ele estava curioso sobre o uso que eu fazia das tasks do Rally. A pressão que passei para chegar em casa logo apos o dilúvio do dia 14-02 em São Paulo me insipirou a escrever esta pequena peça literária a respeito.

Há aproximadamente 6 meses, uma pequena restruturação na empresa onde trabalho me colocou como Scrum Master de umas das equipes de desenvolvimento da plataforma. Essa equipe possui provavelmente o mesmo leque de responsabilidades de muitas equipes ágeis por aí, manter/evoluir funcionalidades já em produção e desenvolver novas funcionalidades.

No início dos meus trabalhos comecei a notar um padrão incômodo, sempre havia histórias vazando para as próximas sprints. Revisando a pontuação dos groomings e das tarefas aceitas notei que estávamos respeitando a velocidade e não aceitando mais do que teoricamente conseguíamos entregar em uma sprint. Minha primeira reação era de que a velocidade estava errada e convenci o PO a diminuir a quantidade de pontos por sprints.

Na sprint seguinte falhamos novamente, histórias vazaram. Certo de que estava no caminho correto negociei com o PO outra redução de velocidade, fiquei atento a histórias que entravam durante a sprint, acompanhei o time de perto e para minha desconcertante surpresa, falhamos novamente, historias vazaram. Convencido de que havia algo misterioso em curso fui em busca de outras explicações, pois outra redução de pontos na sprint nos levaria a uma velocidade que eu considerava ridícula para a quantidade de desenvolvedores que tínhamos na equipe.

Tarefas azuisUm belo dia, andando pelas equipes, pensando nas injustiças da vida gerencial e nas frustrações da vida pessoal, noto algo interessante nos scrum boards, tarefas azuis! Logo após o sprint planning as equipes têm o hábito de realizar o que chamamos de planning 2. Nele as histórias são desmembradas em tarefas e colocadas no quadro usando pedaços de papel branco, se por algum motivo a equipe tem que adicionar uma tarefa à uma história já na sprint ela é colocada no quadro usando um pedaço de papel azul. A ideia me acertou como um soco no estômago, a sprint em termos de histórias não variavam, mas as tasks azuis mostravam que ela terminava bem diferente do que havia começado.

Na retrô desta sprint, em que novamente histórias haviam vazado, fizemos a re-estimativa das que foram adicionadas tarefas azuis e para meu alivio a pontuação da sprint coincidiu com a velocidade original, aquela antes da primeira redução. Eureca!

Alguma coisa acontecia durante o desenvolvimento das histórias que fazia com que elas terminassem maiores do que foram originalmente estimadas. Meu primeiro impulso foi o de culpar os desenvolvedores por estimativas mal feitas, mas depois da experiência mal sucedida apoiada em feeling decidi que métricas deveriam guiar a próxima decisão. Precisava de uma forma de mensurar essas tarefas surpresa. Procurando no Rally, a ferramenta usada pela empresa, encontrei uma funcionalidade, renegada pela maioria das equipes, pulando na tela chamando a minha atenção, gritando “eu eu eu eu consigo”, as Tasks do Rally.

A ideia era usar a API do Rally e o uso extensivo de tasks para medir a variação das sprints e os motivos que a faziam variar. O processo de mensuração de alterações seria da seguinte forma. Do planning 2, tasks seriam adicionadas no Rally e cada task adicionada seria tagueada de acordo com o motivo a qual ela foi adicionada. No final de cada sprint, via API, geraria-se um gráfico da quantidade de tasks adicionadas na sprint e a distribuição do motivo ao qual elas foram adicionadas.

O hábito de usar as tasks do rally não seria facilmente adotado pelas equipes, a cultura do scrum board físico já estava profundamente enraizada na cultura organizacional dos times e pessoalmente eu acho que esses quadros ajudam muito na comunicação e no Management By Walking Around (MBWA). Sendo assim, decidi assumir a responsabilidade da manutenção correta do Rally. O tempo gasto até então falhando com as sprints não me permitiriam lutar contra a cultura ao mesmo tempo que coletava as métricas e eu precisava que os dados fossem confiáveis, caso contrário seriam inúteis. Encontrei uma passagem na Wikipedia de Charles Babbage que descreve a minha situação na época “if you put into the machine wrong figures, will the right answers come out?”.

Lá pela 3a. iteração um padrão curioso começou a se formar. Na média sempre havia um acrécimo de 20% a 24% de tarefas no total da sprint e quando olhei o detalhamento das tarefas adicionadas notei que estávamos nos afundando em débitos técnicos. Necessidade de manutenção de código replicado em diversos lugares, atualizações de bibliotecas quebrando variáveis não inicializadas corretamente, implementações que suportam pouca carga, e etc.

O ataque a todos estes males deixarei como assunto para outro post (cenas dos próximos capítulos) mas para encerrar gostaria de deixar 2 mensagens

1- Decisão baseada em feeling pode levar a vários resultados, estatisticamente pode-se tomar a decisão certa. Decisão baseada em dados leva ao resultado que o dado suporta.

2- Cuidado com o débito que você compra hoje, ele vai voltar para mordê-lo amanhã e depois de amanhã e depois de depois de amanhã…

3- Fazer mais do que esta no job description não dói…

1 comment

  1. Pingback: A Saga para aumentar o volume das entregas (parte II) | Kudoos

Leave your reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Go to top