Como faço o status report de um projeto ágil?

Quem nunca ouviu essa pergunta que ataque a primeira pedra neste post, rs…

Ágil não é mais uma tendência ou moda, é um fato. As grandes corporações já aderiram ao ágil no caminho de aumentar o retorno sobre os produtos, diminuir a cultura do “monitoramento e controle” e aumentar a #COLABORAÇÃO. Porém, geralmente não temos todos os níveis da organização “colando os post-its na parede” e é aí que pecamos na #TRANSPARÊNCIA.

…”Tá tudo no quadro kanban, é só o pessoal dar uma olhada”…

Diálogo comum por aí…

  • Time diz: Podemos trazer esse pessoal pra entender o nosso quadro?
  • PMO diz: Claro que podemos, seria perfeito, mas eles querem?

ps.: usei o PMO como exemplo pois geralmente eles são os vilões dos status, né? Tomei a liberdade de brincar com isso pois eu sou uma ex-PMO com muito orgulho, rs…

A questão é que a gestão topa a transição ágil e está ansiosa pelos resultados, pois só ouve falar bem por aí, MAAAAAS será que eles toparam também ler o quadro kanban ao invés de receber o status? Normalmente, não. O foco deles está em “o resultado está garantido?” e não no “como você fez isso?” (refletido no quadro kanban).

Mas tudo bem, essa é uma boa oportunidade de mostrar para a gestão que temos outras formas de acompanhar o status de um projeto: sem cronograma, curva S, SPI, contador de change request, etc. E tem mais, é uma oportunidade de comunicar a inovação! Afinal, adianta fazer algo legal, mas ninguém ficar sabendo? Temos que sair da caverna e gritar para todos os lados: olha o que estamos fazendo! É legal! E isso vai ser bom pra vocês também!

Até aqui eu tentei convencer vocês, SM e PO e Time, que é importante contar o que vocês estão fazendo no ágil, pois são vocês que vão disseminar a #CULTURA e os processos.

Encapsulando o resultado do time

Agora vamos falar de como encapsular os resultados que temos dentro do time para quem está fora do time:

1. Defina o público-alvo, porque o conteúdo relevante pode mudar dependendo do público.

2. Entenda quais são as preocupações do público-alvo e do time, porque são com elas que você terá as respostas certas. Ou seja, aqui entra a arte de entender os porquês (#loveTheProblem).

3. Pense simples, porque o reporte terá uma periodicidade de divulgação e qualquer um do time poderá atualizar.

Na prática, a dificuldade está no #loveTheProblem, pois quando falamos com o público a resposta deles é uma solução (quero o cronograma, a projeção dos custos…) e nós precisamos descobrir quais são as preocupações atrás desses pedidos para montar uma solução junto com o time.

Algumas ideias que vocês podem testar:

Quando o prazo for uma grande preocupação

Podemos usar o burn-up + cone da incerteza:

Colinha para montar o gráfico acima no Power Point:

IMPORTANTE: na primeira vez que a gestão ver o reporte, faça uma introdução explicando o porquê e como ler os novos gráficos.

Quando a mudança de escopo for uma preocupação

Traga o backlog priorizado e categorizado:

Quando a opinião do cliente é uma preocupação

Temos métricas específicas de produto. O Magno falou sobre elas em outro post, que você pode ler aqui.

Quando dependências externas são uma preocupação

Traga um quadro com impedimentos e aonde impactou/impactará.

Vale lembrar que temos que ter cuidado com as métricas que utilizamos pois elas vão moldar o comportamento do time. O Avelino falou mais sobre isso em outro post, leia aqui! Entenda quais métricas usar de acordo com o objetivo que quer alcançar.

Ah! Não podemos esquecer da melhoria contínua né galera! Alinhe com os envolvidos que essa é a versão inicial, ela é iterativa e incremental. Colha os feedbacks e melhore na próxima 😉

Quer saber mais sobre esse tema? Veja os links abaixo: