PT | EN

Do Scrum para o Kanban

Por 09/04/2020 06/12/2022 5 minutos

Nesta semana realizamos a primeira edição totalmente online do SoftDrops*, espaço no qual nossos colaboradores compartilham conhecimento. Na ocasião, Raphael Rodrigues contou sobre a sua experiência de trabalho em um projeto que migrou do framework Scrum para o método Kanban – que se propõe a analisar o fluxo de valor do trabalho.

O agilista comentou que tal necessidade surgiu após alguns apontamentos, tanto do time com afirmações como “não podemos homologar, falta o ambiente”, quanto dos gestores que questionavam o motivo das iniciativas demorarem para mudar de status. Para apresentar a proposta de evolução e explicar como essa mudança ocorreu, Raphael descreveu alguns dos entraves experimentados a partir de tópicos. Caso você não tenha familiaridade com o método Kanban, recomendamos que você leia esse texto antes de prosseguir.

Problemas que excediam a sprint

Em um determinado momento do trabalho, houve a dificuldade de dar visibilidade aos bloqueios. Isso era perceptível em retrospectivas, por exemplo, quando os times traziam situações que não eram possíveis de resolver para o ciclo seguinte, como problemas de ambiente.

Raphael comentou que isso é comum, pois algumas empresas não costumam realizar a transformação digital em toda a organização. Sendo assim, uma parte dela pode não estar preparada para a velocidade que o time deve ter, ou seja, não pensando de maneira incremental. Nesse sentido, o Kanban torna transparente o trabalho que está sendo feito, permitindo que limitações e gargalos possam ser identificados e abordados.

O time-box da sprint parou de fazer sentido

O agilista comentou que, outro problema estava relacionado aos incidentes, pois os times acabavam focados neles, dificultando o planejamento das sprints e impedindo a evolução do trabalho da equipe. Aplicando o Kanban, as demandas foram separadas por classes de serviço, o que permitiu a priorização de tarefas.

“Dessa forma, não era necessário realizar uma planning, reunião para planejar uma sprint. Isso ocorre por ser um fluxo contínuo em um sistema puxado, removendo a necessidade de, por exemplo, parar e avisar um desenvolvedor qual a próxima demanda que precisa ser realizada.

Visibilidade do status das demandas no backlog

Utilizando o Scrum, havia apenas uma lista de tarefas a serem desenvolvidas, e isso dificultava a visibilidade do status real de cada uma delas. “Por exemplo, em uma série de demandas que dependem de outros setores, não é possível demonstrar que a tarefa está pendente por uma razão externa. Isso pode criar a percepção de que o time não estava conseguindo absorver a demanda de trabalho ou não está desenvolvendo em tempo hábil”, comentou Raphael.

Para solucionar essa questão, o agilista citou a implementação de um fluxo completo de trabalho, com upstream e downstream, onde era possível tentar observar as dependências de outras áreas, esclarecendo demandas que precisavam ser aprovadas pelos demais setores. O modelo de fluxo de trabalho completo propõe um funil de ideias, permitindo que o gestor da área identifique gargalos fora do time, que estão impedindo o desenvolvimento de uma tarefa.

Falha nas estimativas de tempo

As estimativas de tempo e prazos de entrega também representavam um entrave, pois dificilmente eram apuradas – como por exemplo, devido a dependência de outros setores, como falado anteriormente. “No Scrum, quando pensamos em complexidade, pensamos somente no esforço de desenvolvimento ou de testes, mas não contabilizamos o tempo de espera ao aguardar um teste ou um deploy, por exemplo. Ou seja, não observamos a eficiência do fluxo”, disse Raphael. Para começar a solucionar essa questão, o primeiro passo é limitar o WIP – Work in Progress.

Ou seja, o número de demandas foi limitado para cada coluna no Kanban, permitindo a entrada controlada de tarefas em cada uma delas. Após essa limitação ter sido realizada, o agilista passou a observar as métricas de WIP, Lead Time e Throughput, possibilitando a análise e compreensão da performance do time.

Ferramenta para estimar o tempo de entrega

Ao relatar a transição do Scrum para o método Kanban, Raphael falou ainda sobre o Jira, ferramenta que pode auxiliar na mensuração da entrega de uma demanda, a partir da análise do histórico das tarefas realizadas pela equipe. A aba que apresenta o Control Chart faz a estimativa média de tempo, a mínima e a máxima a partir desse histórico. Tais dados trazem insights importantes para a realização de melhorias no fluxo de delivery, fornecendo uma noção de previsibilidade, com margem de confiança.

Outro gráfico no Jira que pode ser utilizado é o Burnup, que analisa o fluxo de criação de demandas e o fluxo de tarefas finalizadas. Dessa forma, é possível estimar o tempo de conclusão de uma versão de produto, por exemplo.

*O SoftDrops é um evento de troca de conhecimento que acontece todas as quartas-feiras, na sede da SoftDesign. A cada semana, um colaborador se predispõe a expor para os colegas algum tema de seu interesse, que tenha relação com os três pilares do nosso negócio: design, agilidade e tecnologia. A minipalestra dura em torno de trinta minutos e é seguida por um bate-papo entre os participantes.

Foto do autor

Cecilia Ribeiro

Product Manager, formada em Jornalismo pela Universidade Federal do Rio Grande do Sul (UFRGS). Com sólida experiência na Gestão de Marketing de Produto e Estratégia.

Posts relacionados

22 de agosto de 2023

Gestão Ágil: impulsione a Transformação Digital da sua empresa

    Agilidade
Saber mais

29 de maio de 2023

Métodos Ágeis: Qual o Melhor Para a Sua Empresa?

    Agilidade
Saber mais

14 de fevereiro de 2023

Por Que Sua Empresa Precisa de Business Agility?  

    Agilidade
Saber mais

Quer saber mais sobre
Design, Estratégia e Tecnologia?