Kanban vs. Scrum: que tipo de ágil é você?

Resumo: kanban é uma estrutura de gestão de projetos que conta com tarefas visuais para gerenciar fluxos de trabalho, enquanto o scrum é uma estrutura de gestão de projetos que ajuda as equipes a estruturar e gerenciar o trabalho por meio de um conjunto de valores, princípios e práticas.

A metodologia ágil é um conjunto de ideais e princípios que serve como guia para a gente. O DevOps é um conjunto de práticas que automatizam e integram os processos entre equipes de desenvolvimento de software e de operações. Quando se trata de implementar agilidade e DevOps, o kanban e o scrum oferecem formas diferentes de fazer isso.

É fácil apontar as diferenças entre práticas Scrum e Kanban, mas isso é apenas superficial. Embora as práticas sejam diferentes, os princípios são em grande parte os mesmos. Ambas as estruturas vão ajudara a criar melhores produtos (e serviços) com menos complicações.

Continuando:

A metodologia ágil é uma abordagem estruturada e iterativa à gestão de projetos e ao desenvolvimento de produtos. Ela reconhece a volatilidade do desenvolvimento de produtos e proporciona uma metodologia para equipes auto-organizadas responderem à mudança sem perder o rumo. Hoje, a metodologia já nem é mais uma vantagem competitiva. Ninguém pode se dar ao luxo de desenvolver um produto por anos ou, mesmo meses, em uma caixa preta. Isso significa que acertar é mais importante do que nunca.

Kanban tem a ver com visualizar o trabalho, limitar o trabalho em andamento e maximizar a eficiência (ou fluxo). As equipes Kanban têm como foco a redução do tempo que leva para o projeto (ou história do usuário) ir do início ao fim. Para alcançar esse objetivo, elas usam o quadro Kanban e melhoram sempre o fluxo de trabalho.

As equipes de Scrum se comprometem a concluir um incremento de trabalho, que pode ser enviado, por meio de intervalos definidos, chamados de sprints. O objetivo é criar ciclos de aprendizagem para reunir e integrar com rapidez o feedback dos clientes. As equipes Scrum adotam papéis específicos, criam artefatos especiais e realizam cerimônias regulares para manter o avanço das coisas. O Scrum é definido melhor no Guia Scrum.

Seja qual for a estrutura da gestão de projetos que funcione melhor para você, a gente tem templates do Jira para ajudar você a começar a trabalhar mais rápido. Confira o template do Scrum ou o template do quadro Kanban. Os dois são gratuitos.

Com o Scrum, sua equipe promete lançar algum incremento valioso de trabalho até o final de cada sprint. Scrum é construído sobre o empirismo, focando pequenos incrementos de trabalho que vão ajudar na aprendizagem com seus clientes e informar melhor o que você deve fazer em seguida. Veja como ele é dividido:

O Scrum se move rápido, com sprints que costumam durar entre uma e quatro semanas, com datas claras de início e término. O período de tempo curto força a divisão de tarefas complexas em histórias menores e ajuda a equipe a aprender rápido. Uma questão importante é: a equipe consegue lançar código utilizável tão rápido?

Sprints são pontuados pelas reuniões de planejamento de sprint, revisão de sprint e retrospectiva e com encontros de Scrum diários (reunião rápida). Essas cerimônias de Scrum são leves e têm funcionamento contínuo.

O Scrum tem três funções definidas com clareza.

• O proprietário do produto defende o cliente, gerencia o backlog do produto e ajuda a priorizar o trabalho feito pela equipe de desenvolvimento.
• O mestre de Scrum ajuda a equipe a não se desviar dos princípios do Scrum.
• A equipe de desenvolvimento escolhe o trabalho a ser realizado, fornece incrementos e demonstra responsabilidade coletiva.

Quem gerencia a equipe de Scrum? Ninguém. As equipes Scrum são auto-organizadas e todos são iguais, apesar de ter responsabilidades diferentes. A equipe está unida pelo objetivo de agregar valor aos clientes.

As métricas do scrum são pontos de dados que as equipes de scrum podem usar para melhorar a eficiência e a efetividade. Eles podem informar a tomada de decisões e ajudar as equipes a se tornarem mais eficientes no planejamento e na execução. Durante a fase de planejamento do sprint, as equipes podem usar métricas como objetivos do sprint, velocidade da equipe, capacidade da equipe e tipo de trabalho. Durante as reuniões rápidas, as equipes também podem se beneficiar da medição de progresso em relação aos objetivos do sprint revisando um burndown do sprint, entendendo a distribuição da carga de trabalho e muito mais.

As equipes se esforçam para entender o quanto elas podem realizar dentro dos limites de tempo do sprint. Elas se comprometem com uma entrega dentro de um sprint. No entanto, as equipes de scrum podem receber feedback de clientes, que as incentiva a mudar de direção e alterar o sprint para entregar maior valor ao cliente. Durante a retrospectiva de sprint, as equipes Scrum devem discutir como limitar a mudança no futuro, pois as alterações colocam o incremento que pode ser entregue em risco. Se uma equipe muda com frequência o escopo no meio de um sprint, isso pode significar que o trabalho selecionado não foi compreendido como deveria ser. Também pode significar que a equipe tem trabalho operacional/não planejável que interfere no plano.

Para mais informações sobre metodologias Scrum veja O que é o Scrum?

Kanban ajuda a visualizar seu trabalho, limitar o trabalho em andamento (WIP) e mudar com rapidez o trabalho de "Fazendo" para "Concluído".

Kanban é ótimo para equipes que recebem muitas solicitações que variam em prioridade e tamanho. Enquanto os processos Scrum exigem alto controle sobre o que está no escopo, Kanban permite que você siga o fluxo. Vamos dar uma olhada nas mesmas cinco considerações para ajudar na sua decisão.

Kanban é baseado em uma estrutura de fluxo de trabalho contínuo que mantém as equipes ágeis e prontas para se adaptarem às prioridades em mudança. Os itens de trabalho, representados por cartões, são organizados em um quadro Kanban onde fluem de um estágio do fluxo de trabalho (coluna) para o próximo. Os estágios comuns do fluxo de trabalho são A fazer, Em andamento, Em revisão, Bloqueado e Concluído. Mas isso é chato.

A melhor parte do Kanban é criar colunas personalizadas para o funcionamento da sua equipe. Minha equipe lança conteúdo, então as colunas (simplificadas) vão de Backlog a Priorizado, Esboços prontos, Escrita, Design, Revisão técnica e Enviado. O quadro ajudou a identificar que a gente lança cerca de um conteúdo por semana e onde os gargalos estão (de olho na Revisão técnica!).

No Kanban, as atualizações são liberadas sempre que estiverem prontas, sem uma programação regular ou datas de vencimento predeterminadas.

Em teoria, o Kanban não prescreve um tempo fixo para entregar uma tarefa. Se a tarefa for concluída mais cedo (ou mais tarde), ela pode ser lançada conforme necessário sem ter que esperar por um marco de lançamento, como revisão de sprint.

Toda a equipe é dona do quadro Kanban. Algumas equipes alistam um treinador de "ágil", mas, ao contrário do Scrum, não há um único “mestre de Kanban” que mantenha tudo funcionando sem problemas. É da responsabilidade coletiva de toda a equipe colaborar e entregar as tarefas no quadro.

Tempo de espera e tempo de ciclo são métricas importantes para equipes Kanban. A questão com a quantidade média de tempo que leva para uma tarefa mover do início ao fim. Melhorar os tempos de ciclo indica o sucesso das equipes Kanban.

O Diagrama de Fluxo Cumulativo (CFD) é outra ferramenta analítica usada pelas equipes Kanban para entender o número de itens de trabalho em cada estado. Os CFDs ajudam a identificar gargalos específicos que precisam ser resolvidos para uma melhor taxa de transferência.

Outra maneira de lidar com gargalos é por meio dos limites de WIP (trabalho em andamento). Um limite de WIP delimita a quantidade de cartões que podem estar em uma coluna ao mesmo tempo. Quando você atinge o limite de WIP, ferramentas como o Jira limitam essa coluna, e a equipe concentra os esforços no avanço desses itens.

Um fluxo de trabalho Kanban pode ser alterado a qualquer momento. Itens de trabalho novos podem ser adicionados ao backlog e os cartões existentes podem ser bloqueados ou removidos com base na priorização. Além disso, se a capacidade da equipe for alterada, o limite de WIP pode ser recalibrado e os itens de trabalho ajustados conforme o necessário. No Kanban deve haver flexibilidade.

Para obter mais informações sobre metodologias Kanban, consulte O que é o Kanban?

A comunidade ágil acredita que esta conversa não deve ser sobre as ferramentas. Muitas vezes, vemos a ferramenta escolhida influenciando a escolha da estrutura, que por sua vez influencia os princípios adotados pela equipe. A gente acredita que a decisão deve fluir para o outro lado.

Depois de implementar os princípios de Scrum e terminar de criar a estrutura do Scrum, você precisa encontrar uma ferramenta boa. O mesmo vale para o Kanban. Somos suspeitos para falar, mas como oferecemos a ferramenta de software mais usada por equipes ágeis, acreditamos que o Jira é perfeito para você.

Com os tipos de projetos dedicados do Jira para Scrum e Kanban, você coloca em prática os princípios de cada estrutura. Para ajudar você a começar, confira também nossos guias sobre como usar o Scrum com o Jira e como usar o Kanban com o Jira.

Scrum e Kanban são "ágeis por definição". O trabalho é comprovado e verdadeiro, então fica difícil argumentar contra. Segundo uma frase famosa, dá para dizer que "ninguém é culpado por escolher o scrum".

Mas essa decisão não precisa ser tão rígida. Centenas de equipes estão usando modelos híbridos influenciados pelo Scrum e Kanban. Como nosso compromisso é ajudar as equipes a fazerem isso no Jira, criamos os projetos gerenciados pela equipe.

Projetos gerenciados pela equipe, como o nome sugere, permitem que as equipes escolham as funções ágeis que fazem sentido para eles; seja scrum, kanban ou uma mistura dos dois. Em vez de implementar uma estrutura no primeiro dia, os projetos gerenciados pela equipe permitem que você acrescente funções cada vez mais poderosos à medida que aprende o que funciona para a equipe (e o que não funciona).

Você pode escolher com confiança Scrum gerenciado pela equipe ou Kanban gerenciado pela equipe, sabendo que ambos os templates podem evoluir para atender às necessidades da equipe.

Seja qual for a escolha, fique com ela por um tempo. Pegue algum trabalho do backlog e siga até o fim. Depois pergunte à equipe o que deu certo e errado. Ao testar Scrum e Kanban e fazer essas perguntas, você está no caminho certo da felicidade ágil.