Você já ouviu falar no termo Scrumban? Ele é uma mescla das palavras Scrum com Kanban e é um termo comum em times ágeis para designar um método formado pelas duas práticas.
Originalmente ele foi nomeado desta forma por Corey Ladas, um praticante de Lean-Kanban que através de diversos estudos criou um método de migrar do Scrum para o Kanban. Apesar de eu não concordar com a necessidade de haver uma “migração”, os estudos e dissertações de Ladas muito contribuíram para a adoção de práticas eficientes e o preenchimento de lacunas do Scrum enquanto framework.
O porquê alguém juntaria Scrum com Kanban eu já expliquei em meu artigo anterior chamado “O que é melhor: Scrum ou Kanban?“, caso não esteja claro os benefícios de juntar os dois conceitos.
No artigo de hoje, fortemente influenciado pelo material oficial da Scrum.org sobre o assunto, eu detalho como pode ser uma junção adequada de ambas as práticas, usando o Scrum como base e adicionando o Kanban por cima (afinal não é um KanScrum, certo?)
Atenção: essa é minha proposta e abordagem para este assunto. Não é uma verdade universal e nem tenho pretensão de descartar o trabalho de outros profissionais como Corey Ladas, Ajay Reddy, Rodrigo Yoshima e o próprio trabalho da Scrum.org que usei como base. Leia e use por sua própria conta e risco. Também lhe convido a dar sua opinião nos comentários ao final do artigo.
Scrum Guide
Primeiramente é importante salientar que TUDO que está descrito no Scrum Guide permanece. Ponto.
Usar Kanban junto de Scrum vai te trazer mais clareza de como aplicar na prática conceitos do Scrum Guide, não vai substituí-los. Como cite nesse artigo sobre as semelhanças entre Scrum, Kanban e XP, é muito fácil de fazer uma transposição de papéis e cerimônias por exemplo.
Falando de papéis, mantemos os do Scrum, sendo que o Scrum Master vai ter de aprender algumas coisinhas novas que são responsabilidade do Service Delivery Manager e o Product Owner tem de estudar um pouco mais o papel de Service Request Manager, ambos papéis do Kanban (não são papéis obrigatórios, mas eles existem).
Falando de cerimônias, vale uma lida nas 7 cadências do Kanban para incrementar suas cerimônias Scrum. Como o Kanban é um método mais metrificado que o Scrum, você terá mais métricas e sempre a presença do quadro para usar como insumos nas suas cerimônias. Por exemplo, a Daily será feita na frente do quadro (físico ou virtual). A Planning, usará as métricas e previsibilidade obtidas pelo SLE (mais à frente falarei disso) para incrementar sua assertividade. A Review terá um momento para ver as métricas do time, bem como a Retrospectiva pode usar as mesmas para iniciar discussões.
Apesar das recomendações acima, esse artigo por si só já vai te dar vários insights de como incrementar o que você aprendeu no Scrum Guide com elementos do Kanban.
O fluxo de valor
O coração do método Kanban é o fluxo de valor, às vezes também chamado de fluxo de trabalho. Todo time Scrumban deve ter mapeado e definido o seu fluxo de valor, as etapas necessárias para um Product Backlog Item ser entregue como DONE segundo sua Definition of Done.
Além do famoso quadro de atividades, que ajuda a definir esse fluxo, é importante que o time documento e torne explícito (Kanban fala muito em políticas explícitas, o que tem tudo a ver com o pilar de transparência do Scrum).
A definição do fluxo de valor do time deve ter:
- quais etapas o fluxo de valor do time possui, ao menos considerando espera (geralmente TO DO), execução (DOING) e finalizado (DONE).
- regras claras de quando um Product Backlog Item pode ser movido de uma etapa para outra, principalmente DONE (essa deve ser associada à Definição de Pronto).
- qual será a unidade de medida de valor entregue ao usuário. Enquanto que em Scrum o mais comum seja utilizar Story Points (que é uma prática do XP), o mais comum em Kanban é apenas contar o número de Product Backlog Itens finalizados (DONE).
- como limitaremos o trabalho em progresso (Work in Progress – WIP) durante a Sprint (falarei disso mais à frente).
- um conjunto de métricas chamado de SLE (Service Level Expectations – Expectativas de Nível de Serviço) que serve para ter previsibilidade e transparência do trabalho do time.
Limitando o trabalho em progresso
Times Scrum naturalmente já possuem o mindset de limitar o trabalho em progresso, oriundo da prática de estimativa de Product Backlog Items versus a Velocidade do Time. Ou seja, dado o tamanho do escopo vs a capacidade de entrega do time, limita-se o quanto de trabalho entra na sprint.
Essa estratégia mais comum pode ser mantida em um método Scrumban, mas o Kanban sugere fazê-lo de maneiras diferentes e até mais granulares, entendendo que restrições estimulam mudanças de comportamento no time. Essa prática é chamada no Kanban de WIP Limit (limite de trabalho em progresso).
Na primeira Sprint Scrumban, o time tenta prever quantos Product Backlog Items ele conseguirá entregar, esse número é a Vazão Estimada (Throughput Forecast) e define que o WIP Limit total dessa sprint é essa quantidade. Para novos itens entrarem, antigos tem de sair (seja finalizados ou despriorizados). Conforme novas sprints acontecerem, você terá um histórico de vazão médio (Average Throughput) e com isso pode ajustar o WIP Limit adequadamente à realidade do time.
O Kanban também sugere que você possa aplicar WIP Limit por etapas do fluxo (por exemplo, não pode ter mais do que 3 itens sendo desenvolvidos ao mesmo tempo) ou por membro do time (cada pessoa só pode estar associada a um item em DOING, por exemplo). Essas restrições mais granulares ajudam a educar e disciplinar os times de desenvolvimento, garantindo maior foco, objetividade e entregas completas.
Afinal, quem nunca chegou no final de uma sprint e tinha um monte de item em DOING e quase nada em DONE? O que é melhor, 3 coisas prontas pra apresentar ao cliente ou 10 pela metade?
Essas regras de WIP Limit devem estar explícitas para o time Scrumban, na Definição do Fluxo de Valor que citei antes, sendo que WIP Limit é a base para se obter um sistema puxado (pull system) ao invés de empurrado (push).
Service Level Expectations
O SLE é um dashboard de gráficos e números que o time Scrumban deve ter anexo ao quadro de atividades. Aqui vou considerar que você não está usando ferramentas online que fornecem isso automaticamente, como o Jira ou o Azure DevOps.
A base para as métricas do SLE é o Cycle Time, ou seja, o tempo decorrido entre o início e fim do desenvolvimento de um Product Backlog Item. Ou seja, o primeiro passo é anotar em cada PBI o dia que o time começou a desenvolver ele e o dia que ele terminou (DONE). Não confundir com Lead Time, que é o dia que a demanda chegou pro time até sua entrega, embora este também possa ser medido.
Outro elemento importante é registrar o Average Throughput do time, ou seja o número médio de Product Backlog Items que eles conseguem entregar como DONE até o final da Sprint. Esse número serve também de WIP Limit geral, para evitar ter mais itens no fluxo do que o time consegue dar conta.
E por fim, nestes casos não há necessidade de um Burndown Chart, uma vez que o próprio quadro vai mostrar o andamento e a chance de terminarem no prazo ou não (embora você ainda possa ter um burndown se quiser), MAS, super recomendo adicionar um Cumulative Flow Diagram (Diagrama de Fluxo Cumulativo).
Eu não quero entrar em detalhes de como obter e montar estes gráficos e métricas, assunto para um próximo artigo, mas se você procurar no Google por mais informações destas métricas e diagramas que citei, não é difícil encontrar.
Conclusões
Brasileiro tem mania de futebolizar tudo. Tudo tem que ser “nós contra eles”, na política, na religião e nos métodos ágeis também. Acho a maior burrice quem mete o pau no Kanban em favor do Scrum ou o contrário. Na minha opinião, uma abordagem bem construída de Scrum (estrutura base) + Kanban (métricas e fluxo) + XP (práticas de engenharia), é o melhor que temos a disposição para organizar um time para a alta performance.
No próximo artigo, espero entrar em mais detalhes das métricas e gráficos do SLE, que apenas passei por cima hoje.
Até lá!
* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto!
