Jogando um Novo Jogo — Diário de Bordo de uma implantação de Kanban
Enquanto coordenador de um time ágil, o cenário que vou abordar neste artigo apresentou-se como uma oportunidade para experimentar uma nova proposta de entrega através de uma abordagem de gamification que vai ficar mais clara ao longo deste diário de bordo.
Primeiramente, é sempre importante começar pelo “porquê” — e este é um resumo das necessidades que sugiram para o time:
1. Apesar de já virmos trabalhando com Scrum há um tempo, uma nova demanda deixou o time em estado de alerta. Se tratava de uma entrega sem precedentes similares e que tinha um milestone de lançamento diretamente ligado a um momento específico do mercado, pois seria naquele período que a solução entregaria o benefício esperado ao cliente com o maior impacto (ou seja, precisaríamos garantir a entrega da demanda dentro daquele prazo específico). Mesmo sendo possível quebrá-la em histórias menores, como poderíamos estimar de forma segura o quanto seria entregue ou o esforço necessário, uma vez que não haviam sido desenhadas soluções semelhantes em entregas anteriores?
2. Havia também diferentes tipos de demandas que paralelizariam a capacidade da sprint e não poderiam ser postergadas para a sprint seguinte, como erros emergenciais de produção e pequenas melhorias no produto, aumentando ainda mais a incerteza do lote de trabalho com o qual o time precisaria se comprometer no sprint planning.
A experimentação:
Sugeri, então, trazer para o time um experimento em que tentaríamos uma nova abordagem: trabalhar em um sistema puxado, seguindo o modelo do método Kanban. Dessa forma, as estimativas e predições, assim como a análise de risco em relação às expectativas das partes interessadas, seriam fornecidas por dados observacionais da base histórica — enquanto o foco do time seria a entrega cadenciada e através das camadas de empirismo envolvidas, por meio de uma agenda de trabalho sustentável com base em nossa capacidade.
Debati o Kanban com o time como “um método para definir, gerenciar e melhorar serviços que entregam trabalho de conhecimento, usando um sistema de entrega orientado a fluxo, por meio de gerenciamento visual, limitando o trabalho em andamento e buscando o desenvolvimento de uma melhoria evolutiva a partir de seu estado atual”.
Entretanto, não tínhamos tempo hábil naquele momento para nos dedicarmos intensivamente à realização de uma etapa de treinamento do time focando na transição de Scrum para Kanban — então, partindo da premissa do “Comece pelo que você já tem, e crie sua melhoria evolucionária a partir deste ponto”, adotei a seguinte abordagem com o time: “Pessoal, vamos rodar este experimento como um novo jogo, uma abordagem de gamificação, em que, a cada dia, somente uma nova regra será colocada — e só se a necessidade dela for comprovada e fizer sentido para vocês”.
Entendo a necessidade de uma abordagem sistêmica para a implantação de um método como Kanban, principalmente com o uso de uma ferramenta essencial, chamada STATIK (System Thinking Approach to Introduce Kaban), em que é importante identificar o tipo de serviço que está sendo entregue, o propósito do produto e valor entregue, os pontos de insatisfação das partes envolvidas com este fluxo, uma análise da demanda e da capacidade para, então, você dar visibilidade ao fluxo atual para os tipos de demandas e classes de serviço. Neste caso, o time já estava acostumado com o fluxo de entrega do Scrum, o projeto já tinha um ano, e imaginei que uma abordagem de gamificação seria uma ótima forma de experimento na transformação do sistema e, ao mesmo tempo, no treinamento do time no modelo. Isso tudo durante a execução do trabalho e, principalmente, orientado a dados observacionais que deixassem claro o sentido e necessidade daquele processo para o time, ajudando a entender melhor o método e mantendo o foco na entrega de valor.
Diário de Bordo da introdução a este novo jogo:
Dia 1 — Kanban Meeting
A primeira nova regra do nosso jogo seria: Vamos realizar nossa daily olhando para o quadro e vamos responder: “O que nos impede de seguir adiante no fluxo das atividades em andamento hoje?”
No primeiro dia, propus ao time que a primeira regra do jogo fosse a visualização do “Trabalho em Andamento” (do inglês “Work in Progress” ou WIP) de forma a fazermos a nossa daily olhando para o quadro como um reflexo do fluxo atual das atividades de valor que estávamos tentando entregar, as histórias de usuário, bugs e melhorias que compunham o nosso WIP naquele momento. Partindo desta premissa, a proposta seria seguirmos a daily respondendo sobre o que precisamos fazer para desbloquear as atividades em andamento, para que elas pudessem seguir para o próximo estágio do fluxo de entrega e, desta forma, colaborássemos com a entrega do time como um todo e a gestão do sistema.
Também expliquei que, conforme as regras fossem sendo aplicadas, poderíamos chamá-las de “políticas explícitas” do nosso time, assim elas ficariam claras e transparentes para todos os participantes, como um manual de um jogo.
Dia 2 — Leitura da Esquerda para a Direita
Fez sentido passarmos a fazer a daily olhando para o quadro, de forma a focar no trabalho em andamento, mas percebemos que, na maior parte do tempo, estávamos discutindo os bloqueios dos itens que não iriam ser entregues naquele momento — enquanto os itens já próximos da entrega, nas fases de validação de qualidade, estavam parados com correções necessárias e bloqueios encontrados. Observamos, juntos, a necessidade de focar primeiro nos itens com os quais estávamos mais próximos de entregar valor ao cliente e, partindo daí, seguir a leitura dos demais itens de trabalho. Desta forma, foi proposta a adoção de uma nova política: a leitura do nosso quadro seria feita da direita para a esquerda, de forma que discutiríamos primeiro os cards mais próximos da coluna de “entregue”, como os itens das etapas de validação da qualidade, e seguiríamos, coluna a coluna, até os itens que tinham acabado de ser atualizados para o estágio de “desenvolvimento em progresso”.
Dia 3 — Limite de Trabalho em Progresso
Agora que estávamos usando o quadro como ferramenta para a priorização e gestão do fluxo de trabalho, encontramos, no terceiro dia, outra situação que precisaríamos discutir se haveria a necessidade de ser trabalhada.
Uma grande quantidade de itens estava sendo iniciada simultaneamente, lotes grandes de várias histórias estavam sendo mandados de uma só vez para as etapas de revisão de código e de validação de qualidade, de forma que, quanto mais à direita do quadro, mais gargalos se acumulavam no fluxo — ou seja, menos itens e, principalmente, menos valor era de fato entregue ao cliente do que tínhamos a capacidade de entregar.
Isto evidenciou para o time a necessidade de limitarmos o trabalho em progresso (WIP) em cada etapa do nosso quadro Kanban e que, com a redução deste, os itens de trabalho atravessariam mais rápido o nosso quadro. Pode parecer contraintuitivo de início, mas existe um conceito chamado lei de Little que fala sobre a relação proporcional entre as médias da vazão, da quantidade de itens na fila e do tempo de atravessamento em sistemas de fluxo, ou seja, para otimizar o tempo de entrega podemos reduzir a quantidade de itens que deverão ser trabalhados.
Para contextualizar melhor, mostrei ao time uma das ferramentas que estava usando para acompanhar nosso processo de entrega, em substituição ao nosso burndown: um CFD (sigla em inglês para “Diagrama de Fluxo Cumulativo”), que é um gráfico cumulativo da quantidade de itens que chegam e saem de um sistema em uma sequência de tempo.
Entendendo a necessidade, definimos uma política de limite de trabalho em progresso (WIP) para cada uma das etapas do fluxo e fizemos o acordo de respeitar esta regra, de forma que, caso algumas das colunas possuíssem o número máximo permitido de itens nelas, iríamos colaborar mais intensamente para que algum item fosse movido para a etapa seguinte e, com isto, liberasse um slot para que outra atividade pudesse entrar na coluna em questão. Por exemplo: o desenvolvedor terminou a revisão do código e precisa passar o item para a etapa “teste”, mas as atividades em teste já preenchem todo o limite de WIP. Nesse caso, ao invés de simplesmente puxar mais uma história para “teste” e gerar um gargalo, o time se auto-organizaria para ajudar na validação de qualidade e liberar um espaço para um novo item de trabalho ser enviado para esta etapa.
Dia 4 — Definição de Classes de Serviço
No quarto dia, conversando com o time pela manhã, observamos que os tipos de trabalho que estavam em nosso ciclo de entrega não eram exatamente iguais e, principalmente, seguiam necessidades de priorização do trabalho distintos. Essas necessidades iriam variar de acordo com o custo que o atraso em uma entrega poderia gerar: havendo itens de bugs de maior criticidade que precisariam ser resolvidos no menor tempo possível para mitigar riscos para a confiabilidade da aplicação, melhorias na solução atual que precisariam ser entregues assim que possível, além de uma solução responsiva que o time estava construindo com base em uma relativa camada de empirismo, e cuja aplicação, como mencionado anteriormente, estava atrelada a uma data de entrega fixa devido a um lançamento oficial no mercado e um ciclo de valor em que a maior parte do benefício seria alcançada no início do referido lançamento.
Com base nestes fatores, fez sentido para o time tratar os diferentes tipos de trabalho de formas visualmente distintas em nosso quadro. Então, apresentei para eles o conceito de classes de serviço (que são justamente as diferentes características de demandas e suas políticas) e as diferentes classificações que os itens poderiam assumir pelos custos do atraso que trariam para o valor proposto. Com base nessa reflexão, separamos estas classes em raias: os bugs urgentes acordamos incluir em uma raia chamada “expedite”, e a política explícita seria tratá-los dentro do menor tempo de entrega possível, porém sustentável. Também acordamos que regras como limite de WIP não seriam válidas para esta raia; os itens relativos a entregas com data fixa de lançamento, classificamos como “fixed date”; e as demais melhorias entraram em uma raia padrão. Com esta classificação, ficou mais fácil a auto-organização do time para focar no item certo no momento certo, mantendo um fluxo de entrega contínua de valor.
Dia 5 — Fluxo Unidirecional
No quinto dia de trabalho, compartilhei com o time como estava a nossa gestão de fluxo. Observamos como, algumas vezes, havia uma percepção de vazão nas colunas, mas não tínhamos itens realmente sendo entregues. Algumas vezes, o limite de WIP travava o fluxo, mesmo sem novos itens serem adicionados no quadro. Havia uma dificuldade maior em responder sobre o tempo de ciclo em cada etapa, e pude apresentar também algumas ondas anômalas no CFD que reforçavam estas percepções. Até aquele momento, eu não havia feito nenhuma consideração sobre a direção do fluxo de trabalho — naturalmente, o fluxo seguia da esquerda para a direita, até devido à ordenação das colunas no quadro. Mas, ocasionalmente, itens voltavam, causando as assimetrias que observamos — entretanto, não havia uma política explícita sobre isto até então. Com certeza faria mais sentido ter apresentado uma sugestão sobre o tema desde quando acordamos em adotarmos o limite de WIP e direção da leitura do quadro, mas, com o objetivo de gerar evidências palpáveis desta necessidade para o time, deixei que rodássemos sem restrições quanto a esta questão.
Observadas, então, as evidências apresentadas, o próprio time inferiu a necessidade de o fluxo ser o mais unidirecional possível, de forma que um bloqueio em uma etapa do fluxo deveria permanecer como tal e ser priorizada a remoção deste impedimento sob o risco de gerar um gargalo no limite de trabalho em progresso, visto que o item, mesmo bloqueado, continuaria a ocupar um slot na coluna em que houvesse o bloqueio, sendo também um reforço à autonomia da equipe para se organizar e tratar estes impedimentos, mantendo um sistema estável de entrega de valor.
Dia 6 — Ciclos de Feedback
No primeiro dia da semana seguinte, discutimos sobre as políticas explícitas e as razões que justificavam a adoção delas, além de outras políticas referentes aos critérios de aceite das etapas de nosso ciclo de entrega. Também conversamos sobre a necessidade de mantermos os nossos ciclos de feedback, para analisarmos as métricas de evolução de nossas entregas e como estávamos progredindo como time, além de como podíamos melhorar de forma evolutiva nosso processo de trabalho.
As principais cadências adotadas naquele momento, além da Kanban Meeting, foram um reabastecimento semanal para entendermos quais itens entrariam no nosso fluxo de entrega daquela semana sem comprometer a capacidade, e limitado pela vazão do próprio time, mantendo o ritmo de sistema puxado das atividades e focando primeiro no trabalho iniciado e entrega contínua de valor. Reforçamos também a realização de retrospectivas a cada duas semanas, nas quais analisaríamos as métricas de gestão de fluxo, como o aging das atividades em andamento, nossa vazão, tempo de ciclo e nosso CFD, assim como as percepções do time, para identificarmos assimetrias e trabalharmos, juntos, ações de melhoria.
Ao longo do mês, nós passamos a atuar cada vez mais confiantes em relação ao método Kanban, entendendo as métricas e as políticas explícitas com as quais estávamos envolvidos e, principalmente, que buscávamos evoluir através dos ciclos de feedback. Ao final, mesmo com a preocupação inicial em relação ao commitment, foram realizadas com sucesso as entregas dos itens de trabalho dentro do tempo necessário para um menor custo de atraso possível. Outro ganho que tivemos foi em relação à previsibilidade e planejamento a longo prazo, pois as métricas geradas por um fluxo mais estável de entrega em sistema puxado permitiram que todo novo projeto requisitado pelo cliente fosse estimado usando medidas da própria base histórica do time, como a vazão e o lead time, sem a necessidade de estimativas mais subjetivas, e permitindo uma resposta rápida com base na previsibilidade de fluxo.
Todos os ganhos acima foram alcançados através dos princípios de visualização do trabalho e dos processos e políticas de uma gestão consciente e auto-organizada do trabalho em progresso e dos ciclos de feedback e melhoria evolucionária por meio do uso do Kanban.
