Criar uma visualização para o fluxo de trabalho é uma das primeiras recomendações do Kanban e tem uma série de vantagens potenciais: melhoria da comunicação, transparência nas priorizações, clareza em relação aos gargalos, maior colaboração, etc… Além de ótimos benefícios, soa como algo trivial de executar quando lido em um post como esse. Sinceramente, acredito que era para ser simples mesmo. Todavia, nada como uma boa dose de mundo real para mostrar que até coisas simples podem ficar complicadas.
NOTA DO ELEMAR: Este é o segundo post do Fernando Neiva, editado por mim.
Desafio #1 – Dificuldade em gerar um consenso sobre a granularidade dos itens
No nosso cenário cada time tinha uma percepção de como gostaria de visualizar os itens no quadro Kanban. Por exemplo, o time de negócio alegava que as User Stories eram demasiadamente granulares para poderem acompanhar a evolução do trabalho. Por essa razão, defendiam que precisavam ter uma visão agrupada em features, onde cada feature contempla um conjunto correlato de user stories.
Já para o time de desenvolvimento a visão deveria ser em user stories no mínimo, se possível, em tasks, onde cada task representa uma atividade técnica que precisa ser realizada para alcançar o objetivo de negócio proposto na User Story.
Até cogitamos, em certo momento, criar visões separadas, porém percebemos que um time trabalhando em uma visão e outros acompanhando em outra geraria ruído na comunicação. Também ficou confuso alguns conceitos como a delimitação do work-in-progress que poderia ter sentidos diferentes dependendo da granularidade da visão.
Desafio #2 – Qual ferramenta utilizar para compartilhar a visualização com toda empresa
Os times de desenvolvimento trabalham no mesmo escritório (com exceção do Elemar que nos acompanha remotamente) e não seria problema utilizarmos um quadro com post-its para o controle de tarefas. Porém, temos equipes comerciais, consultores, implantação e operação distribuídas geograficamente. Logo, tivemos que nos preocupar em escolher uma ferramenta online. Isso nos levou fazer alguns questionamentos. Acomodar uma visão de Kanban nos softwares que já utilizávamos ou adicionar mais um sistema na stack?
Para os squads de tecnologia receberem reports de bugs e solicitações dos usuários nós utilizávamos o Jira. Já para controle das demandas, gerenciamento de configuração e integração o TFS. A área de negócio e produto fazia uso de planilhas. (E o Elemar é fã do Trello).
Apesar de acharmos que essa era uma stack mais complexa que gostaríamos, cada software tinha uma razão legítima de existir e queríamos evitar fazer mudanças bruscas naquele momento que fossem impactar muitas pessoas. Mas, de qualquer forma, precisávamos manter nosso objetivo de melhorar a comunicação.
Cenas dos próximos capítulos
Fizemos algumas experimentações para chegar ao que estamos utilizando hoje. Houveram alguns erros que serviram de aprendizado. Compartilharemos nos próximos posts o que funcionou e o que falhou no nosso cenário e o porquê.
Se você está adotando kanban também no dia a dia do seu time compartilhe conosco seu aprendizado, pode ajudar a mim e a outros que nos leem.
