Desde o seu início, a Jera adota o Scrum e o Extreme Programming (XP) como forma de gestão. O que nos ajudou a trazer uma mentalidade ágil tanto para os times quanto para a organização.

Porém, no decorrer dos anos, percebemos que os valores, papéis, eventos e artefatos do Scrum e as práticas do XP não eram suficientes para estabelecermos um processo adequado a nossa forma de desenvolver.

Em 2017, começamos a experimentar as práticas do Método Kanban em nossos times Scrum e aos poucos chegamos ao modelo de gestão que utilizamos hoje. Aplicamos as seguintes práticas:

1. Visualizar o trabalho
2. Limitar o trabalho em progresso
3. Gerenciar o fluxo
4. Políticas explícitas
5. Ciclos de feedback
6. Melhorar colaborativamente, evoluir experimentalmente

O Pair Programming é uma das práticas de Extreme Programming que utilizamos na Jera.

1. Visualizar o trabalho

A prática de visualizar é importante para deixar o trabalho evidente, não à toa, a transparência é um pilar do Scrum. A visualização é um chamado para a colaboração e traz à tona os gargalos e o trabalho até então escondido. Ela permite também ver qual demanda é mais importante, qual está preparada para puxar, qual está em andamento e qual está entregue.

A ferramenta que utilizamos para fazer a gestão do quadro é o Trello, até mesmo quando estávamos trabalhando presencialmente. Nele identificamos as fases do fluxo: onde a demanda entra (Entrada), a priorização (Para fazer), o ponto de comprometimento (Fazendo ou Em progresso), onde é a entrega (Feito) e quem é o responsável por ela. Abaixo segue um exemplo de um quadro do nosso time.

Outro ponto importante é deixar visível os tipos de itens de trabalho (demanda) e a tecnologia a ser desenvolvida. No Trello, utilizamos o recurso de etiquetas para evidenciar, como pode ser visto na imagem abaixo.

2. Limitar o trabalho em progresso

Esta prática é a engrenagem que gera o sistema puxado, fazendo com que o ritmo de trabalho seja sustentável. Dessa forma, o acúmulo de demandas é controlado e a entrega é contínua.

Utilizamos duas formas de limitar o trabalho em progresso: por horas e por fase.

Na limitação por horas, colocamos um teto de horas por sprint. O teto corresponde a 80% de uma sprint. Se uma sprint tem 40 horas o teto será de 32 horas. Nas reuniões de planejamento (Sprint planning), o time estima as demandas até chegar ao limite de horas.

E na limitação por fase, colocamos um limite por célula na etapa “Em dev” e “Em validação”. Cada célula tem entre um a três desenvolvedores.

Uma dica valiosa para quem usa o Trello é utilizar o power up “Limites da lista”. Nele você define o limite por fase e ele sinaliza quando é ultrapassado o limite, como na imagem acima.

3. Gerenciar o fluxo

O objetivo de gerir o fluxo de trabalho é fazer com que as demandas sejam entregues no menor tempo possível.

Para isso, em nossas diárias (Daily Scrum) olhamos o quadro da direita para esquerda, a fim de definir estratégias para darmos vazão às demandas que estão mais próximas de serem entregues. Outra prática que auxilia na entrega contínua, é não voltarmos a demanda para fases anteriores, caso ela esteja bloqueada, paramos para resolver ela na etapa em que está.

Para verificar a saúde do fluxo e ter previsibilidade, utilizamos de métricas de eficiência, as principais são: Tempo de espera (Lead time), Taxa de entrega (Throughput) e Diagramas de fluxo (Cumulative Flow Diagram ou CFD).

4. Políticas explícitas

Políticas explícitas permitem novos membros entenderem rapidamente como o time trabalha e auxiliam quando algum acordo precisa ser relembrado.

As políticas ou acordos emergem de discussões entre o time, seja em retrospectivas ou em conversas do dia a dia. Incentivamos o diálogo aberto para que os problemas sejam levantados e acordos sejam definidos pelo time.

Cada política acordada é documentada no nosso quadro ou em algum local que todos acessem com frequência. No Trello, temos uma coluna para os acordos do time, como no exemplo abaixo.

As principais políticas do nosso time são: definição de preparado (DoR) e pronto (DoD), informações necessárias em uma demanda, transição de demandas, tratamento de demandas urgentes, horários de reunião, responsabilidades e limites de trabalho em progresso.

Para quem utiliza o Trello, uma dica para explicitar as políticas de transição de demandas é criar um card em cada fase e deixá-lo no topo, como no exemplo abaixo.

5. Ciclos de feedback

Os ciclos de feedback são o momento em que o time para o que está fazendo para analisar qual o melhor passo a ser tomado. Muitas vezes ficamos presos às demandas e não olhamos estrategicamente o que estamos entregando e como estamos entregando.

Nossos ciclos são os eventos Scrum: planejamento, diária, revisão (Sprint review) e retrospectiva.

No planejamento reabastecemos o fluxo conforme a nossa capacidade, como falei anteriormente. A diária é a reunião estratégica para o time se organizar. A revisão e a retrospectiva, o momento de colhermos feedback e melhorarmos nosso processo de entrega e checarmos se estamos atingindo o objetivo do produto.

6. Melhorar colaborativamente, evoluir experimentalmente

Um dos princípios do Kanban é “Concorde em buscar a melhoria através da mudança evolutiva”. Ele é importante para que não façamos grandes mudanças, aumentando o risco de não alcançarmos uma melhoria efetiva. A prática aqui é o time acordar em realizar pequenos experimentos e compararmos com o estado anterior se melhoramos ou não.

Na Jera, incentivamos os times a realizarem experimentos. Nas retrospectivas, olhamos para as métricas para discutirmos e propor ações de melhoria. Estas ações podem ser pontuais, acordos ou experimentos. E a cada ciclo revisamos para ver se mantemos a mudança ou não.

Referências

O livro do David Anderson, criador do método.

Se você quer uma versão resumida e ilustrada, tem a versão feita pelo Pawel Lewinski, Jakub Drzazga e Marcin Biedron.

Se você quer uma versão mais resumida ainda, tem o Guia oficial do Kanban de 2021.