Elementos em comum entre Scrum, XP e Kanban

No artigo de hoje eu quero te mostrar algumas semelhanças entre três dos principais frameworks/métodos de agilidade adotados pelas empresas em seus times de desenvolvimento de software: Scrum, XP e Kanban. Minha ideia não é te convencer de que não há diferenças, mas sim te mostrar que a maior transformação que você pode fazer pelo seu time não está na troca de um método pelo outro, mas sim na adoção dos valores e princípios ágeis do Manifesto, que são justamente a causa desses três métodos terem tantas semelhanças.

Pronto, isso já concluí o artigo. 😀

Scrum, XP e Kanban

Scrum foi criado por Ken Schwaber e Jeff Sutherland na década de 90. Eles juntaram suas experiências liderando projetos de software de todos os tamanhos ao redor do mundo com as teorias popularizadas por Takeuchi e Nonaka no famoso The New New Product Development Game, publica na década de 80 na Harvard Business School. É um framework iterativo-incremental para desenvolvimento de soluções complexas e inovadoras por times auto-gerenciáveis.

Já o Extreme Programming (XP) foi criado por Kent Beck, Ward Chunningham e Ron Jeffries também na década de 90. Eles juntaram suas experiências com engenharia de software para criar uma metodologia ágil que lidasse bem com requisitos vagos que mudavam frequentemente, times pequenos e que colocasse mais disciplina nos desenvolvedores ao invés de mais processos formais. É um método muito focado em qualidade de código, testes e outras boas práticas de engenharia.

E por fim, o Kanban, foi originado no chão de fábrica japonês na década de 50, mas posteriormente adaptado por David Anderson nos anos 2000 para ser usado em corporações, visando gestão do fluxo de valor das empresas, dentre elas as de software. Ele trabalha em cima dos conceitos da manufatura Lean e promove uma postura evolucionária de adoção do método, através de necessidades emergentes.

Note que as três surgiram em meio ao boom dos métodos ágeis, cujo ponto focal foi a criação do Manifesto Ágil em 2001. O quanto o Manifesto influenciou elas ou o contrário, é difícil saber, mas é fato de que existem muitas semelhanças, que é o que vou mostrar agora.

Agilistas do Scrum, XP e Kanban

Começando pelo mais óbvio papel dos métodos ágeis, o agilista, o profissional responsável pela adoção e melhoria contínua de processos ágeis no time.

No chão de fábrica japonês, conforme relata Mike Rother no seu Toyota Kata, já havia se entendido a necessidade de ter uma pessoa focada na melhoria contínua do time (kaizen), observando o fluxo de produção, identificando gaps e ajustando processos. Embora os próprios profissionais de produção também enxergassem gaps nos seus processos, eles não tinham a visão do fluxo de valor completo e muito menos tinham tempo para promover melhorias.

A versão moderna deste profissional é o Scrum Master no Scrum, o Coach e o Tracker no XP e o Service Delivery Manager no Kanban. Note que no XP temos dois papéis exercendo atividade semelhante e ao mesmo tempo com particuliaridades uma vez que o Coach XP é geralmente muito mais técnico do que um Scrum Master moderno e o Tracker XP é focado em métricas do time. Já o Service Delivery Manager foi criado mais tarde como um papel opcional pelo próprio David Anderson, uma vez que ele deve ter percebido que o ditado “cachorro com mais de um dono morre de fome” também se aplica a processos desenvolvimento.

Note que não entro aqui na filosofia por trás de cada papel e me perdoem os mais puristas por isso. Do ponto de vista de atividades, a semelhança é incrível.

Profissionais de Produto do Scrum, XP e Kanban

Outro grande gap identificado nos métodos tradicionais de desenvolvimento de software foi o distanciamento do cliente ao longo do projeto. A falta de comunicação com o mesmo durante todas as fases de desenvolvimento do software faziam com que o resultado fosse um desastroso telefone sem fio (lembra da brincadeira?). Assim nascia a função do profissional de produto dentro dos times ágeis. Seja o cliente ou alguém representando o mesmo no dia a dia, estes líderes de produto tinham como missão garantir o ROI e otimizar o esforço de desenvolvimento rumo ao que o cliente realmente deseja.

No Scrum temos o Product Owner, no XP temos o Cliente e o Gerente e no Kanban temos o Service Request Manager. Todos estes papéis são responsáveis por priorização de backlog, comunicação com o cliente, ROI do projeto/produto, etc. Curiosamente é comum que eles trabalhem com o formato de User Stories para os itens de backlog, que é um formato originário do XP. Também é muito comum que eles trabalhem com o backlog corrente exposto em um quadro de atividades, oriundo do Kanban. Ou seja, é muito comum uma amálgama destas práticas no dia a dia dos times de software.

No XP eu citei os papéis de Cliente e Gerente como sendo comparados ao Product Owner do Scrum e ao SRM do Kanban pois depende da natureza do projeto e das características da sua empresa. Eles são papéis distintos no XP, mas podem acabar sendo aglutinados dependendo do cenário.

Novamente me perdoem os puristas.

Cerimônias do Scrum, XP e Kanban

Ao contrário do que muitos times novatos pensam, passar a utilizar uma metodologia ágil não quer dizer que você vai ter mais reuniões do que já tem. O que acontece é que sim, haverá uma disciplina maior na facilitação e recorrência das mesmas, para garantir o alinhamento e a comunicação, consequentemente aumentando a chance de sucesso do projeto.

O Scrum possui cerimônias muito famosas, logo pegarei as mesmas como exemplo de comparação. No Scrum temos a Sprint Planning, marcando o início de uma iteração (a propósito, Scrum e XP possuem iterações, Kanban não, ele possui cadências). Da mesma forma, no XP teremos o Jogo de Planejamento, sendo que existe o Planejamento de Iterações (tal qual Sprint Planning) e o Planejamento de Releases (semelhante a um Product Increment Planning do SAFe).

Extreme Programming Project
Extreme Programming Project

Já no Kanban é mais parecido com o XP do que o Scrum, pois se quebrou a cerimônia de planejamento em duas. Aqui as cerimônias se chamam cadências e temos a Replenishment ou Commitment Meeting e a Delivery Planning Meeting.

E depois de planejado, mantemos a sincronia do time através da famosa e polêmica reunião diária. Se tem uma coisa que gera polêmica e que ao mesmo tempo é unânime entre os métodos ágeis é a necessidade de reuniões frequentes e rápidas enfatizando a comunicação. No Scrum temos a Daily Scrum, no XP a Daily Stand Up Meeting e no Kanban a Standup Meeting (também com frequência diária).

Curiosamente, no Scrum também se faz esta cerimônia em pé, mas esta é uma regra do XP e do Kanban, e não do Scrum.

Ciclo Scrum
Ciclo Scrum

Findo o desenvolvimento do incremento de software, é hora de revisar o que foi feito e entregar ao cliente. No Scrum chamamos este momento de Sprint Review e no Kanban temos duas cadências para revisar a entrega, denominadas Service Delivery Review e Strategy Review. No XP não temos nada específico para este momento até onde pude estudar, talvez até pelo própria ênfase em entrega contínua (Continuous Delivery), o que obviamente não invalida pequenos pacotes com review do cliente.

E para finalizar, quando o assunto é revisar como o time está trabalhando, o Scrum tem as famosas Sprint Retrospectives, o XP menciona retrospectivas, mas não define algo mais concreto e no Kanban temos uma mescla entre Service Delivery Review (métricas), Operations Review (otimizações no fluxo de valor) e Risk Review (ajustes no processo visando mitigar riscos). Note que apesar do Kanban aparentar ter mais cerimônias, é super comum a mescla entre elas ou a periodicidade assíncrona.

Cadências do Kanban
Cadências do Kanban

Artefatos do Scrum, XP e Kanban

Quando o assunto são os artefatos, aí é que temos uma enorme confusão. Ninguém se lembra qual artefato é de qual método.

Primeiro, usar um board de atividades é muuuito comum em qualquer time ágil, mas ele é originário do Kanban.

Kanban
Kanban

Segundo, escrever os requisitos em formato de histórias de usuário é outra prática comum, mas ele é natural do XP.

User Story Card
User Story Card

Terceiro, métricas como Lead Time e gráficos como o Cumulative Flow Diagram são artefatos do Kanban, embora largamente utilizados em diversos times Scrum e XP.

Lead Time
Lead Time

E por fim, estimar usando pontos em escala de Fibonacci, através de um baralho de cartas não é de nenhum dos três métodos, mas simum artefato inventado pela Mountain Goat Software chamado Planning Poker. Eu sei, no Kanban é mais comum contar atividades do que estimá-las, mas nada lhe impede de estimar em Kanban exceto o radicalismo de alguns agilistas. XD

Planning Poker
Planning Poker

Logo, aqui não temos semelhanças, mas sim um compartilhamento de ferramental que chega a tornar confuso saber o que é oficial de cada framework.

Por hoje é só pessoal. Como já disse no artigo O que é melhor: Scrum ou Kanban, acredito no uso combinado destes métodos para alcançar os melhores resultados com os times.

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis clicando no banner abaixo pra aprender muito mais!

Gamification em Modelos de Maturidade

No artigo de hoje vou explicar para quê serve, como criar um e como tornar a experiência com modelos de maturidade mais lúdica e interessante para os times. A ideia não é esgotar o assunto, mas dar ideias e uma introdução a quem busca este tipo de abordagem.

O quê é um Modelo de Maturidade?

Segundo a Wikipedia, em uma tradução livre, maturidade é uma medida da habilidade de uma organização em melhorar continuamente em uma disciplina em particular, sendo que a maioria dos modelos de maturidade certificam pessoas/cultura, processos/estruturas e objetos/tecnologia.

No âmbito de processos de desenvolvimento de sistemas temos modelos de maturidade como CMMI (Capability Maturity Model Integration) e MPSBR (Melhoria de Processos do Software Brasileiro) e mais especificamente dentro dos métodos ágeis temos um exemplo de modelo de maturidade no método Kanban que se chama KMM ou Kanban Maturity Model.

KMM
KMM

Basicamente um modelo de maturidade te guia através de práticas e processos cada vez mais evoluídos para a obtenção de um nível desejado de proficiência e qualidade na execução de suas atividades. Modelos de maturidade são divididos em níveis, onde para se obter a certificação de que você chegou em um nível geralmente tem-se de resolver um desafio ou fazer uma prova.

Por que criar um modelo de maturidade?

Todas empresas e times querem evoluir, certo? Afinal, melhoria contínua é um dos objetivos primários da agilidade. Embora a melhoria contínua orgânica e artesanal tenha o seu valor, muitas vezes as empresas possuem um norte técnico e de processos a ser seguido. Ter um modelo de maturidade claro, coerente e transparente ajuda e muito aos times atingirem esses objetivos, chegar nesse norte.

Se a sua empresa não depende de modelo de maturidade de mercado para conseguir clientes (CMMI é exigido em licitações, por exemplo), criar um modelo de maturidade próprio permite ter algo customizado às suas necessidades.

É importante ter em mente que o objetivo de um modelo de maturidade não é rotular que time é melhor ou pior, mas orientar a todos o caminho que a empresa espera que eles sigam, sendo algo de comum adoção em transformações ágeis e digitais de corporações, por exemplo.

Mas como tornar mais interessante e divertida essa busca por melhoria contínua direcionada através de um modelo de maturidade? Com gamification!

O que é gamification?

Gamificação é o uso de técnicas de design de jogos para enriquecer contextos geralmente não associados aos mesmos. Geralmente atividades gamificadas incluem obtenções de pontos (como em programadas de fidelidade), classificação dos “jogadores” (como em “funcionário do mês”), emblemas de conquistas (como nas insígnias de escoteiros) e muito mais. Note que citando estas características eu já dei vários exemplos de uso do gamification no mundo real.

Ao adicionar elementos de jogos em atividades não relacionadas aos mesmos traz mais leveza à condução destas atividades, torna-as mais divertidas, cria muitas vezes uma competição saudável e aumenta o engajamento do pessoal pois é muito comum as pessoas se engajarem em jogos bem construídos, sejam eles virtuais ou reais.

XBox LIve
XBox LIve

Como criar um modelo de maturidade gamificado?

Eu vou te fornecer um método, ok? Mas entenda que não é uma resposta para qualquer situação, a popular “bala de prata” que muitos procuram. É apenas um jeito de fazer, que já apliquei e deu muuuuito certo, mas no meu contexto.

Qual era o contexto? Uma corporação financeira com quase 20 anos que decidiu fazer uma transformação ágil e digital na sua TI. Estou falando de centenas de pessoas de todas as skills possíveis que trabalhavam com arquiteturas fragmentadas (ou emergentes, mas sem se conectarem), quase sem processos de desenvolvimento (poucos times usavam PMI e menos ainda usavam métodos ágeis) e muitos, mas muitos desafios, além da vontade de mudar pra melhor, é claro!

O primeiro passo é entender quanto tempo o jogo vai durar. Sim, isso mesmo. Todo jogo tem início, meio e fim. Ninguém aguenta jogar o mesmo jogo pra sempre. Podem haver continuações depois? Sim, mas você precisa ter início, meio e fim no seu jogo ou as pessoas irão perder o interesse, mais cedo ou mais tarde.

No meu caso, a duração do jogo era um ano. Queríamos fazer a referida transformação em um ano.

O segundo passo é entender qual é o final do jogo. Todo jogo tem de ter um final épico, que envolva uma grande transformação dos personagens, a superação de muitos desafios. Onde você espera que sua empresa/times estejam depois do jogo ter terminado?

No meu caso esperávamos que após um ano os times estivessem todos rodando métodos ágeis (Scrum, Kanban, etc) e programando nos padrões da arquitetura corporativa definida pela empresa (stack de tecnologia, padrões de segurança, ferramental de desenvolvimento, etc). Alcançado esse objetivo, entendíamos que a transformação teria sido finalizada com sucesso e de quebra acreditamos que afetaríamos a cultura da empresa positivamente.

O terceiro passo é entender qual a situação atual. Frente ao objetivo proposto para o tempo dado, o quão longe estamos de chegar lá? Note que esta metodologia de racionalizar um desafio não é minha, é do Toyota Kata de Mike Rother, mas isso é papo pra outro momento. Se queremos chegar lá em x meses, quantos passos serão necessários? É viável este salto evolutivo neste tempo?

Toyota Kata
Toyota Kata

No meu caso era viável sim pois as metas eram bem razoáveis. A fotografia atual não era desesperadora, apenas ia dar bastante trabalho. Tínhamos forte patrocínio da diretoria da empresa, o que foi vital para conseguirmos seguir adiante.

O quarto passo é quebrar o desafio em etapas, que seriam os níveis do modelo de maturidade. Você deve quebrar em tantas etapas quanto dê sensação de progresso aos times, mas não tantas que atrapalhe demais eles pois o avanço entre os níveis tem uma série de requisitos.

No meu caso quebramos o ano em 4 trimestres, onde a cada três meses fazíamos uma aferição dos resultados obtidos para ver quais times evoluíram dentro do modelo ou não.

Dependendo do número de níveis e da duração do seu jogo você poderá associar uma temática à ele. Sim, pois todo jogo tem um tema central, certo? Temas possíveis e comuns incluem artes marciais (trocando faixa a cada nível), escalada do Everest (alcançando acampamentos na montanha), treinamento Jedi (de youngling a Jedi master), RPG (que tal os níveis das classes de personagem?) e por aí vai.

Jedi Levels
Jedi Levels

Associar uma temática não é um passo obrigatório, mas altamente recomendável. A temática, se bem escolhida, abre um leque de oportunidades para comunicação dos desafios, premiações e cria uma empatia enorme com os times, principalmente quando se usa elementos muito conhecidos da cultura pop.

No meu caso usamos artes marciais como tema e definimos cores de faixa para simbolizar o nível de cada time dentro da evolução do modelo de maturidade. Apesar de não ser algo que muitos na empresa praticassem, foi algo que encontramos que todos conheciam bem o bastante e que tinha um simbolismo poderoso.

O passo seguinte é definir as regras para troca de níveis dentro do modelo. Sim, você tem de pensar como que os times e a empresa saberão quem está em qual nível e como avançar de um nível pra outro. Avaliações frias como provas não são recomendadas aqui, mas você terá de ter algum tipo de avaliação de qualquer forma, afinal é um jogo e ele possui regras.

No meu caso cada nível tinha uma série de microdesafios. Cada microdesafio era parte importante para se vencer o desafio do nível, que só era alcançado com 100% de microdesafios entregues. Cada microdesafio tinha um nome, uma descrição que dizia como ele era alcançado e uma categoria. Para cada categoria (DevOps, Práticas Ágeis, etc) existia um consultor encarregado que não apenas avaliava os times naquele tema, mas também tinha a função de educar os times de como chegar lá.

D&D XP Table
D&D XP Table

E por fim, a comunicação. O jogo só fará sentido e os jogadores buscarão evoluir dentro dele se houver comunicação eficiente. Comunicação dos prazos, das regras, dos desafios. Comunicação das premiações, que podem ser apenas simbólicas, reconhecendo publicamente os times que vencem cada etapa ou mais materiais como prêmios lúdicos como adesivos com insígnias dos desafios, cartazes e bandeiras para os times, etc.

Evoluir tecnicamente times de desenvolvimento de uma grande empresa não é uma tarefa fácil (no meu caso eram mais de 40 times e 420 pessoas). Nem pra quem está organizando a transformação, nem pra quem está sendo transformado. Comunicar bem sobre o jogo é uma maneira de tornar tudo mais real, mais tátil. Ajuda a garantir o engajamento e a tornar claro o que a empresa espera que os times alcancem.

E você, tem alguma experiência com modelos de maturidade? Alguma dúvida? Alguma sugestão? Deixe nos comentários!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis clicando no banner abaixo pra aprender muito mais!

O que é melhor: Scrum ou Kanban?

Na verdade o título que eu gostaria de usar neste artigo era “O que é melhor: desenvolvimento iterativo-incremental ou em fluxo contínuo?”, mas como os nomes dos processos são mais famosos que o conceito por trás deles, resolvi deixar como está. Além disso, a melhor analogia que eu poderia utilizar (eu adoro analogias!) para lhe poupar o trabalho de ler o artigo inteiro seria fazendo uma pergunta diferente “O que é melhor: a chave de fenda ou o martelo?”. Pense nisso.

E se estiver com preguiça de ler o artigo inteiro (depois só não vai fazer perguntas já explicadas no artigo), pule direto para as tabelas no final do mesmo.

Alguns fundamentos…

Antes de entrar nos argumentos do porquê da analogia é importante lembrar que Scrum, de 1995, é um framework empírico de desenvolvimento iterativo-incremental para projetos complexos e adaptativos. Ele foca no trabalho em equipe, melhoria contínua e muitos outros princípios que mais tarde originariam o Manifesto Ágil (2001). Sendo pouco prescritivo para os métodos de gestão de projetos à época, foi fortemente influenciado pelo artigo de Takeuchi e Nonaka, The New New Product Development Game (1986), de onde veio inclusive a ideia de comparar os times de desenvolvimento com os times de rúgby.

Já o Kanban do qual estamos falando é a versão de 2002, adaptada por David Anderson para gestão de atividades dentro de um fluxo de valor contínuo. Oriundo do sistema kanban de Taichii Ono (década de 50), criador do Sistema Toyota de Produção, ele foca no mapeamento e otimização do fluxo de valor de maneira que as pessoas que trabalhem no mesmo o façam com o maior eficiência possível (resumidamente: mantendo um lead time baixo com qualidade total). Ele toma para si uma abordagem evolucionária e colaborativa e é menos prescritivo ainda que o Scrum.

Você conhece mais sobre a essência destes métodos no meu artigo A Essência do Agile.

Principais Diferenças

A ideia aqui ainda não é falar qual é o melhor, apenas citar algumas diferenças (sem entrar no mérito se é uma vantagem ou desvantagem).

O Scrum tem um foco muito grande em ser um framework e não um método: uma estrutura mínima que te dê subsídios para avançar dentro do ágil, mas sem você ter de começar do zero. Suas cerimônias, papéis e artefatos constroem disciplina e tomada de consciência do time para a transparência, inspeção e adaptação.

Implementações de Scrum quebram silos ao criar times multidisciplinares, horizontalizam os times removendo a hierarquia e diminuem o achismo ao focar em ciclos rápidos de construir-medir-aprender tal qual no Lean Thinking (também derivado da Toyota).

Já o Kanban parte de uma filosofia “comece com o que você tem hoje”, onde o value stream mapping inicial é apenas o ponto de partida para a tomada de consciência com base no empirismo. Suas cerimônias, papéis e artefatos são praticamente emergentes e muitas vezes não são usados na sua plenitude pelos times.

Implementações de Kanban são evolucionárias e não costumam causar transformações desde o primeiro dia, embora possuam um forte apelo visual oriundo do uso quase onipresente do task board pelos times. Assim como o Scrum, mas ainda mais presente aqui, possui forte ligação com o Lean Thinking, principalmente no que tange o trabalho de Hansei e Kaizen (reflexão e melhoria) sobre os desperdícios do fluxo (Muda, Mura e Muri).

E por fim, as entregas. Enquanto no Scrum focamos em entregas iterativo-incrementais, ou seja, pequenas entregas em pequenos ciclos; no Kanban focamos em um ciclo único de entregas contínuas. E esta é, sem sombra de dúvida, a parte mais polêmica da discussão. Em um tempo que temos ferramental para Continuous Delivery, não seria óbvio que fluxo contínuo é melhor que entregas iterativo-incrementais?

Mais ou menos…

Entrega contínua vs Maturidade do Projeto

Scrum não fala nada contra Continuous Delivery. Tão pouco Kanban fala algo a respeito. Scrum inclusive se popularizou sobre o waterfall devido ao fato do número de entregas muito maior do que apenas uma durante todo o ciclo de vida de um projeto. Quebrar um projeto waterfall em vários ciclos menores não apenas permitiu que fizéssemos mais entregas do que antes como também permitiu que aprendêssemos mais rápido.

A confusão com Scrum vs CD é a mesma que o pessoal tem com as timeboxes do Scrum. Se uma planning tem uma timebox de 8h para 30 dias de sprint, NÃO quer dizer que ela tem de demorar 8h. O tempo MÁXIMO é 8h. Da mesma forma, na PIOR das hipóteses, você deve entregar um incremento de software a cada sprint, para garantir que o time está avançando e entregando valor. Agora, se seu time consegue entregar software diariamente, manda ver, só não esquece de alinhar com seu Product Owner, pois nem sempre jogar software em produção continuamente é uma boa ideia (mesmo testado).

Mas o que quero tratar aqui não é Scrum vs CD ou como Kanban ama CD, mas sim uma discussão mais importante que é: faz sentido para o seu time trabalhar focado em fluxo contínuo?

Vou te dar um exemplo: seu projeto está começando hoje. O backlog é imenso, tem uma série de questões estruturantes para serem feitas, o MVP está longe de poder ser usado por um cliente de fato (mas ainda é válido de ser testado por usuários-chave). Uma única tarefa ou história não agrega valor sozinha pois ainda é muito cedo, o software ainda não está minimamente maduro para que cada pedaço faça sentido ser colocado em produção.

Agora outro exemplo: seu produto está no ar há meses. O backlog continua a crescer, mas são sempre features complementares ao projeto original. Cada uma das features levam várias tasks para serem concluídas, mas garantem avanços e inovações para os clientes a cada semana ou quinzena (diferente da v1.0 que levou de 1-3 meses pra ser concluída). Tasks individuais ainda não geram valor per se, exceto no caso de correções de bugs. O software está amadurecendo cada vez mais rápido.

E um último exemplo: seu produto está no ar há mais de um ano (talvez vários anos). O backlog já não cresce mais tanto, geralmente entrando pro time (agora bem menor) uma série de ajustes, correções, melhorias pontuais e raramente alguma feature mais complexa. Diz-se que o software entrou em modo de sustentação, sendo que cada task já gera valor individualmente e os clientes tem acesso a melhorias (se seu pipeline estiver evoluído) diariamente. O software está completamente maduro e provavelmente já existe outro time pensando em um novo produto para substituí-lo.

Em quais destes três cenários você enxerga um bom uso de entregas organizadas em semanas (iterativo-incrementais) e em quais faz mais sentido as entregas diárias ou o mais próximo disso (em fluxo contínuo)?

A tabela abaixo mostra a minha resposta para este questionamento:

Scrum vs Kanban - Tabela 1
Scrum vs Kanban – Tabela 1

Entenda como verde o que recomendo que seja utilizado, amarelo use com cautela (entenda a situação, faça adaptações) e vermelho evite. E se nunca ouviu falar de ScrumBan, é a prática quase universal de usar Scrum com um board estilo Kanban para gestão visual de demandas e outras práticas de fluxo contínuo.

Vou ressaltar aqui apenas dois pontos: os vermelhos.

Rodar scrum “by the book” em times de sustentação de software é um tiro no pé. Você tem de adaptar para um ScrumBan ou outra adaptação qualquer, caso queira ser bem sucedido. Dependendo das classes de serviço que este time for trabalhar, nem mesmo faz sentido rodar métodos ágeis e apenas uma gestão de incidentes mais tradicional, no melhor estilo ITIL.

E por outro lado, rodar somente o sistema Kanban em times criando um software do zero não vai servir pra muita coisa, seu Lead Time não terá como ser baixo (um dos principais objetivos do Kanban se perde neste caso) e o sistema não ajudará no team building (na verdade Kanban pouco se importa com o time, e sim com o fluxo rodando rápida e perfeitamente).

Note que esta é apenas a minha opinião, mas criada a partir de mais de 8 anos rodando ambos em diferentes times.

No entanto, não querendo lhe dar uma equação tão simples e por vezes míope para essa discussão, eu agregaria ainda outro fator: o quão proficientes em métodos ágeis são os membros do seu time?

Processo Ágil vs Maturidade do Time

Maturidade de time é um tema sempre polêmico, mais até que Scrum vs Kanban, hehehe. Pretendo abordar este tópico em outro artigo. Por ora, estou dividindo aqui os times em apenas dois níveis: Agile Noobs (quem nunca trabalhou com métodos ágeis antes e/ou tem pouca experiência) e Agile Practioners, a galera que já roda métodos ágeis há tanto tempo que os 12 princípios do manifesto já estão no seu sangue, já o fazem independente do processo estabelecido.

Por que considerar isto é importante?

Por ser mais prescritivo (se comparado ao Kanban), o Scrum é quase que uma formação em métodos ágeis para o time. Ele trabalha toda a questão de disciplina, responsabilidade, trabalho em equipe. Torna concreto uma série de princípios ágeis mais abstratos. Inclusive, com o passar do tempo e com a tomada de consciência que ele traz, o próprio time vai entender por si só se o Scrum ainda está lhe ajudando ou não. Esse é exatamente o conceito ShuHaRi de aprendizado das artes marciais japonesas, que pretendo abordar em outra oportunidade.

Não quero dizer que começar com Kanban em um time Agile Noob não possa dar bons resultados, mas sim que, na minha experiência, se tornou muito mais eficiente começar com Scrum. Posto isso, segue outra tabela, agora considerando a experiência do time com métodos ágeis:

Scrum vs Kanban - Tabela 2
Scrum vs Kanban – Tabela 2

Vou ressaltar aqui apenas dois pontos: o amarelo e o vermelho.

Sim, eu não recomendo Kanban “puro” para times que estão começando agora com métodos ágeis. Note que me refiro aqui a times de software, em outros nichos às vezes faz sentido só usar Kanban a vida inteira do time.

E sobre Scrum puro em times mais avançados, deixo à critério do próprio time decidir, uma vez que já devem ter experimentado ambos e com base no entendimento do próprio time eles podem tomar esta decisão sozinhos (pensando aqui que você que está lendo seja um agilista).

Análise Final

E se você, assim como eu, está preocupado em cruzar as duas informações, vou poupar o seu trabalho com a tabela abaixo, onde cruzo ambas tabelas para fácil consulta.

Scrum vs Kanban - Tabela 3
Scrum vs Kanban – Tabela 3

Aqui novamente explicarei somente os dois extremos: o vermelho e o verde.

Em vermelho, quero dizer que times novos no ágil em projetos novos devem fortemente ser orientados a usar Scrum. Scrum é uma excelente “escola” quando o assunto é agilidade. O time deveria no mínimo tentar utilizá-lo por algumas sprints (geralmente leva-se de 2 a 3 para ter sucesso com Scrum) antes de descartar essa possibilidade.

Em verde, quero dizer que times ágeis trabalhando em software maduros devem estar livres para usar o processo que quiserem. Geralmente estes times acabam usando algum tipo de amálgama, dificilmente abandonando as raizes do Scrum e/ou do Kanban. Geralmente estes times não possuem mais lideranças prescritivas (como o Scrum Master), mas sim situacionais.

Ainda que existam pessoas que talvez venham comentar que times realmente ágeis deveriam ser livres para usar o processo que quiserem desde o primeiro dia de projeto, minha recomendação é não cair na armadilha do “não precisamos de processo, já sabemos tudo que deve ser feito e como deve ser feito”. Eu jamais cheguei em um time que, por mais que já trabalhassem juntos há um tempão, não tivessem margem para melhorar através de ajustes de processos e ferramentas bem ajustados.

No livro Extreme Programming do Daniel Wildt (e cia.) tem uma frase muito boa que diz: não existe a perfeição, apenas o aperfeiçoar. Curiosamente, a maioria dos times com os quais tive de lidar achavam que não precisavam da ajuda de um agilista, que já eram maduros…

Voltando à analogia que eu coloquei lá no início, Scrum e Kanban são ferramentas diferentes que em alguns momentos você vai querer usar uma das duas, em outros momentos as duas e talvez em um terceiro momento, nenhuma delas. Afinal, quem disse que para ser ágil tem de usar Scrum OU Kanban?

Sem contar o XP…onde ele entra nessa história? Tento falar disso nesse outro artigo.

E você, concorda ou discorda? Qual a sua opinião a respeito? Manda aí nos comentários!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis clicando no banner abaixo pra aprender muito mais!