8 pontos para avaliar Kanban e Scrum: Que abordagem utilizar? (parte 2 - Final)

Dando continuidade ao artigo anterior, vamos avaliar outros pontos para se tomar decisão entre Kanban e Scrum, para sabermos qual é a abordagem de melhoria de processos mais adequada.

Funções da equipe

Uma equipe de Scrum envolve funções obrigatórias. É altamente recomendável que haja um Scrum Maste dedicado e Product Owner em cada equipe do Scrum. A violação desta regra levaria a sérios riscos na entrega. Eu nunca vi ninguém ter um problema para encontrar um Scrum Master bom e um Product Owner brilhante para uma equipe de Scrum, mas o que se irá acontecer quando formos trabalhar com quatro ou mesmo dez equipes? Estamos prontos para contratar pelo menos cinco Scrum Masters dedicados e encontrar cinco Product Owner dedicados para dez equipes Scrum? Nós definitivamente não recomendemos o uso de Scrum se você não estiver pronto para pagar por pessoas dedicadas para preencher as funções.

No nosso caso, em vários projetos que trabalhamos, o cliente estava pronto para fornecer um Scrum Master e Product Owner por equipe se dividirmos 14 pessoas em 2 equipes. Então, aqui, Scrum e Kanban são um bom ajuste.

Kanban 5 x 2 Scrum

Requisitos

A estrutura de requisitos pode variar muito drasticamente. Ele pode aparecer como um backlog de funcionalidades para um novo aplicativo ou pode aparecer como uma fila eterna de aprimoramentos para um aplicativo legado. Este é um fator clássico para escolher entre Scrum e Kanban. Se o projeto é de longo prazo e já existem alguns épicos e um conjunto de recursos esperados para ser implementado, é um caso ideal para Scrum. Dito isto, há são algumas precauções. Para configurações de Scrum em grande escala (três ou mais equipes de Scrum) é bom dividir o “backlog do produto” por áreas. As equipes do Scrum que servem a “backlog de produto de área” podem trabalhar com dependências mínimas e integração com outras equipes. Isso permite uma colaboração efetiva entre equipes de Scrum e partes interessadas. Kanban também se beneficia deste cenário do Scrum.

Kanban 6 x 3 Scrum

Equipes distribuídas

Como o modelo de entrega se apresenta quando temos recursos atribuídos em vários locais? Esta é uma boa pergunta para explorar. O Scrum foi inicialmente projetado para impulsionar o desempenho em equipes de co-localizados. Isso pode ser conseguido através da mudança de controle do gerenciamento para a equipe de desenvolvimento. A equipe de Scrum torna-se self-organized. A equipe de desenvolvimento decide de forma autônoma como atingir o objetivo da Sprint. Sem uma extensa comunicação e trabalho em Soft Skills, não podemos alcançar o aumento de desempenho esperado. A melhor descrição do Scrum Team Dynamics pode ser encontrada no modelo de Bruce Tuck. Bom desempenho requer passar por certos estágios do modelo de Tuck.

No caso de grupos dispersos (não localizados), há o risco potencial de ficar preso no primeiro estágio “formando” para sempre, porque a próxima etapa, “storming”, é quase impossível sem estar fisicamente presente em um local com outros membros da equipe. Eu tive uma grande chance de participar do “Distributed Scrum” desenvolvimento. Começamos como uma equipe dispersa, onde a equipe SCRUM consistia de desenvolvedores distribuídos em algumas cidades e em locais diversos em uma mesma cidade. Este set-up foi extremamente ineficaz. Em seguida, utilizamos o Scrum distribuído, onde formamos equipes de desenvolvimento de Scrum totalmente funcionais nestes locais externos. A colaboração entre equipes não foi grande até que começamos a usar ferramentas de comunicação high-end como SMART boards, vídeo-conferência, Google Docs, um quadro de status na TV, viagens de negócios freqüentes e outros meios para efeito essa sensação de conexão e presença. Aqui está o negócio: o Scrum distribuído efetivo só é possível quando o cliente está pronto para investir em ferramentas de comunicação e viagens de negócios entre locais.

Então o modelo Kanban, por outro lado, tem diferentes dinâmicas organizacionais. Kanban não é muito dependente da localização, possibilitando a implementação de Kanban efetivo através de meios de comunicação tradicionais. A configuração mínima para o Kanban distribuído requer um quadro on-line abrangente, como um TFS Kanban e uma boa tecnologia telefônica e de internet. A afirmação é que o Kanban distribuído é menos problemático do que o Scrum distribuído; no entanto, não vamos enganar-nos-bom investimento na comunicação eficaz leva a uma entrega mais rápida e melhor produtividade. Bem feito distribuído O Scrum com comunicação high-end é muito melhor do que o Kanban distribuído com um conjunto mínimo de ferramentas de comunicação. Buscando uma abordagem mais lean e mais simples, tanto Scrum como Kanban podem atender.

Kanban 7 x 4 Scrum

Organização

É de conhecimento comum que o Scrum leva a profundas mudanças organizacionais, enquanto Kanban leva o atual modelo organizacional em conta e incentiva melhorias evolutivas ao longo do tempo. A pergunta mais freqüente sobre o Scrum é o que é suposto fazer-com arquitetos-chefe, gerentes de projeto, gerentes de QA e outras funções organizacionais atuais? Scrum é rigoroso. A equipe do Scrum deve consistir do proprietário do produto, do Scrum Master e dos desenvolvedores. Outras funções devem ser incorporadas na equipe de desenvolvimento do Scrum ou consideradas “partes interessadas”. As partes interessadas comunicam todas as suas necessidades através do Product Owner, não tendo assim, acesso direto à equipe de desenvolvimento. Para muitos cenários de aplicação, a comunicação estreita com muitas partes interessadas da área pode ser necessária, tornando o modelo de Scrum inevitavelmente problemático.

Kanban 8 Scrum x 4

Decisão

Podemos perceber, que pelos cenários expostos, a escolha pelo método Kanban se torna mais lucrativa e com chances de ser aprovada ou aceita pela maior parte dos envolvidos. Um fator muito importante para esta decisão é a abordagem Kanban em si, que preza por não realizar julgamentos, ter uma visão de todo o trabalho em progresso e evoluir de forma colaborativa e contínua.

É importante citar também que Cocco (2011) e Cocco (2013), em sua tese de doutorado, fazendo uso de ferramentas de simulação dinâmica de processos, constatou também que Kanban é uma escolha melhor do que Scrum no que se refere à gestão de desenvolvimento de software. O modelo, simulando um processo baseado em Kanban, apresentou taxas de entrega maiores em menores tempo e com maior qualidade e menor retrabalho do que as abordagens Scrum ou Waterfall.

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

Até mais!

COCCO, Luisanna. Complex system simulation: agent-based modeling and system dynamics. 2013. Tese de Doutorado. Universita’degli Studi di Cagliari.

COCCO, Luisanna et al. Simulating kanban and scrum vs. waterfall with system dynamics. In: International Conference on Agile Software Development. Springer, Berlin, Heidelberg, 2011. p. 117-131.