No artigo de hoje eu quero 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 é convencer ninguém de que não há diferenças, mas 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á conclui 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“, publicado 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, originado no chão de uma fábrica japonesa 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 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, 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, o Tracker no XP e o Service Delivery Manager no Kanban. Note que no XP temos dois papéis exercendo atividades semelhante e ao mesmo tempo com particularidades, 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 de desenvolvimento.

Note que não entro aqui na filosofia por trás de cada papel – 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 esses papéis são responsáveis pela 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ê 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 usarei 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).

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 essa cerimônia em pé, mas essa é uma regra do XP e do Kanban, e não do Scrum.

 

Finalizado 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.

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 usaremos um board de atividades. É muito comum em qualquer time ágil, mas ele é originário do Kanban.

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

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

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, sim, um 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.

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.

Curtiu o artigo? Dê uma olhada no meu livro de Scrum e Métodos Ágeis.