LuizTools

Scrumban: como usar Scrum com Kanban corretamente

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!

Toyota Kata – Resenha

Quando iniciei como Agile Coach em janeiro de 2018, promovido após alguns meses com Scrum Master no Agibank, eu logo fiz uma lista de leituras para me tornar um bom profissional nessa função. Dentre esses leituras estava o livro Toyota Kata, de Mike Rother, que é o motivo da minha resenha de hoje.

Toyota Kata é um livro sobre “gerenciar pessoas para melhoria, adaptabilidade e resultados excepcionais”, segundo o próprio autor. Se esses assuntos lhe interessam, continue lendo o post.

Clique na capa do livro para ver na Amazon.

Quem é Mike Rother?

Mike é um pesquisador americano enormemente conhecido por ter difundido no ocidente através de suas publicações os conceitos japoneses de Value Stream Mapping (Mapeamento de Fluxo de Valor, essencial para o Kanban), Fluxo Contínuo e, neste caso, o Toyota Kata também. Ele inclusive recebeu diversos prêmios devido à inovação e contribuição práticas das suas pesquisas na área e manufatura.

Sim, estou em um blog de tecnologia falando de um autor da indústria, ou você esqueceu que as bases dos métodos ágeis vieram do Sistema Toyota de Produção?

Toyota ok, mas o quê é um Kata?

Primeiro você precisa entender o que é um kata na cultura japonesa.

Um kata (forma em japonês), nas artes marciais, é uma sequência de movimentos coordenados cujo objetivo é proporcionar ao praticante da arte e, simultaneamente, experiência de luta. A ideia é que, conforme o estudante dominar os katas, eles se tornarão parte dele e, em caso de necessidade, ele os usará de maneira instintiva ou até mesmo criará novos.

Esse conceito de assimilação de conhecimento das artes marciais é citado por Jeff Sutherland no best-seller Scrum: A Arte de Fazer o Dobro do Trabalho na Metade do Tempo como sendo o famoso modelo Shu-Ha-Ri (também citado por Martin Fowler): na fase do Shu o estudante apenas repete os movimentos, sem entender muito bem o que está fazendo, mas ganhando prática; na fase Ha ele passa a entender os princípios e conceitos e a incorporar outras práticas de outros mestres; e na Ri ele transcende os ensinamentos e cria suas próprias práticas.

No contexto do livro, a referência aos katas se dá pelo fato da Toyota possuir “sequências de movimentos” ou de práticas que eles já incorporaram no seu dia a dia de maneira transparente e natural. Eles estariam no estado Ri de algumas competências gerenciais.

Inclusive Rother cita que, por ser algo tão natural no chão de fábrica japonês que ele teve de fazer intensas observações no dia a dia do trabalho nas gembas. Esse nome, Toyota Kata, ele mesmo quem cunhou.

O que é Toyota Kata?

Na verdade não é apenas um kata, mas dois: o Improvement Kata (Kata de Melhoria) e o Coaching Kata (Kata de Treinamento) e o livro gira em torno de lhe explicar estes dois katas, com muito embasamento de outros cases.

Basicamente, o Kata de Melhoria pode ser explicado a partir da imagem abaixo.

Nela, partimos do futuro (1), da visão de onde queremos que nosso processo ou produto esteja.Por exemplo, que seja possível atender a um cliente em menos de 10 minutos em uma financeira.

Depois, tiramos uma fotografia da nossa situação atual (2), onde estamos hoje frente ao desafio futuro. Por exemplo, demoramos 1h30 para atender a um cliente.

A seguir, definimos o próximo passo, a Próxima Condição-Alvo (3, Next Target Condition ou NTC), rumo à visão. Por exemplo, reduzir o tempo de análise de novo cliente de 30 minutos para 5 minutos.

Com a Próxima Condição Alvo em mente, conduzimos experimentos (4) para se chegar lá, usando o método PDCA para isso. É importante salientar que serão necessárias várias iterações ou NTCs para se chegar na visão. Ou seja, os passos 2, 3 e 4 se repetem.

Claro que o livro vai a fundo nestes tópicos que eu apenas citei, ensinando a definir estas etapas, a conduzi-las e apresenta cases da manufatura japonesa.

O outro kata, de Coaching, é sobre como na Toyota os líderes ensinam o Kata de Melhoria aos novatos. Como eles fazem gestão de pessoas para melhoria, adaptabilidade e resultados excepcionais.

Aqui vale uma menção aos exercícios que existem no livro, com situacionais em que você deve tomar decisões e depois vê a resposta correta segundo o autor.

E em software?

Claro que alguém já adaptou isso para o mundo do software, não é mesmo?

No livro Lean Enterprise o Toyota Kata é citado em uma versão modificada, voltado ao desenvolvimento de software. Enquanto que no original o foco era melhoria de processo, aqui o racional é quebrar uma visão de produto em pequenos passos iterativo-incrementais.

No entanto, caso queira realmente entender como funciona essa adaptação, o trabalho original veio deste livro aqui, de funcionários da HP, A Practical Approach to Large Scale Agile Development.

A essência ainda é a mesma, o mais bacana dessas leituras são os cases de aplicação mesmo.

Um abraço e até a próxima!

Gostou da resenha? Compre o livro na Amazon.

* 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!

O que é Scrum?

Atualizado em 07/04/2019!

Conheço e aplico métodos ágeis desde 2010, principalmente o framework empírico Scrum. Durante o final da minha faculdade a empresa onde trabalhava, RedeHost, necessitava urgente de uma reorganização dos seus processos de desenvolvimento de software e queriam que eu me tornasse um de seus líderes de desenvolvimento. Obviamente agarrei a oportunidade, que foi muito importante para minha carreira, e isso me rendeu uma ida à São Paulo participar da segunda turma de um treinamento latino-americano oficial da Scrum.org para desenvolvedores Scrum. O treinamento de uma semana foi incrível e me capacitou para tirar duas certificações na área de gerenciamento de projetos com métodos ágeis e passei a atuar como facilitador do framework Scrum na empresa, em treinamos e em consultorias (como esta).

No artigo de hoje resumo o famoso Scrum Guide, o livro de apenas 19 páginas que detalha tudo o que você precisa saber sobre o Scrum antes de passar a aplicá-lo em seu time de produto. No fim do artigo você encontra os slides do treinamento que aplico, disponíveis no Slideshare.

Caso queira saber mais sobre o meu trabalho com Scrum, dê uma olhada em meu livro.

O que é Scrum?

A definição formal, cunhada pelos criadores Ken Schwaber e Jeff Sutherland, diz que:

Um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível.

Entenda um framework como uma caixa de ferramentas. Scrum não é algo pronto que resolve todos seus problemas, mas sim um conjunto de processos que norteiam o desenvolvimento de produtos complexos.

Apesar de leve e simples de entender, Scrum é extremamente difícil de dominar, uma vez que envolve rigidez em sua aplicação. Implementações de Scrum que não seguem as regras previstas em seu manual são o que chamamos de Scrum flácido, e tendem a não alcançar o potencial máximo da metodologia.

Mas por que confiar e seguir cegamente este framework?

Scrum é um processo empírico, baseado pura e simplesmente nas experiências passadas de seus criadores que desde o início da década de 90 aplicam Scrum em projetos de software com sucesso, já sendo uma das metodologias ágeis mais usadas no mundo. E uma vez que você se torna adepto do Scrum, o empirismo passa a fazer com que você respeite o processo cada vez mais e adicione novos processos e artefatos complementares baseados nas SUAS experiências com o mesmo.

Os Pilares

O Scrum se baseia em três pilares de sustentação, suas ideologias:

Transparência: aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados.

Inspeção: os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção a detectar variações. Esta inspeção não deve, no entanto, ser tão frequente que atrapalhe a própria execução das tarefas.

Adaptação: se um ou mais aspectos de um processo desviou para fora dos limites aceitáveis ou produto não será inaceitável, o processo ou o material sendo produzido deve ser ajustado.

Sobre estes pilares o framework Scrum divide-se em papéis, eventos e artefatos.

Papéis

Os papéis dentro do time Scrum são:

Product Owner

É o responsável pelo ROI (retorne sobre o investimento) do projeto, é responsável por gerenciar e priorizar o Product Backlog (veja mais abaixo) e para que o Scrum funcione e ele consiga trabalhar, toda a organização deve respeitar as suas decisões. No mundo mais tradicional da gestão de projetos, o P.O. seria o Gerente de Produto (Product Manager), embora em grandes empresas, existam diferenças entre esses dois papéis.

O P.O. é membro do Time Scrum e deve estar presente e disponível para solucionar dúvidas do time em relação ao produto e ao backlog. Se esse papel for assumido por alguém da empresa do cliente, esta pessoa idealmente dever ter um canal de comunicação ininterrupto com o time de desenvolvimento, para que ele possa avançar sem atrasos.

Desenvolvedores

São os responsáveis por desenvolver o produto. O time de desenvolvedores (que não precisa e não deve ser composto apenas por desenvolvedores) é auto-gerenciável, multifuncional e compartilham a responsabilidade pelo sucesso ou fracasso do projeto.

O time de desenvolvimento é quem decide o quanto consegue entregar a cada iteração, para que haja comprometimento com a entrega.

Scrum Master

É o responsável por aplicar e garantir a adoção do Scrum dentro da equipe e até mesmo dentro da organização onde estão inseridos. Cabe ao Scrum Master, que é um líder-servidor, liderar o time para que os objetivos do Product Owner sejam alcançados e para que o time de desenvolvimento consiga avançar sem impedimentos, removendo-os quando necessário.

Todos os eventos Scrum são facilitados pelo Scrum Master da equipe, que idealmente não deve ter outra função paralela no time Scrum.

Eventos

O Scrum chama seus eventos de time-boxes, uma vez que são eventos de duração fechada. Um evento pode ser encerrado em tempo menor do que o previsto, mas nunca maior, e o Scrum Master deve garantir isso enquanto facilitador dos eventos. Permitir a extrapolação cria um sentimento inconsciente de impunidade e faz com a equipe não respeite os objetivos e o planejamento da Sprint. Por sua vez, falhas constantes em entregar os objetivos de uma Sprint forçarão o time de desenvolvimento em serem mais eficientes no planejamento, focarem mais nos objetivos e se comprometerem de maneira mais coerente com as entregas.

Sprint

As sprints são time-boxes de 1 mês ou menos e são o coração do Scrum. Durante o período da Sprint um incremento utilizável do produto é criado. Mas nem só de desenvolvimento vive a Sprint, fazendo parte da mesma também o planejamento, as reuniões diárias, a revisão e a retrospectiva.

Sprint Planning

Time-box de 8h para uma sprint de um mês, ou menos tempo de acordo com o tamanho da Sprint. Nesta reunião é onde o Product Owner é ouvido em relação às prioridades e os objetivos desta Sprint. É nela também onde o time irá deliberar sobre o que conseguem fazer nesta sprint em relação às necessidades do P.O., formalizando o Sprint Backlog, ou lista de coisas que serão feitas no próximo mês.

É comum o uso de artefatos externos ao Scrum nesta fase, como o Planning Poker, usado para estimar o custo de tarefas a serem realizadas. O ideal é que independente da técnica usada para estimar (pontos de história, por exemplo), que cada tarefa não ocupe um membro do time por mais de um dia. Se isso acontecer, veja como pode quebrar a tarefa grande em tarefas menores.

planningpoker

Outro artefato muito popular, que também não é do Scrum, é o kanban (especialmente usando Trello), um board onde temos colunas com cards, onde em cada card temos uma tarefa a ser realizada, previamente estimada. Cada coluna representa um estágio do ciclo de desenvolvimento de uma tarefa, tais como: TODO (para fazer), DOING (fazendo), Testing (testando) e DONE (pronto).

kanban-board-e60650d1-1

Daily Scrum

Time-box de 15 min que deve acontecer diariamente, sempre no mesmo local e horário para gerar consistência e evitar perda de tempo, facilitada pelo Scrum Master. Nesta reunião, que deve ser muito dinâmica e que popularmente é feita em pé (para evitar prolongamentos e distrações), cada membro do time deve responder apenas três perguntas: o que eu fiz ontem, o que eu vou fazer hoje e se tem algo me impedindo.

A reunião diária é o método mais eficaz de alinhamento dos membros do time que tive a oportunidade de experimentar. Ela permite a descoberta rápida de problemas e desvios de curso e suas respectivas correções, por isso deve ser respeitada.

burndown-chart-formula

Artefatos possíveis de serem usados nessas reuniões incluem um Burndown Chart, que nada mais é do que um gráfico de features a serem desenvolvidas (eixo y, vertical) versus tempo da Sprint (eixo x, horizontal). Um Burndown Chart sempre visível garante o dia inteiro, todos os dias, que todos sabem o quanto falta para terminarem a sprint, e caso estejam longe do seu objetivo, de resolverem os problemas. A ideia aqui não é analisar o Burndown Chart na reunião diária, que é curta e deve se manter assim, mas apenas acompanhar rapidamente, também de maneira diária, o progresso do time.

Esse evento é um dos que representam o pilar de inspeção do Scrum.

Sprint Review

Time-box de 4h para sprints de 1 mês onde o incremento do produto, que está pronto pra uso, é apresentado ao Product Owner para apreciação. Também é na review (que deve ser facilitada pelo Scrum Master) que o Product Owner apresentará os números, gráficos e tudo o mais que for importante à equipe saber sobre o produto. Novas prioridades, movimentos do mercado, etc, tudo focado em manter os objetivos coerentes ao longo das sprints.

Essa é o evento que melhor representa o pilar de inspeção do Scrum.

Sprint Retrospective

Time-box e 3h para sprints de 1 mês onde o time de desenvolvedores e o Scrum Master (que atua apenas como facilitador) falam sobre os resultados obtidos na Sprint que passou e as lições tiradas a partir daí, para melhorar o processo, fortemente arraigado ao pilar de adaptação. Trato em mais detalhes desta importante reunião neste post.

Artefatos

O Scrum determina alguns poucos artefatos:

Product Backlog

Lista ordenada de tudo que deve ser necessário no produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. Gerenciado única e exclusivamente pelo Product Owner, que o faz a todo momento, o product backlog deve ser mantido longe do time de desenvolvimento, para evitar dispersão.

Muitas empresas tem usado a ferramenta Trello para seus products backlogs. Já usei muito, mas atualmente uso só o Visual Studio Online ou o Jira.

Sprint Backlog

Uma versão reduzida de backlog apenas com os itens que devem ser desenvolvidos nesta Sprint, retirados do backlog original. Também pode ser organizada em formato de kanban no Trello, mas em um board separado do Product Backlog.

Cabe ao time de desenvolvimento montar o Sprint Backlog com base nas prioridades do Product Owner e é sua responsabilidade dar cabo de todos itens até o fim da sprint, servindo o Scrum Master como um facilitador para que nada interrompa o ciclo de desenvolvimento.

Conclusões

É isso. O Scrum Guide tem apenas 19 páginas e esse post umas 2000 palavras. O Scrum é pequeno, mas difícil de ser posto em prática porque exige muita disciplina. Nos treinamentos que ministro aplico sempre um exercício prático aos alunos para enriquecer a experiência e vivenciar na prática, mesmo que por poucas horas, como funciona o ciclo de desenvolvimento de um produto usando Scrum.

Boa sorte aplicando o Scrum em sua empresa!

* 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!

Treinamento de Scrum de Luiz Fernando Duarte Jr