"To do or not to do"

Você já passou por este tipo de problema? Demandas são priorizadas para o time de desenvolvimento, mas nunca são iniciadas? Ou levam semanas para serem iniciadas? 

No meu caso, em um time responsável pela manutenção de vários sistemas, mesmo respeitando um limite de demandas priorizadas em um quadro kanban isso continuava acontecer. Sempre apareciam demandas que estavam paradas a muito tempo nesta fila. 

O problema é que, assim que uma demanda é priorizada, ela começa a gerar expectativas no demandante e nos usuários. Eles esperam que o problema deles seja resolvido em breve. E estar frustrando constantemente expectativas causa desconfiança no time de desenvolvimento: um custo caro a se pagar.

Então, como era a priorização neste time? Qualquer analista de requisitos pode priorizar uma demanda a qualquer hora. Seja a partir da chegada de um defeito por um sistema específico, seja pelo recebimento de um e-mail relatando um problema ou mesmo por telefone. Este analista decidia sozinho qual a prioridade deste item em relação aos demais da fila.

Então, começamos a priorizar semanalmente. Escolhemos um dia para todo o time se reunir e priorizar o que será feito na próxima semana. Não limitamos os itens a um número de demandas ou a um número de pontos (como é feito no Scrum), mas ao que o time acha que dá conta de fazer em uma semana. O time leva em conta o trabalho que está em progresso e o trabalho priorizado na semana anterior mas ainda não iniciado. Além disso, o time considerada também as férias e licenças dos seus integrantes.

Esta estratégia é chamada de estabelecer uma cadência de entrada e tem todo um capítulo dedicada a ela no livro Kanban: Successful Evolutionay Change for Your Technology Business de David J. Anderson. 

As vantagens que notamos ao utilizar esta técnica neste time foram:

1. Adequação da demanda à capacidade da equipe, pois a equipe só puxa o que conseguirá fazer na semana; 
2. Possibilidade de agrupar demandas similares ou correlacionadas para melhorar a produtividade, por exemplo, priorizar várias correções em um mesmo sistema, ou seja, a ordem que as demandas chegam não é a melhor ordem para trabalharmos; 
3. Criação de uma oportunidade para toda a equipe discutir cada demanda, entender e revisar os seus critérios de aceite.

Vale ressaltar que estabelecemos uma cadência de entrada, mas não de saída. Muitas demandas ou grupo de demandas levam mais do que uma semana para estarem prontas e continuam a serem testadas, homologadas e colocadas em produção no seus ritmos.

Um receio que tínhamos antes de iniciar era se o custo de reunir todo o time em uma reunião semanal seria alto demais. Mas isto não se confirmou. No início, gastamos mais de duas horas em uma reunião e no final já estávamos gastando pouco mais de uma hora. 

Um ponto que me surpreendeu é que nos pareceu fácil saber o que dava para fazer em uma semana. Se estivéssemos priorizando para duas semanas receio que os erros - priorizar demais ou de menos - seriam maiores. Mas, pode ser também que depois de um tempo, acabaríamos aprendendo. Fica como mais uma oportunidade de experimentação...

A conclusão é que desde então o time está mais consciente do trabalho a ser feito e poucas demandas passam de uma semana para a outra sem estarem terminadas ou pelo menos iniciadas.

PS1: Se quiser ser avisado por e-mail sobre um novo artigo, se inscreva aí do lado (nada de spams).