Em um post recente em um fórum técnico, um gerente de Desenvolvimento tinha a pergunta (parafraseada aqui) – Minha organização quer operar de forma Kanban, mas manter a estrutura de sprints e gráficos burndown para acompanhar o progresso. É possível fazer isso? O Scrumban é a metodologia correta? Se sim, qual é a melhor maneira de implementá-lo?
Esta é uma pergunta bastante comum que muitas equipes Agile que estão começando a olhar para o Kanban têm. Você é uma equipe Scrum com ferramentas e práticas Scrum bem estabelecidas. Como exatamente você começa a trabalhar com Kanban? O que você acaba fazendo é conhecido como Scrumban? Implícito nestas perguntas talvez esteja a preocupação – minhas práticas e resultados Scrum serão diluídos ou distorcidos de alguma forma?
Tive o prazer de responder ao autor da pergunta e pareceu funcionar bem para eles!
O que é Scrumban?
No nível mais simples, Scrumban é apenas a aplicação dos princípios do método Kanban no topo de seus processos Scrum. Kanban, como esclarecido por David Anderson em seu famoso Blue Book de Kanban, não é uma metodologia de desenvolvimento de software ou de gerenciamento de projetos. É um método para visualizar e melhorar o que você faz atualmente. Se você atualmente faz Scrum, ainda pode usar Kanban para visualizar seu trabalho e melhorar sua entrega de produtos. Muitas vezes, as equipes que fazem isso chamam o resultado de processo Scrumban alterado/melhorado.
Os princípios fundamentais do Kanban são:
- Visualizar seu processo atual
- Implementar os limites de WIP e o método Pull; e
- Melhorar o fluxo, abordando qualquer gargalo do processo e evoluir gradualmente
Portanto, nas palavras do autor da pergunta, o fato de a equipe querer manter os princípios de Scrum e “trabalhar à maneira de Kanban” é um bom lugar para começar.
Visualize seu processo atual
Comece definindo o quadro Kanban que visualiza o processo que sua equipe Scrum usa atualmente para desenvolver, testar e entregar/implementar as histórias dos usuários. Ao invés de apenas o quadro Pronto-Fazendo-Feito, expanda a coluna Fazendo em cada etapa pela qual a história do usuário passa.
Aqui, é útil notar que muitas equipes só visualizam as tarefas dentro de cada História de Usuário no Quadro de Scrum, não as Histórias de Usuário. Com as Tarefas, é mais fácil usar apenas a estrutura Pronto – Fazendo – Feito para o Quadro de Tarefas. Entretanto, com o Kanban, você tem a oportunidade de visualizar as Histórias de Usuários em um quadro Scrum Storyboard – que poderia ser um nível mais alto de Pista de Natação no mesmo quadro Kanban, onde você pode definir o processo de engenharia detalhado pelo qual uma história de usuário passa.
Ao fazer isso, você pode visualizar completamente a jornada de cada história de usuário à medida que ela vai de uma etapa a outra, e começar a estudar as anomalias do processo de forma muito mais eficaz.
Seu Quadro Kanban pode ser parecido com o abaixo – é claro que você modelaria seu processo real no quadro –
A pista de natação principal rastreia suas histórias de usuários. Como mencionado anteriormente, esta pista é a que visualiza o processo real pelo qual suas histórias de usuários passam – e o ajudará a identificar gargalos ou áreas problemáticas onde suas histórias tendem a diminuir a velocidade e a se acumular devido a razões como atrasos de entrega, dependências externas (aguardando a confirmação de um cliente, ou uma equipe de infraestrutura para completar alguma tarefa de provisionamento), etc.
Você pode ter uma pista separada para acompanhar as tarefas associadas a cada história de usuário – embora isso seja opcional. Uma vez que você se acostumar com o gerenciamento do trabalho no nível de História de Usuário à medida que a história passa por cada etapa do processo de desenvolvimento, você pode achar que as tarefas são redundantes.
Defina os Limites de WIP
Uma vez acostumado com a nova visualização do Quadro Kanban, você pode implementar limites de WIP em cada etapa/passo – para refletir a quantidade máxima de trabalho que deve estar presente em cada etapa de cada vez. O Kanban reforça o princípio de reduzir as multitarefas e terminar o que você já começou antes de assumir qualquer coisa nova. (Pare de Começar. Comece a Terminar!).
Como você define os Limites de WIP? Inicialmente, você pode começar sem Limites de WIP. Uma vez observado qual é o fluxo de trabalho habitual, você pode decidir quanto de Limite de WIP deve ser especificado por etapa do fluxo de trabalho. Os Limites de WIP são mostrados como números em cada etapa, como na figura abaixo:
Image Courtesy: Pawel Brodzinski
O famoso Don Reinertsen deu a fórmula de definir o Limite de WIP como sendo o dobro da média de trabalho em progresso que você observa inicialmente. A maioria das equipes normalmente definem os Limites de WIP iguais a 1-2 vezes o número de pessoas trabalhando em cada etapa do fluxo de trabalho.
Os limites de WIP funcionam como restrições em um canal pelo qual o trabalho está fluindo, semelhante às margens de um canal. Sem as margens bem definidas (restrições), a água tenderá a se espalhar e estagnar em vez de fluir na direção desejada. Da mesma forma, os limites de WIP garantem que o trabalho já iniciado flua até o final do fluxo de valor antes que um novo trabalho seja puxado para o canal. Uma vez puxado o trabalho, os Limites de WIP ajudam a garantir que ele continue avançando.
Definindo Limites de WIP e a importância de Limites de WIP também já foi abordado em posts anteriores no blog.
Aborde Gargalos/Melhore o Fluxo
Conforme sua equipe começa a observar o fluxo e avaliar as etapas em que o trabalho está ficando bloqueado, você poderá automaticamente discuti-las nas reuniões de sua equipe e abordar os problemas que estão sendo enfrentados. As soluções podem variar desde ajustar os limites de WIP em estágios anteriores para regular melhor o fluxo, definir políticas explícitas (um princípio chave do Kanban) para lidar com o trabalho que está sendo retido de forma priorizada (como revisões de documentos e códigos), ajustar atribuições de recursos e assim por diante.
O outro aspecto de fazer isso é incentivar a implementação do Pull no sentido real. A maioria das equipes e das pessoas tem dificuldade em dizer “não” ao trabalho adicional. A definição de Limites de WIP lhes dá uma ferramenta para fazê-lo mais efetivamente, uma vez que os Limites de WIP são definidos e determinados conjuntamente por todas as partes interessadas – e fornecem um contrato explícito a ambas as partes de que nenhuma etapa do trabalho será sobrecarregada. As equipes podem dizer “não” mais efetivamente ou pelo menos pedir a seus clientes que retirem algo mais se lhes for exigido algum novo trabalho. Isto pode ter um efeito quase mágico sobre como o novo trabalho “urgente” deixa de ser empurrado para a equipe de entrega!
Movendo de Scrum → Scrumban (→Kanban?)
Não há uma “melhor maneira” prescrita para passar de Scrum para Scrumban ou Kanban, nem é desejável entrar em tal semântica. Você pode continuar apenas fazendo Scrum, com as características adicionadas de Kanban para ajudá-lo a gerenciar melhor o trabalho e a melhorar. Você está livre para chamar o processo melhorado resultante – que foi completamente adaptado às suas necessidades (da sua equipe)!
Ao começar a introduzir o Kanban em sua equipe, você deve continuar a usar vários aspectos do Scrum, tais como os buckets de 2 ou 3 semanas de Sprint, métricas como gráficos de velocidade ou burndown e outras formalidades relacionadas ao Scrum que estão funcionando bem para sua equipe, especialmente a Reunião Diária e as Retrospectivas.
Pelo menos inicialmente, nada precisa mudar em termos de seu Lançamento e Planejamento de Sprint. À medida que você utiliza o Kanban efetivamente, especialmente os limites de WIP e outros conceitos como a definição de políticas explícitas, o uso de Classes de Serviço para priorizar o trabalho e o compromisso com SLAs, você pode decidir fazer mudanças em seu processo geral que podem incluir a eliminação de alguns conceitos relacionados ao Scrum, como os buckets de tempo de 2 ou 3 semanas, estimativa, etc., pois o Kanban o ajudará a implantar mais continuamente e lhe dará a capacidade de fazer previsões do que você pode completar em cada quantidade de tempo.
Você também pode optar por adotar métricas Kanban adicionais, tais como o Diagrama de Fluxo Cumulativo, Tempo de Lead e Eficiência de Fluxo enquanto deixa de fazer o gráfico Burndown, uma vez que você pode não estar mais fazendo estimativas ou rastreamento de horas. Na verdade, a própria comunidade Scrum não está mais enfatizando a estimativa de esforço como sendo necessária para Scrum.
Para saber mais sobre Scrumban, você pode conferir aqui – O que é Scrumban? – que fornece mais alguns detalhes e referências a outros especialistas no tema Scrumban, como Core Ladas e outros, que você pode apreciar.
Espero que isto ajude. Se você precisar de mais ajuda sobre como implementar o Scrumban, você pode entrar em contato conosco aqui! Teremos prazer em ajudar!
Mahesh Singh
Co-founder, Sr. VP – Marketing, AKT/ KCP
