O Kanban, o facilitador para implementar DevOps

Há nove anos atrás quando Agile e DevOps no Governo Federal não havia muitos casos de governo, nesta época participei da implantação de ambos com relativo sucesso e muitas lições aprendidas na EBC. Inicialmente, havia uma resistência das equipes em usar novas tecnologias, métodos ou serviços.

A desconfiança entre as pessoas da equipe era grande, não havia muita conversa sobre as atividades em execução, planejamento ou mesmo conversa de boteco. Ou seja, elas estavam confinadas fisicamente numa mesma área da organização, contudo não eram uma equipe, uma típica cena daquela época em muitas instituições públicas. Um das causas era a frequente mudança de lideranças, como consequência, havia uma mudança frequente de diretrizes, o que fazer e como fazer. O efeito colateral era começar muitos projetos e quase nunca terminá-los.

O Kanban foi usado como o meio para implantar DevOps mas sem dizer que estávamos querendo fazer isso, a razão era porque a tentativa anterior de implementar DevOps fracassou completamente.

A estratégia para para implementar Kanban foi seguir um processo incremental e evolutivo, evolucionário. Começamos com o básico para a primeira versão do quadro Kanban, usamos um quadro branco e as colunas Backlog, Do, Doing e Done.

O proposta inicial era ter reuniões rápidas e diárias para feedback das atividades em andamento, como fazer as novas atividades e levantar as atividades que deveriam ser colocado no Backlog. Havia dois razões ao propor esta dinâmica:

1 - Incentivar as pessoas da equipe a falarem o que estavam fazendo, o que estava dificultando a execução da atividade

2 - Ouvir o que as outras pessoas da equipe estavam fazendo

A fato de falar e ouvir, no caso ouvir muito mais do que falar porque todos estavam ávidos para dizer o que estavam fazendo, as dificuldades e talvez o mais importante para cada um, dizer quais desafios foram vencidos. Todo mundo gosta, quer, ter seu trabalho reconhecido e obter reconhecimento das pessoas da equipe pode um dos maiores motivadores e também de retenção de talentos.

Conscientemente não foi estabelecido limite de tempo para reunião, apenas citado no início de cada reunião qual seria a duração ideal. Pacientemente era ouvido o relato de cada membro e orientado a identificar quais seriam as atividades e projetos que deveriam estar no quadro. A reuniões diárias levavam horas mas iniciava ali um senso de equipe efetivamente.

Está foi a dinâmica na primeira e segunda semana, as reuniões diárias duraram horas ao invés de minutos. As atividades eram estimadas para mais ou menos 1 semana, ao final de cada semana os cartões finalizados eram contados e guardados. No fim da segunda semana foi comparado o total de atividades realizadas em cada semana. Para surpresa de toda equipe havia dezenas de tarefas finalizadas.

As 4 colunas eram bastante para aqueles três primeiras semanas, nesse meio tempo os cartões eram movidas até Done e no fim do dia na sexta contávamos os cartões que foram para Done. Ali, foi a primeira vez que a equipe percebeu que eles eram super-produtivos, o que não tinha acontecido até então é que o trabalho deles não era visível.

Na quarta semana introduzimos simbolicamente um isopor que lembrava vagamente o martelo do Thor. O portador do martelo era responsável em mostrar para os outros da equipe que o tempo para falar e reportar como estava o trabalho estava acabando, ou seja, o portador do martelo era responsável por as pessoas falarem de forma mais objetiva na reunião diária. O martelo simbolicamente ao lado do Kanban para que todos lembrassem de mover os cartões e falar objetivamente. Ao final da quarta semana o tempo das reuniões diárias diminuíram para mais ou menos 20 minutos.

Em um das reuniões diárias eram mais efetiva mas ainda havia o sentimento de que havia ainda muita coisa para fazer, de fato realmente havia quando olhamos somente para equipe. Ao levantar se havia alguma coisa para fazer no qual a organização precisava com urgência, não havia nada que deveria ser priorizado. Este foi o momento em que perceberam que não precisavam mais trabalhar alucinadamente porque a equipe havia encontrado uma cadência de entrega das atividades compatível com a organização.

A equipe finalmente percebeu que poderia trabalhar em coisas novas ao invés de apagar incêndios constantemente. Há dez anos atrás diminuiu o trabalho manual, no que atualmente é chamado de Toil, este foi um marco importante porque a equipe começou a fazer automações de processos e serviços em parte trabalho da semana, assim iniciou-se a implantação de Continuous Delivery, Infraestrutura como Código, etc.

Na quinta semana um dos membros das equipe pesquisou sobre Kanban e viu que uma boa prática seria limitar o WIP em três atividades simultâneas em Doing. Ela levou propôs isso para o restante da equipe que foi aceito prontamente. Além disso, eles também adicionaram uma marcação nos cartões com algum tipo impedimento. Esses impedimentos inicialmente eram levantados na reunião diária ou erra escalado para liderança se o impedimento impactava outras equipes ou toda organização.

Ao final da sexta semana a equipe dispensou minha presença nas reuniões diárias. Isso representou de que eles não precisavam de alguém para ajudar na organização da equipe, eles haviam aprendidos a se auto-organizarem, a tomarem ações por conta própria sem precisar das lideranças dizerem a todo momento o que precisam fazer.

O Kanban foi o método usado para implementar DevOps na equipe de infraestrutura da EBC. Sem ele ou usando outro médoto poderia ter implementado com o mesmo sucesso? Sim, provavelmente.

Não há atalhos para as equipes se comportem de fato como “equipes”, como elas podem ser tornar autônomas. O Kanban foi um importante para este caso porque a implantação não impôs métodos ou tecnologias. Partiu-se da situação na qual a equipe estava, realizou-se pequenas evoluções até que a equipe obter por si conhecimento e autonomia.

comments powered by Disqus