8 pontos para avaliar Kanban e Scrum: Que abordagem utilizar? (parte 1)

Talvez nem todos saibam, mas Kanban não se trata de um processo de desenvolvimento de software ou mesmo um conjunto de regras e padrões a serem aplicados. Nem mesmo é prescrito pelo método Kanban algum tipo de papel ou responsabilidade. Um dos pilares do Kanban é não fazer julgamentos sobre o processo atual. Porém, muitos ainda confundem Kanban como sendo somente o quadro na parede.

Vamos verificar então se a metodologia é capaz de apoiar as necessidades dos negócios e, ao mesmo tempo, naturalmente escalável, enquanto o negócio está crescendo. No Scrum temos velocidade e o tamanho do backlog. Em projetos com alto nível de incerteza, as métricas de Scrum podem ajudar a prever planos realistas, melhorar a direção, reduzir os riscos de entrega e estimar o orçamento. Com Kanban, medimos a rapidez com que uma tarefa de negócios pode alcançar a produção. Todas as práticas Kanban são sintonizadas em conjunto para ajudar a equipe a ver como melhorar métricas, como o lead time, throughput e eficiência do fluxo. Em Kanban, o foco é o fluxo de entrega.

Que tal escalar? No Kanban, escalamos quando precisamos melhorar a taxa de throughput. A teoria das restrições nos diz que existe um e apenas um gargalo no sistema. Desta forma, o objetivo é encontrar o lugar mais fraco no processo e melhorar o Kanban, por exemplo, aumentando a capacidade da equipe ou limitando trabalho em progresso. A maneira mais fácil de identificar gargalos no Kanban é criar limites de trabalho em processo mais rigorosos para que a soma de todos os limites não seja maior do que o número de pessoas na equipe Kanban. No gráfico, vemos que a fase de QA é o gargalo. Para melhorar a taxa de transferência do sistema, adicionar mais recursos de QA pode ser uma boa idéia. Aqui estão as soluções mais comuns para eliminar o gargalo:

• Comutação de especialistas não QA para a equipe de QA. Esta solução irá melhorar lead-time, mas pode afetar negativamente a motivação dos desenvolvedores e outros especialistas não-QA.
• Descarregar especialistas de QA, mudando algumas responsabilidades para desenvolvedores e analistas; por exemplo, ter analistas escrever casos de teste antecipadamente, ou por ter desenvolvedores criar scripts de automação. Esta solução pode preservar a motivação dos especialistas não QA, mas requer algum tempo para introduzir a nova prática.
• Limite o trabalho em progresso. Esta solução melhora o lead time e a taxa throughput

No Scrum, uma abordagem diferente é usada para aumentar a escala. Normalmente, uma boa equipe de Scrum tem um “Product backlog” bem estimado e “velocidade” conhecida. Essas informações são suficientes para criar um gráfico Burndown. Vamos explorar um exemplo de um gráfico abaixo. Lá vemos que a equipe começou a trabalhar no projeto com uma certa velocidade, que não foi suficiente para realizar o “product backlog” entre junho e julho. A fim de melhorar o dinamismo de combustão, foi tomada uma decisão para adicionar mais uma equipe, permitindo-lhes fazer os prazos iniciais.

Diante deste cenário, podemos perceber que, para uma nova iniciativa, o negócio precisava de uma abordagem para acelerar a entrega de tarefas empresariais individuais. Podemos concordar que Kanban serviria a essa necessidade melhor do que o Scrum.

Por isto, temos o placar: Kanban 1 x 0 Scrum

Tamanho da equipe

O tamanho da equipe é outro aspecto importante que tendemos a ignorar. No Kanban, não temos limites no tamanho da equipe, enquanto no Scrum, o tamanho da equipe não deve exceder 9 pessoas. Por exemplo, se tivermos 15 pessoas na iniciativa, o Scrum precisa dividir o grupo em 2 ou 3 equipes. Isso pode ser problemático se tivermos algum talento único e é impossível formar duas ou três equipes de recursos iguais. Outra coisa a ter em mente é que duas ou mais equipes de Scrum exigirão mais tempo para sincronização, portanto você deve estar preparado para pagar por sobrecarga de comunicação, fazendo com que os seus custos de coordenação e de transação fiquem mais altos e, possivelmente, a depender do tamanho da equipe, a complexidade também piore pois haverá divisões de equipe para se adequar ao modelo scrum.

No quesito tamanho de equipe, Kanban seria muito mais fácil de configurar.

Kanban 2 x 0 Scrum

Gerenciamento de tarefas

Cada metodologia tem sua própria abordagem sobre como a gestão de tarefas deve ser organizada. Não podemos evitar o que o Scrum prescreve sem arriscar conflitos permanentes entre a equipe de desenvolvimento e as partes interessadas. Nós temos de responder a duas perguntas se quisermos tentar o modelo Scrum.

Em primeiro lugar, quantas vezes vamos mudar as prioridades? Se as prioridades forem destinadas a mudar mais rápido que o comprimento da Sprint, isso levará a sérios conflitos entre a equipe do Scrum e as partes interessadas do negócio. Mudanças freqüentes no meio do Sprint muitas vezes requerem esforços significativos de re-planejamento. Quando perguntámos às nossas partes interessadas, disseram-nos que a sua iniciativa exigia um pouco de flexibilidade na parte da equipe, porque anteciparam que as prioridades poderiam mudar a cada dois ou três dias.

Quão rápido temos de cumprir a tarefa de negócios? Se o participante da empresa solicitar que a equipe do Scrum forneça alguns recursos ASaP no meio do Sprint, ele pode resultar em outro conflito porque a equipe do Scrum está trabalhando em um plano para fornecer incrementos de trabalho até o final do Sprint. É por isso que algumas equipes de Scrum usam a “linha vermelha” para aumentar a flexibilidade, mas essa solução pode levar a uma queda significativa no desempenho. Quando a natureza do negócio implica várias mudanças nas prioridades e certas tarefas críticas com SLAs em torno de 2-3 dias, ou seja, tem uma inconstância grande, o Kanban se adapta melhor e atende um dos itens do manisfesto ágil com maior acertividade: Responder a mudanças mais que seguir um plano

Kanban 3 x 0 Scrum

Tamanho da tarefa

Em Kanban, nos concentramos em melhorar o time to market de cada tarefa de negócios de forma individual. Kanban é um método muito orientada por métricas. Por exemplo, a métrica de lead-time nos ajuda a ver se estamos melhorando ou não. No entanto, métricas Kanban requerem que as tarefas de negócios sejam do mesmo tamanho, caso contrário, é difícil obter qualquer valor do método. Nós não seriamos capaz de prever ou estimar datas de entrega por falta de uma abordagem de medição confiável para o lead-time. Se temos grandes tarefas de negócios para entregar e essas tarefas de projetos podem ser divididas em tarefas menores, então Kanban pode trabalhar de forma mais fluída.

Para projetos de negócios que não são tão claros, Scrum vai servir melhor. Nós experimentamos situações em que projetos grandes e não claros estavam chegando ao quadro Kanban e permanecendo no mesmo lugar no quadro por semanas. Não há nenhum valor em tal visualização. Decidimos usar o Scrum em vez disso.

Quando verificamos que as tarefas foram projetadas para atender a solicitações de negócios relativamente pequenas, podemos garantir que, nesta categoria, tanto Scrum quanto Kanban podem funcionar. O problema portanto, pelo menos para nós, estava relacionado ao tamanho do lote das tarefas. Estavam muito grandes e de díficil compreensão.

Kanban 4 x 1 Scrum

Bom, aqui termina a primeira parte desta análise. No próximo post iremos finalizar a avaliação. Não perca!

Quer saber como melhorar seu processo por meio de uma abordagem Kanban? Venha participar do Workshop Lean-Kanban Fundamentals !