Quando pensamos em agilidade, entregas curtas de valor e em um ritmo sustentável, um dos principais frameworks que nos veem à cabeça é o Scrum.

O Scrum com as entregas através das sprints, o ritmo das reuniões diárias, as entregas na revisão e os alinhamentos na retrospectiva nos dá uma ideia clara de projeto.

Por outro lado, o kanban nos ajuda a dar visibilidade do fluxo de trabalho, com tudo aquilo que temos a fazer, o que estamos fazendo e o que já fizemos, tendo o conceito de pronto.

Neste artigo iremos fazer da união do Scrum com o kanaban, abordando os conceitos e aplicabilidades do Scrumban.

Um olhar projetizado no Scrum

O framework Scrum nasceu para nos ajudar a gerenciar projetos e entregar produtos nos mais altos padrões de qualidade, de forma contínua, e gerando valor constantemente ao cliente.

Uma das características do Scrum é que ele trabalha muito bem para coisas finitas, como projeto, que tem início, meio e fim.

Vejamos o fluxo do Scrum e façamos uma análise.

O Scrum se inicia com um documento de visão, que fornece uma noção em alto nível de tudo aquilo que o produto irá conter.

Avançando para o backlog priorizado, o framework trabalha para priorizar tudo aquilo que será entregue dentro de um período finito.

Nas sprints, que também são finitas, a depender do tamanho e complexidade do projeto, cada entrega gera um incremento no produto final.

Em cada revisão um entregável de valor acontece e na retrospectiva o time se reúne para analisar o que foi bom e o que pode ser melhorado.

Esse fluxo se repete até que todos os itens do backlog sejam entregues. Isso dá uma visão clara de que estamos falando de algo com início, meio e fim.

O fato de termos essa visão delimitada no tempo nos leva a refletir que o Scrum se aplica muito bem para projetos, que possuem uma característica ímpar de possui início e fim definidos pelo tempo.

Se formos pensarmos em rotinas do dia a dia o framework pode não entregar todo o valor que se espera. Para cada cenário temos que entender qual o melhor método de gestão precisaremos aplicar para obter os melhores resultados.

Um olhar processual no kanban

O kanban nasceu originalmente para resolver problemas ligados ao fluxo de trabalho contínuo, o que descaracteriza totalmente de projeto, realizado no Scrum.

Em sua configuração mais básica, o kanban nos traz três raias para que possamos trabalhar as demandas: a fazer, fazendo e feito, como ilustra a imagem.

O fluxo de trabalho aplicado ao kanban segue um sentido único, da esquerda para a direita, tendo sempre o objetivo de começar a terminar e parar de começar.

Como o fluxo do kanban é contínuo podemos associar que sua aplicabilidade se encaixa melhor para trabalhos contínuos e não a projetos.

Para entendermos melhor a aplicação do kanban, façamos uma análise da imagem com seu fluxo de trabalho.

Para que se possa gerenciar a quantidade de trabalho em progresso (Work In Progress – WIP) é importante que, ao se analisar se um novo card deva ser inserido, uma avaliação do que deva sair primeiro é primordial.

O montar o quadro kanban, os cards podem ser inseridos à medida da necessidade de capacidade do time, mas antes de incluir uma nova atividade, um olhar para o que já está em andamento deve ser realizado.

Importante terminar o que está em andamento para que possamos iniciar uma nova atividade (começar a terminar e parar de começar.

Esse é o fluxo padrão do kanban, que se aplica muito bem para trabalhos contínuos e fluxos que precisam ser gerenciados.

União de Scrum e kanban – Scrumban

A união do framework Scrum às boas práticas do kanban foi idealizada pelos mesmos criadores do Scrum, através do guia do Scrum para times que pode ser baixado gratuitamente no link: https://www.scrum.org/resources/kanban-guide-scrum-teams?gclid=Cj0KCQiA8vSOBhCkARIsAGdp6RTxxoDkP3eSXo00Glwg3jNaFaBN0sFmxedNGckaVhq1aSrBXo8BUWEaAltVEALw_wcB.

O guia nos dá algumas orientações valiosas de como unir esses dois universos para que possamos obter melhores resultados.

Para que possamos ter uma visão mais clara de como usar o Scrunban em nossos projetos, façamos uma comparação desses dois universos com a inclusão do terceiro elemento.

	Kanban	Scrum	Scrumban
Papéis	Sem papéis definidos	PO, SM e Time	Time + papéis necessários
Cerimônias	Não possui	Reunião diária, planejamento da sprint, revisão e retrospectiva	Reunião diária e se, necessário, o planejamento da sprint, revisão e retrospectiva
Fluxo	Contínuo – puxado	Somente executa o trabalho planejado na sprint	Contínuo – puxado. Não existe limitação de trabalho
Artefatos	Quadro kanban	Backlog, quadro de atividades, burndown	Quadro kanban
Estimativas	Não possui	Tamanho de estórias, duração de sprint, release	Fluxo contínuo com estórias do mesmo tamanho
Times	Especializado	Multifuncional	Pode ser especializada
Limites (WIP)	Conforme capacidade de trabalho na etapa	Tamanho de pontos/estórias suportadas em cada sprint	Conforme capacidade de trabalho de etapa
Backlog	Just-in-time	Priorização e estimativa	Just-in-time: as estórias estão sempre prontas para serem puxadas

Através da tabela podemos fazer uma comparação entre o Scrum e o kanban e avançarmos para o Scruban, ressaltando que são orientações e boas práticas.

O kanban puramente não possui o time com papéis, diferentemente do Scrum que possui o Scrum Master, Product Owner e os desenvolvedores. No Scrumban o time será o necessário para gerar as entregas.

As cerimônias, como planejamento de sprint, revisão e retrospectiva só existem no Scrum. Sendo assim o Scrumban pode fazer uso e adaptações.

No kanban o fluxo é contínuo e no Scrum acontece o que precisa para entregar a sprint. Já Scrumban não existe limitação de trabalho, com o fluxo puxado.

No kanban o único artefato é o próprio quadro. No Scrum já existem aqueles artefatos que são gerados nas sprints. Por isso no scrumban o único artefato é o quadro com suas adaptações.

Não há estimativas para entregas no kanban, por ser contínuo. As entregas do Scrum dependem do tamanho das sprints com suas estórias e atividades. No Scrumban as estórias são sempre do mesmo tamanho.

O time no kanban é especializado e no Scrum é multifuncional ou multidisciplinar. No Scrumban ele pode ser especialista, assim como no Scrum.

O trabalho em progresso (Work In Progress – WIP) no kanban depende da capacidade de trabalho de cada etapa. Já no Scrum é limitado pela sprint. No Scrumban o trabalho é delimitado pela quantidade de trabalho de cada etapa.

Por fim, o backlog do kanban é em tempo real (just in time). No Scrum há a priorização. O Scrumban trabalho com o conceito de just-in-time com as estórias sempre para serem puxadas pelos envolvidos.

Conclusão

Perceba que há uma liberdade de adaptação quando se fala de Scrumbam. Importante que cada cenário seja avaliado para saber se o Scrum consegue entregar o valor necessário ou se será necessária uma adaptação juntamente com o kanban.

Uma análise importante que deve ser realizada é que existe Scrum sem kanban, existe kanban sem Scrum e existe Scrum com kanban.

Todos os frameworks e boas práticas disponíveis no mercado cabem análise para saber se se encaixam na demanda requerida para cada projeto ou rotina.

Receitas de bolo prontas dificilmente servem para todos os cenários. A experiência dos times, análise de ambiente, cultura e outros fatores podem influenciar na hora de se definir qual o melhor método de gestão que deva ser implantado.

Tire suas conclusões, compartilhe suas ideias e argumentos, para que mais pessoas possam usufruir desses importantes frameworks que vem ajudando milhares de pessoas ao redor do mundo a obter melhores resultados em projetos e trabalhos do dia a dia.

Um forte abraço e até a próxima.