Pronto ou Preparado? Eis a questão...

No contexto de projetos ágeis é bem comum ouvirmos sobre definições de pronto (definition of done). Muitas vezes o pronto está associado a um estágio intermediário do ciclo de produção. Exemplo: pronto para testes, pronto para homologação, entre outros.

Ao falamos sobre velocidade para entregas de valor, os prontos intermediários tem relevância bem baixa; na ótica do clientes, o benefício propriamente dito só é realizado com o produto disponível e em utilização por usuários finais.

Olhando um pouco além do visivelmente declarado nas colunas de um quadro kanban, temos estímulos indiretos para manutenção de um modelo empurrado. Colunas que declaram intenção de pronto fazem com que a atuação na coluna anterior seja: fazer o mínimo e mais rápido possível e empurrar para seguinte.

Como mitigar, e possivelmente evitar, o risco desse tipo de comportamento? Uma abordagem efetiva é fazer com o que o próprio quadro kanban discipline o time (poka-yoke). Como fazê-lo? Remova colunas de pronto e insira colunas de preparado. Ao invés de pronto para testes, utilize uma coluna chamada desenvolvido/construído, por exemplo. O mesmo vale para homologação (ou testes de aceitação): ao invés de pronto para homologar/homologação, utilize testado.

Cada coluna no formato preparado pode, e deve, ter um checklist indicativo do que precisa ser feito para que uma peça seja puxada para ela. Essa mudança, embora pareça irrelevante, e seja sútil, faz com que o estímulo ao time seja de puxar peças da coluna anterior, ao invés de empurrar para próxima.

Desta forma estamos reservando a definição de pronto apenas para a última coluna do quadro kanban, que possivelmente indica que o produto está habilitado nas mãos do usuário final, como deve sê-lo.