Muitas equipes novas no SCRUM insistem no seu livre arbítrio de usar apenas as três colunas de TO DO, DOING e DONE no seu quadro de tarefas. Isso até pode ser razoável em um quadro de Discovery, em tarefas de preparação do DoR (definition of ready), mas não é para o Sprint de Delivery, é desperdício não explicitar todas as etapas do seu fluxo de desenvolvimento e seus buffers.
Não é simples, desenvolvimento de pessoas e times envolvem um viés cultural, em conhecimento, habilidades, atitudes, comportamentos e mesmo o cognitivo. Gestão por Competências é a arma e o gatilho é o senso de time e pertença, é um novo modelo mental que precisamos entender, desaprendendo o passado para aprender e internalizar novas alternativas no presente e mudar o futuro.
Um bom quadro Kanban que explicite as etapas de construção e seja enriquecido com avatares, postits formatados, selos, marcações, limites (WIP), etc, nos leva a um Sprint claro e transparente, otimiza as dailys e a necessária antecipação de riscos e oportunidades. Um bom quadro com um bom gráfico Burndown torna possível a qualquer integrante ou interessado ter uma clara informação do Sprint e seu andamento apenas passando os olhos por estes artefatos na parede.
Bons quadros e gráficos consomem um tempo de start, configuração, montagem inicial, sim, mas após isto são poucos minutos diários para mantê-los atualizados. Vejo equipes reclamando ou me consultando sobre a dificuldade de gerar percepções claras do andamento do sprint, mas mesmo com uma resposta conclusiva optam por usar o TO DO, DOING e DONE além do Burndown ilegível.
Alguns optam por uma viagem as cegas sem instrumentos, o sucesso depende da convergência de esforço pessoal e N fatores a favor, mas para dar errado só depende de umzinho destes não dar certo … aí quando se dão conta é tarde demais. O que dói é que o volume de dados úteis coletados e debatidos a cada dia é mínimo, o aprendizado é menor e se não der certo, a solução é tentar de novo.
Mas há times que trabalham consistentemente para mudar seus hábitos e modelos mentais, usam quadros conclusivos, postits formatados, avatares, selos de bug, de code review e pair programming, agregam informações diárias, algo que lhes ocupa minutos para gerar cenários atualizados e gestão visual de qualidade e valor inquestionável. Não é para ser difícil, leve na diversão!
Até onde ao adotar um método ágil o fazemos no mínimo exequível e buscamos novas zonas de conforto, evitando experimentar coisas diferentes, quer sejam artefatos, técnicas ou atitudes? Até onde é possível validar uma metodologia sem dedicar esforço para a mudança e transição, gerando restrições contra todo esforço adicional … NÃO existe mudança de metodologia sem esforço adicional para mudança de hábitos, desapegar do velho para aprender o novo.
Vejo equipes lado-a-lado em que uma insiste em tentar mudar o mínimo possível, enquanto outra se engaja, tenta novas técnicas, incentivam-se uns aos outros para que funcione. No futuro podemos eliminar ao máximo artefatos adicionais ou mesmo redundantes, mas enquanto estamos tentando implementar a mudança é gol contra achar que estamos com essa bola toda.
Com abordagens importantes para este entendimento tenho postado sobre a Curva de Tuckman em que temos a fase de Storming, sobre os Loops de Chris Argyris, sobre teorias sobre mudança cultural de Edgar Shein e tantos outros nomes, o processo de mudança para adoção de um método como o SCRUM é um desafio, pois não se trata de novas ferramentas e técnicas, trata-se de mudança de comportamentos e atitudes … usando novas ferramentas e técnicas.
Humildade e engajamento é a chave!
