O Que é Scrumban?

O que é Scrumban?

O Scrumban é um híbrido de Scrum e Kanban – uma mistura das cerimônias do Scrum com a visualização, os limites de WIP, o sistema puxado e o fluxo contínuo do Kanban. Uma combinação como essa é particularmente útil para empresas migrando do Scrum para o Kanban ou aquelas que nunca experimentaram Métodos Ágeis, porém estão interessadas em adotar um fluxo de trabalho puxado.

O termo Scrumban foi inventado por Corey Ladas, autor de “Scrumban: Essays on Kanban Systems for Lean Software Development”.

Scrum e Kanban em poucas palavras

O Scrum foi desenvolvido como um framework para engenharia simultânea na indústria de software. Suas metas são aumentar a velocidade de entrega dos produtos e uma capacidade maior de reagir às mudanças de requisitos e condições do mercado. O Scrum divide o trabalho em iterações de 1 a 4 semanas chamadas de sprints, ao término de cada qual um produto funcional deverá estar disponível. No Scrum, as equipes são pequenas e multifuncionais, sendo que todo o trabalho de dada sprint é determinado por um Product Owner.

O Kanban tem suas origens na indústria e uma de suas principais características são os limites de WIP (trabalho em andamento). As equipes Kanban se concentram em manter um fluxo contínuo de trabalho, visualizado como cartões Kanban em um quadro dividido em etapas de trabalho. Cada etapa possui um limite de WIP designado, que ajuda a gerenciar a taxa de produção, monitorada regularmente para garantir a eficiência e previsibilidade do processo.

O que é Scrumban?

O híbrido Scrumban permite que as equipes usem o melhor dos dois mundos para atender às suas necessidades específicas. Costuma-se recomendar que equipes maduras migrem do Scrum para o Kanban e o Scrumban é uma boa maneira de realizar essa transição, embora, muitas vezes, as equipes decidam simplesmente continuar no Scrumban. De certa forma, o Scrumban está mais alinhado ao Kanban que ao Scrum, no sentido de ser mais fácil aplicá-lo a diversas finalidades, por ser menos restritivo que o Scrum.

As origens do Scrumban: Adotar o Scrum é difícil

Migrar para os Métodos Ágeis é algo difícil para a maioria das equipes. Muitas vezes, isso requer uma mudança de mentalidade difícil de realizar. Além disso, por conta da popularidade do Scrum, muitos gestores lembram apenas do Scrum ao pensarem em Métodos Ágeis, embora existam inúmeros outros frameworks e metodologias disponíveis, incluindo Kanban, XP, DSDM, etc.

Apesar dos muitos casos de sucesso envolvendo equipes que implementaram Scrum, se você pudesse falar com essas equipes, provavelmente lhe diriam que alcançar o sucesso com Scrum não foi fácil. Nas empresas mais bem-sucedidas, muitas vezes leva de 12 a 16 semanas para desenvolver a disciplina para fazer o Scrum funcionar. É comum as empresas necessitarem de ajuda externa séria, na forma de consultores. Elas costumam enfrentar muita dificuldade para preencher os novos papeis exigidos de Product Owner, Scrum Master e equipe de desenvolvimento. Para muitas, é meio que um desastre de RH.

Além disso, calcular pontos de história (story points) e medir a velocidade – apesar de não ser obrigatório no Scrum, segundo seu manual oficial – tornou-se quase uma necessidade. A maioria das equipes enfrenta dificuldade para entender essas métricas e Scrum Masters reclamam como é difícil medi-las corretamente. O Scrumban permite evitar toda essa confusão desnecessária.

Os gerentes de projeto estão acostumados a lidar com empreendimentos que tenham uma data de início e fim definida. Geralmente são projetos compostos por equipes multifuncionais, trabalhando juntos por 12 meses ou menos. Equipes como essas podem trabalhar bem com o Scrumban, aprendendo as estruturas de comunicação baseadas em determinadas cerimônias do Scrum, com sessões de planejamento dedicadas para discutir os requisitos do projeto.

Além disso, em muitos projetos, especialmente os de infraestrutura, nem sempre há um produto funcional ao fim de cada sprint, um dos requisitos do Scrum. Em vez disso, as equipes trabalhariam continuamente e passariam para a produção ou outra iteração quando prontas. Afinal, a abordagem Scrumban aceita um sistema ou ciclo de produto existente e simplesmente o complementa com a visibilidade do Kanban e algumas das cerimônias do Scrum.

Além do mais, com o Scrumban, os gerentes de projeto não precisam obrigatoriamente encontrar um Product Owner específico para controlar o backlog. O papel de Product Owner é crítico para o Scrum, mas nas empresas, geralmente há múltiplas partes interessadas em diferentes tipos de requisitos, tornando impossível que uma única pessoa priorize histórias ou demandas. O Scrumban não exige histórias de tamanho padrão ou um responsável único pelo backlog, mas simplesmente pede para a equipe garantir que o backlog fique claramente visível a todos.

Migrando de iterações para a entrega contínua

O Scrumban permite que as equipes deixem de manter um conjunto obrigatório de sessões de planejamento, passando a planejarem apenas quando necessário. Novos itens a fazer podem ser descobertos regularmente durante a produção. Ao contrário do Scrum, o Scrumban não força as equipes de produção a limitarem o escopo do sprint a 1-4 semanas, possibilitando que a produção leve o tempo que for necessário para os melhores resultados. Embora, do ponto de vista de um projeto, isso acabe por aqui, para a maioria das empresas, é apenas o início da jornada. Os projetos são realizados de modo que a mudança temporária iniciada por eles continue operando e colhendo benefícios. O Scrumban é muito útil para isso.

Equipes Scrum podem achar mais fácil migrar para o Scrumban na última parte de um projeto – ao passarem do desenvolvimento do produto para a sua manutenção, adotando uma abordagem de fluxo contínuo.

Afinal, qual é a diferença entre Scrumban e Kanban?

Tipicamente, as equipes utilizando quadros Scrumban dividem o fluxo de trabalho em mais etapas do que em um quadro Kanban. Fazem assim para mostrar uma natureza mais gradual do processo, derivada da abordagem de planejamento de projetos baseada em sprints. Muitas vezes, o quadro Scrumban ainda incorpora uma etapa “sprint” ou uma classe de itens “Histórias”. Nesses quadros, é possível monitorar o progresso do trabalho relacionado a um sprint ou uma história específica, mesmos a equipe trabalhando continuamente.

Além disso, as equipes Scrumban geralmente têm mais liberdade ao priorizar os itens nas colunas do que as pessoas trabalhando com Kanban, que tende a prescrever o uso da regra FIFO.

Conclusão

As empresas estão percebendo que precisam mudar para uma forma de trabalhar mais Ágil ou Lean, sendo o Scrumban uma maneira fácil de fazer isso, com a eliminação da confusão desnecessária do Scrum, desnecessárias a muitas organizações. Com isso, as empresas podem continuar trabalhando de uma maneira que seja natural para elas e, ao mesmo tempo, implementar as melhores práticas Lean e Ágeis específicas para ambientes de fluxo contínuo.

O Scrumban pode fornecer a quantidade certa de rigor que você precisa, junto com a flexibilidade, eficiência e visibilidade do Kanban e do Lean.

Os principais benefícios do uso do Scrumban são:

  • maior qualidade do trabalho concluído e tomada de decisão just-in-time
  • maior velocidade de processamento
  • desperdício minimizado
  • maior autonomia e satisfação das equipes
  • processos melhorados continuamente


Características Scrumban
Papeis Não predefinidos. A equipe mais os papeis necessários, p. ex., gerente de projeto, etc.
Reuniões ou sessões As necessárias para fazer progresso contínuo. Geralmente, ao menos stand-ups diárias.
Demos e retros Como e quando necessárias – não são fixas no fim de cada sprint.
Iterações Não fixas, trabalhando em fluxo contínuo.
Método de trabalho Puxado com limites de WIP.
Burndowns Não, apenas um quadro Kanban.
Monitoramento da velocidade Não, mas recomenda-se foco na remoção de gargalos.
Estimativas Os itens no quadro têm tamanhos similares, mas não são fixos com pontos de história.
Backlog Guiado por JIT (just-in-time), como necessário.
Escopo Não fixo, o quadro é atualizado regularmente. O fluxo de trabalho não é sobrecarregado, mas baseado em JIT e taxa de produção.