Do Scrum para o Kanban: quais são os desafios dessa transição?

Ampliamos a utilização do método Kanban, com o objetivo de gerar mais fluidez na entrega de valor para os nossos clientes. Nesse período aprendemos muito e gostaríamos de compartilhar essas experiências com você que pensa em transitar do Scrum para o Kanban ou que já vive essa mudança.

Por REINALDO SIMIZU

 

O framework Scrum teve papel fundamental no estabelecimento da cultura ágil, porém algumas restrições do modelo como timebox e estimativas, começaram a limitar nosso fluxo. Começamos então a transição nos times, adotando a abordagem evolucionária do Kanban.

 

Caso não conheça o método, convido você a ler o post Método Kanban – Primeiros passos, onde esclarecemos os principais conceitos e princípios.

 

Na Matera o contexto da maioria das equipes era esse: para cada equipe responsável por um produto tínhamos 2 times: um time de suporte responsável por demanda de falhas (sem método específico) e outro por evoluções (Scrum). Essa informação é importante porque agora com Kanban unificamos os times e passamos a tratar demandas de falha e valor no mesmo fluxo.

 

Optamos por iniciar o trabalho em equipes com cenário externo mais estável, sem promessas de entrega no curto prazo e com o analista de negócios bem próximo ao time. Apesar desses fatores não serem premissa, eles contribuem para um início menos conturbado.

 

Definimos um quadro Upstream para os Analistas de Negócio e Arquitetos analisarem as demandas e quando atingiam um estado de DoR eram quebrados em entregáveis e encaminhados para o quadro de Delivery para o time de desenvolvimento (DEVs  + QAs).

 

Como nossos times são distribuídos (multi-site), utilizamos o quadro digital para visualização do fluxo, o que também facilita a coleta das métricas.

 

Scrum Master morreu?

 

No Kanban temos o papel do Service Delivery Manager (SDM) com foco em gerenciar o fluxo de trabalho, contrariando o modelo comando-controle que decide o que as pessoas devem fazer. O Scrum Master precisou expandir seus conhecimentos para aprender o método Kanban e assim atuar como SDM.

 

Ele tem grande importância nessa virada, justamente porque o método é pouco prescritivo e é importante que ele direcione a intensidade das mudanças de acordo com a maturidade do time. Por exemplo, reforçando os princípios e práticas para que não haja dúvidas, encontrando o melhor momento para introdução das práticas, como o limite de WIP e optando por tratar as restrições mais significativas junto ao time.

 

Desafios

 

O cartão

 

Nas sprints, os cartões no quadro representavam micro-tarefas que percorriam as etapas do processo.

 

Esse foi um primeiro desafio na definição do backlog do kanban Downstream, definir coerentemente o que cada cartão simbolizava, já que para as métricas não faz sentido comparar laranja com banana.

 

Explico melhor. Não poderia ter um cartão representando a criação de uma coluna na tabela e outro uma funcionalidade inteira, isso criaria distorções nas medições e a previsibilidade seria comprometida.

 

Criamos então uma política explícita onde o cartão representa sempre uma entrega de valor, ou seja, algo que o cliente final consiga validar e utilizar.

 

Planning, ainda tem?

 

Sim, mas não com esse nome e formato. A cadência onde o time entende O QUÊ e COMO fazer tem o nome de Replenishment no Kanban. A diferença é que dentro de um sistema puxado, ela ocorre quando o time solicita nova atividade para Negócios, ou seja, a cadência não é fixa.

 

O formato também pode variar e o time deve entrar no consenso de quem deve participar. Funcionalidades básicas, só o dev e o QA mais aptos para a tarefa participavam. Funcionalidades sistêmicas, convidávamos o time pois a visão crítica do grupo colaborava para análise de riscos e impactos, além de capacitar o grupo.

 

As primeiras foram complicadas principalmente para os QAs, porque tinham que interromper os testes em um assunto para ter foco em outro, mas com o tempo encontramos momentos melhores para sincronizar e não gerar muita troca de contexto.

 

O analista de negócios passou a acompanhar mais de perto o fluxo das atividades, porque a medida que as atividades caminhavam, ele já cuidava do reabastecimento da fila.

 

Lei de Parkinson

 

“O trabalho expande-se de modo a preencher o tempo disponível para sua realização.” C. N. Parkinson

 

Esse é uma das principais deficiências do Scrum, forçar que o mundo tenha que ser redefinido em timeboxes fixos. O número de sprints que terminavam antes do prazo raramente superava as que falhavam ou terminavam na data. Isso ratifica a lei de Parkinson. Enquanto tivermos tempo disponível, provavelmente vamos preenchê-lo revisando ou gerando baixo valor agregado.

 

E como foi isso na prática?

 

Na classe de serviço padrão, onde não havia um prazo final estabelecido, as tarefas começaram a demorar mais que anteriormente.

 

Relaxamento por não ter o prazo? Talvez.

 

O que constatamos foi a ausência de um critério mais claro e objetivo de Definition of Done. Uma vez que essa política foi melhor definida, as tarefas passaram a ter a clareza de quando estariam prontas, com a qualidade esperada, sem preciosismo. Testar aquém do necessário é um problema, mas além de certo ponto é desperdício e pode sinalizar falta de critério. O prazo final não deve ser o único critério de fim da sua atividade.

 

Nas retrospectivas, para essa questão, analisamos métricas de dispersão de leadtime e eficiência de fluxo que nos ajudam a identificar tendência de evolução ou regressão nas entregas e se existe ineficiência.

 

Métricas

 

Toda previsibilidade de entregas tem como base o registro das métricas coletadas. Confiar nos dados reforçam o mindset de não depender de feeling para tomada de decisão.

 

Começamos com Leadtime (Dispersão e Histograma), CFD, Burnup, Throughput e Eficiência de Fluxo e depois de um período de 3-4 meses já tínhamos uma boa amostragem para ter o ritmo do time e previsibilidade das entregas. Confira no post Vamos falar sobre métricas Kanban, onde explicamos com detalhe algumas dessas métricas.

 

Nossas retrospectivas são iniciadas analisando as métricas coletadas, tendências, gargalos e produzem um resultado mais eficaz, vamos direto ao ponto mais problemático sem muitos rodeios.

 

Inspeção

 

Já parou para pensar que você não precisa esperar até o final de um ciclo para conversar sobre algum problema, ou refletir com o time sobre algum insight para melhorar o processo?

 

Quando começamos a aplicar o método Kanban, nossas retrospectivas (sim, mantivemos o nome sem trauma algum) aconteciam a cada 2 semanas, mas depois passamos a ajustar conforme necessário. Geralmente uma entrega mais significativa ou problemática, algum insight ou novas demandas que seriam interessantes ter o risco avaliado, são bons motivos para a cadência de inspeção.

 

Os benefícios

 

A unificação das equipes e adoção do método Kanban trouxe uma série de benefícios, além dos citados acima, ressalto alguns:

  • Time com atitude de dono. A fluência depende da redução de retrabalho nas etapas do processo. No fluxo contínuo cada interrupção por falha exige uma troca de contexto e impacta diretamente na vazão e no leadtime dos entregáveis. Seja por erros encontrados internamente ou nas demandas de falha externas que atravessam qualquer planejamento. Como o time é diretamente impactado pelos próprios erros que comete, ganhamos um senso maior de responsabilidade, já que no cenário anterior as demandas de falha eram direcionadas para outra equipe.

 

  • Entregamos mais com Kanban, principalmente por adequar a capacidade correta para a demanda (bastante variável), já que o backlog é dinâmico. Também por estabelecer o limite de WIP adequado no fluxo. Me permita reforçar: tentar encaixar o mundo em caixas de tamanho fixo gera desperdício como custo de coordenação e ociosidade.

 

  • Ganhamos maior flexibilidade para tratar as mudanças de negócios que são vitais nesse cenário de transformação e inovação que vivemos. Tínhamos um custo de coordenação elevado para dimensionar as equipes separadas e o movimento era sempre mais lento que a frequência de mudanças de curso.  

 

Conclusão

 

A adaptação ao método Kanban para quem vem de um framework como o Scrum tem vários desafios e exige um acompanhamento mais próximo de um SDM.

 

Seja utilizando o STATIK (System Thinking Approach to Implement Kanban) ou qualquer outra literatura, é importante respeitar o momento e a maturidade do time, com foco sempre na abordagem evolucionária!

Por REINALDO SIMIZU

Agile Coach e Kanban Management Professional (KMP), atua transformando boas ideias em prática e acredita que a entrega de valor é potencializar e cuidar do maior bem da empresa: pessoas.

Postado em: 02 de julho de 2018

Confira outros artigos do nosso blog

Tudo o que rolou no Agile Brazil 2018!

30 de outubro de 2018

Karina Costa Mineiro

Como a comunicação influencia em times ágeis?

15 de junho de 2018

Ariane Ferreira Izac

Vamos falar sobre métricas Kanban?

21 de maio de 2018

Ricardo Augusto Shikota

Método Kanban: primeiros passos

10 de maio de 2018

João Paulo Grabosque

Deixe seu comentário