Kanban: análises para implementação

O que é Kanban - Apresentação

Olá, eu sou o Roberto Sabino, sou instrutor na Alura, sou especialista em engenharia de software e agilidade, e estou aqui para te convidar para um treinamento muito bacana que é o Kanban 1. Vamos aprender o método Kanban através de um estudo de caso da Bytebank, onde vamos acompanhar a saga da Léia Líder, que é uma líder de squad.

Esse squad faz manutenção em um dos sistemas da Bytebank, e ela vai, junto com a gerência dela, junto com a equipe de desenvolvimento e os clientes, fazer uma proposta. Nós vamos analisar todo o cenário da Léia Líder, porque a proposta dela é mudar do framework Scrum para o método Kanban.

Está propondo que essa mudança seja feita e precisaremos entender: qual é a diferença entre Scrum e Kanban? Quais são os prós e contras de usar Scrum ou Kanban em um cenário de manutenção de sistemas? Também veremos um pouco sobre qual a diferença entre um método e um framework - aqui tem um ponto importante também para entendermos - e analisarmos um pouco da gestão visual, que faz parte das boas práticas do Kanban.

Embora também usemos no Scrum, mas vamos analisar com um pouco mais de detalhes o quadro físico, o quadro eletrônico, como usar a gestão visual. E Léia Líder vai optar, em um primeiro momento, por fazer um quadro físico, vamos aprender a organizar esse quadro e a trabalhar com ele da melhor forma possível, inclusive criando raias novas, vamos entender toda essa dinâmica.

Um dos pontos importantes que a Léia Líder vai trazer para o time no meio deste treinamento é que temos que saber trabalhar com o trabalho em andamento, o work in progress, que é um ponto muito importante no Kanban. Existe uma boa prática de reduzir o trabalho em andamento. Nós vamos entender isso.

Vamos entender através de alguns exemplos que eu vou trazer neste quadro, que é um quadro fictício, mas que faremos alguns cenários. Vamos aprender que limitar o trabalho em andamento não é deixar de atender o cliente, pelo contrário, vamos atender melhor porque estaremos mais focados.

Lá no final, a Léia Líder vai trazer, para o time dela, a ideia de que é necessário medir o trabalho para poder melhorar esse trabalho. Então ela vai trazer algumas métricas e apresentar essas métricas. Nós vamos aprender o conceito dessas métricas e depois, em um Kanban 2, vamos trabalhar com as métricas mesmo, fazer conta e ver detalhes dessas métricas no dia a dia.

Coisas importantes, você viu essa descrição e falou assim: "Sabino, eu quero fazer o treinamento, o curso de Kanban, mas eu não sei se eu consigo acompanhar". Vamos lá, se você conhece um pouco de agilidade, dá para acompanhar. "Sabino, mas eu não trabalho com sistemas, eu trabalho com agilidade, mas eu não trabalho com sistemas, eu consigo acompanhar?". Consegue.

"Sabino, eu já trabalho com um pouco de Kanban, então eu já conheço um pouco, tem benefícios em ver o curso?". Tem, vamos entrar um pouco em alguns detalhes operacionais do Kanban e acho que mesmo quem já trabalha, quem está começando a trabalhar com Kanban, pode se beneficiar do que vamos trazer aqui. "Sabino, eu trabalho só com Scrum, não conheço nada de Kanban, consigo fazer o treinamento?". Consegue tranquilamente.

"Sabino, quando que eu não consigo fazer esse treinamento?". Eu acho que aqui temos que olhar o seguinte: se você não conhece nada de agilidade e você quer aprender sobre agilidade, então não é este treinamento. Eu vou deixar no Para Saber Mais do curso algumas informações de outros conteúdos, na Alura, em que você possa fazer essa introdução à agilidade e então começar a aprender conceitos de agilidade.

Se você não conhece nada de agilidade, então não abordamos isso no curso de Kanban. De resto, vem comigo, o curso está bem prático, vamos analisar um caso prático, não precisa trabalhar exatamente com manutenção de sistemas. Esse caso prático é um caso porque fica bem clara as análises que vamos fazer de Scrum versus Kanban, estão todos convidados, espero vocês na primeira aula. Um abraço, até lá.

O que é Kanban - Nosso contexto

Muito bem, vamos começar então o nosso Mão na Massa, o nosso Kanban 1? A construção do nosso quadro Kanban, conhecer o método Kanban. Mas eu queria fazer aqui algumas colocações sobre este treinamento. Nós faremos a análise de uma história, de um estudo de caso que aconteceu na Bytebank.

É a história da Léia Líder. A Léia Líder é a líder do squad, de um squad de desenvolvimento de sistemas. Na verdade, é um squad que faz manutenção de um sistema de concessão de crédito dentro da Bytebank, que é uma fintech. Só que você não precisa saber nada de concessão de crédito - zero, não precisa saber nada de concessão de crédito, isso não é um problema. Mas precisa ter uma noção de agilidade. Bem por alto? Sim.

Eu vou deixar, no Para Saber Mais desta aula, algumas indicações de outros conteúdos, que temos na Alura, que podem te ajudar se você precisar de alguma coisa mais conceitual, se você quiser conhecer a teoria de Kanban, de Scrum, de agilidade. Por quê? Porque aqui nós vamos trabalhar na prática.

Então a história da Léia Líder, nessa história a chefe, ou a líder dela, é a Mana Ger - depois você me fala se você pegou o porquê o nome é Mana Ger. Ela é gerente de desenvolvimento, ela é a gestora da Léia Líder. Os desenvolvedores, nós vamos considerar uma persona, então o Deive Loper - também me fala depois se você pescou o porquê o nome é Deive Loper.

Ele é desenvolvedor full stack, é uma persona, então não falaremos de vários desenvolvedores, usaremos essa persona para tudo o que precisarmos trazer sobre os desenvolvedores. E temos o nosso cliente, o nosso líder da equipe de negócios, que está na equipe de negócio, que está perto da operação, que é Leo Rico. O Leo Rico é o nosso cliente principal.

Tem outras pessoas que vão aparecer nessa história durante o treinamento, precisamos então fazer uma análise e precisamos conhecer os nossos personagens. A Léia Líder, ela é coordenadora de equipe de sistemas, esse é o cargo que ela ocupa na Bytebank. Ela hoje faz o papel de Scrum Master. "Sabino, eu não estou entendendo, você vai falar de Kanban? Você está falando de Scrum Master".

Sim. Por quê? Porque hoje ela trabalha com Scrum, já vamos ver isso bem rápido. Ela acha a produtividade do time baixa, mas ela entende que a culpa não é do time, mas da maneira que eles estão usando o framework. É assim que começa a nossa história. Ela está pensando em propor uma mudança no formato de trabalho.

No trabalho anterior, antes de ela vir para a Bytebank, ela tinha usado o método Kanban. Ela acha que esse sistema de trabalho é o mais adequado para fazer manutenção de sistemas do que o Scrum, que eles estão usando hoje. Muito bem, e a gestora dela acha o quê? A Mana Ger, ela é gerente de equipe de sistemas, o papel dela é fazer gestão de pessoas.

Então ela não deve se envolver muito no técnico, mas sabemos que muitas vezes o líder, o gerente, ele acaba fazendo, acaba tendo envolvimento técnico. Ela não acha a agilidade muito importante, mas ela aceitou bem o trabalho Scrum. Se você perguntar para Mana: o que você acha do trabalho com Scrum?

Ela vai falar: não, está bom. Você acha que Scrum é muito importante em relação ao formato anterior de trabalho? Não. Então, para ela é 0 a 0. Ela nunca ouviu falar do método Kanban, ela não sabe o que é Kanban. Ela tem dúvidas se seria uma boa fazer alteração no processo de trabalho, porque ela não sabe se isso é efetivo, assim como ela não sabe se a mudança para Scrum surtiu alguma diferença. Por quê?

Porque ela faz gestão de pessoas, e sabemos que algumas implantações, algumas implementações de framework às vezes não refletem da maneira que deveriam ou a liderança às vezes não se envolve como deveria. Enfim, esse é o perfil da Mana Ger. O Deive Loper, que é desenvolvedor, ele tem um cargo de desenvolvedor de sistemas.

O papel dele é time de desenvolvimento, ele curte agilidade, ele gostou do Scrum, se adaptou bem ao Scrum, não conhece detalhes do método Kanban, mas já ouviu falar de Kanban, ele tem uma ideia do que é Kanban, mas ele não conhece detalhes. Ele está disposto a testar essa nova forma de trabalho. Ele se preocupa com a produtividade e também se preocupa com o seu bem-estar dentro do trabalho, claro.

O Léo Rico, que é o nosso cliente, que é da área de negócios, ele tem um cargo de coordenador de equipe de negócio. O papel dele hoje é product owner. Mas ele não conhece agilidade, ele não conhece Scrum, ele fez os treinamentos que a empresa indicou para preparar para esse papel de product owner, mas foram treinamentos caseiros, vamos dizer assim, a própria empresa fez esses treinamentos com seu pessoal.

Ele não está muito confortável com o papel e ele gostava mais do jeito de trabalhar anterior, antes de implantar Scrum. Então o Léo Rico, ele preferia quando ele não era product owner. Qual é o cenário do nosso estudo de caso aqui? O processo de trabalho usado é o Scrum, temos para esse squad a atividade de manutenção de sistemas.

Existem mudanças frequentes de prioridade, o que é normal para a manutenção de sistemas, então atender diretamente as equipes que estão usando sistemas, é muito comum termos mudanças de prioridade frequentes. Os papéis também são dinâmicos, então existem mudanças na área de negócio algumas vezes, inclusive refletindo na manutenção.

A satisfação da equipe é baixa, de uma maneira geral, eles não estão muito satisfeitos com a produtividade. Como está essa produtividade, essa performance? As entregas são meio irregulares, a gestão está mais ou menos satisfeita. Por quê? Porque a gestão, de uma certa forma, patrocinou a implantação do Scrum, então eles mais ou menos estão ali para dizer: não, está funcionando, vamos lá, vamos continuar.

Os clientes, como eles estão agora com um papel, uma responsabilidade maior e com o fato do PO ser da área de negócio, eles têm que responder mais ou menos pela priorização, pelo andamento das demandas - não pelo funcionamento das entregas, mas como eu estou demandando? Eu estou demandando bem ou não? Então a satisfação é média para alta, mas tem um pouco de viés aqui.

Satisfação da equipe mesmo, as equipes que estão trabalhando. Tanto a de negócio quanto a de sistemas, eles estão achando que está ruim: não está muito legal, não estamos entregando bem, do jeito que trabalhávamos antes estava melhor. Então a performance é o ponto. E os clientes? A organização da área Cliente, o PO, ele não está sabendo se organizar direito. Na verdade, a priorização dele está meio confusa.

Por quê? Porque ele não está preparado para ser PO, faz pouco tempo que eles estão trabalhando com Scrum. O conhecimento do método é muito baixo e eles também não querem conhecer mais do método, eles fizeram os cursos e está tudo bem.

Eles não têm uma visão de como eles poderiam melhorar, estão jogando o jogo. É assim que os clientes estão andando. Nós precisamos entender se essa mudança de Scrum para Kanban é uma boa. Essa é a proposta que a Léia Líder vai fazer no próximo vídeo.

O que é Kanban - Scrum Vs Kanban

Você acha que faz sentido comparar Scrum com Kanban? Eu vou dizer que vamos achar todos os tipos de respostas: vão ter as pessoas que vão falar que não dá para comparar as duas coisas, vão ter pessoas que vão falar que tem que comparar, tem que escolher. Mas precisamos entender o que a Léia Líder quer com essa proposta. Qual é a proposta da Léia Líder?

Ela disse o seguinte: "eu queria mudar do framework Scrum". Imagine que você está em um cenário onde houve uma implantação de Scrum, as pessoas ainda estão se adaptando, já estão trabalhando com Scrum há algum tempo. Algumas pessoas gostaram, outras não, mas ela está propondo mudar. Então, de uma certa forma, isso já é uma proposta complexa. Ela quer implantar o método Kanban.

Ela está dizendo, a Léia Líder, ela entende que o Scrum é um framework e que o Kanban é um método. Ela está dizendo o seguinte: eu acho que deveríamos mudar só para as equipes que são focadas em manutenção de sistemas. Na Bytebank tem alguns squads que fazem desenvolvimento de novos produtos, desenvolvimento de features de produtos e tem alguns que são focados em manutenção de sistemas.

A Léia Líder está propondo que somente os squads que tenham esse foco em manutenção comecem a usar o método Kanban. Ela acha que para esses squads não deveria ter esse PO na área de negócio, não deveria ter o PO. Ela também acha que seria importante usar um quadro físico e não uma ferramenta eletrônica. Ela acha que essa ferramenta eletrônica deveria ser pausada por um tempo.

Ela está fazendo essas propostas, mas precisamos entender porque ela está propondo isso. Quais são as reações que isso causa? A Mana Ger e o Léo Rico, eles têm visões diferentes sobre isso. Eles querem saber o seguinte: os membros da equipe de desenvolvimento estão de acordo? A primeira pergunta que eles fazem para a Léia Líder: você falou com os desenvolvedores? Eles estão de acordo com isso?

Quais são as vantagens de usar Kanban? Lembre-se de que tanto a Mana quanto o Léo, eles não conhecem muito bem Kanban. E eles queriam saber se a proposta é para todas as equipes - a Léia Líder já disse que é só para as equipes de manutenção sistemas, ela deixou isso bem claro. A Mana e o Léo ficaram com uma dúvida: Léia você acha que o Scrum é ruim?

Então a Léia resolveu fazer uma apresentação sobre as principais diferenças de Scrum e Kanban para justificar porque ela acha que para a manutenção de sistemas o Kanban é melhor. Ela fez uma comparação entre iterativo e incremental e o fluxo contínuo. De uma maneira geral, o Scrum ele está mais para iterativo e incremental enquanto o Kanban está mais para fluxo contínuo.

"Sabino, por que você fala que está mais para?" Porque não dá para definirmos de uma forma cabal porque depende um pouco de como é operacionalizado, tanto o Scrum quanto o Kanban. Mas, na teoria, e se fizermos de uma forma mais próxima dessa teoria, então teremos o Scrum iterativo e incremental, o Kanban fluxo contínuo.

O iterativo e incremental do Scrum, ele é dividido em sprints, que vão até a um mês. Os incrementos, eles levam o produto a um objetivo. Nenhuma alteração é feita que coloque em risco a meta da sprint. Então quando o Léo precisa alterar alguma coisa - por quê? Porque surgiu algum problema, ou uma melhoria, que é muito mais prioritária, ele tem que esperar a próxima sprint.

No fluxo contínuo do Kanban, os cartões devem fluir de uma maneira mais contínua. Os impedimentos têm que ser eliminados o mais rápido possível para termos essa fluidez. E deveríamos manter um work in progress baixo - WIP é work in progress, que é trabalho em andamento. Isso aqui é fundamental para entendermos Kanban: work in progress, trabalho em andamento, é fundamental para entendermos Kanban.

Vamos fazer aqui outra distinção que também gera algumas polêmicas: o Kanban, ele é considerado um método enquanto o Scrum é um framework. Você vai encontrar autores que dizem que o Kanban também é um framework. Eu, particularmente, acho que considerar o Kanban como um método é mais adequado do que considerar como um framework.

O método, ele é pouco prescritivo. Um dos princípios do Kanban é comece com o que você já tem, e o método tem mais essa pegada, então comece de onde você está. Não tem definição fixa de papéis, vamos dizer que não tem definição fixa porque algumas implementações de Kanban, ou alguns autores, vão sugerir dois, três papéis, mas é sugestão, o método Kanban em si, ele não prescreve papéis.

Ele também não define cerimônias. Alguém que já conhece o Kanban vai falar: "não, mas tem as cadências, as cadências no final são como se fossem cerimônias". Sim, mas são sugestões, você pode fazer Kanban sem as cadências, sem essas cerimônias. E o framework? O framework, ele é mais prescritivo quando comparado a um método.

Ainda que trabalhar com Scrum seja, de uma certa forma, menos prescritivo do que trabalhar com uma metodologia, mas o framework em si, ele é prescritivo, você tem papéis - PO, Scrum Master, time de desenvolvimento - você tem cerimônias, você tem os artefatos, então tem coisas que você tem que seguir.

Ele define papéis, ele define as cerimônias, que no Scrum guide, em português, são chamadas de eventos, artefatos, então ele é mais prescritivo. O Scrum é mais prescritivo, na sua maneira de trabalhar, do que o Kanban. E para a maturidade do time, qual é a diferença de Scrum e Kanban?

Kanban, ele pode causar menos resistência justamente porque ele é menos prescritivo. Não é necessário conhecer muito de agilidade para usar Kanban, você pode ir começando, é a ideia do learning by doing, você vai fazendo e você vai aprendendo, você não precisa aprender antes para entender como você vai aplicar o framework e depois começar a aplicar.

Você pode começar a trabalhar com Kanban sem conhecer nada de agilidade e você vai aprendendo com o tempo. Você pode manter os papéis mais naturais, ou seja, aqueles papéis que você já tem ou os papéis que são mais comumente entendidos pelas pessoas naquele setor, naquele ramo de atuação.

A maturidade no sistema Kanban vem com o tempo, então você vai praticando e você vai aprendendo. Você não precisa fazer a disrupção de implantar o Kanban de uma forma muito forte, ter muito treinamento, essas coisas. Isso tem a ver com a maturidade do time e também com o conhecimento do time em agilidade.

E trabalhar com o backlog ou com gestão visual. "Sabino, então quer dizer que o Scrum tem backlog e o Kanban tem gestão visual?". Não. Na verdade, os dois têm os dois. O Scrum tem backlog e pode ter gestão visual, é bom que tenha. O Kanban, ele tem gestão visual e ele pode sim trabalhar com backlog.

Normalmente você vai trabalhar com os dois, mas o Scrum guide, se você olhar no Scrum guide, você verá que ele fala de backlog, mas o Scrum em si não fala de gestão visual. O Kanban, ele fala mais de gestão visual, mas você acaba usando o backlog dentro do quadro Kanban. Mas, de uma certa forma, podemos associar um backlog mais forte ao Scrum e gestão visual mais forte ao Kanban.

Vamos lá, o backlog admite várias formas de gestão. Você pode gestionar o seu backlog de várias maneiras diferentes, possibilita o uso de várias ferramentas e simplifica as regras de requisitos. Os requisitos ficam simplificados quando você pensa em um backlog. A gestão visual, o foco não é no que você tem para fazer, mas como você vai gerenciar isso que você tem para fazer.

Ela cria um foco no processo, você vai ver o processo, você tem que ver o processo acontecendo. Ela facilita a visualização de gargalos, porque você está vendo o que está acontecendo - claro, desde que você aplique o método corretamente e realmente visualize o quadro. Ela agrega o time em torno de um objetivo. Por quê?

Porque na gestão visual você está visualizando o trabalho, você está materializando o trabalho. E ela explicita os erros no fluxo de trabalho. "Sabino, você está dizendo que o Kanban faz isso e o Scrum não?". Eu não estou dizendo isso. Eu estou dizendo que a gestão visual, que é mais forte no Kanban do que Scrum, ela ajuda nessas coisas todas, mas você pode usar Scrum e gestão visual sem problema nenhum.

Muito bem, essa é a explicação que a Léia Líder tem e ela chegou às seguintes conclusões: ela recomenda Scrum para produto novo, para produto em produção, mas não recomenda para manutenção de produtos. Ela não recomenda Kanban para produto novo, ela acha que sim, pode ser usado para produto que já está em produção.

Então para criar features de produtos que já estão em produção, para criar funcionalidades novas, para criar módulos novos em produto em produção. Mas ela acha que a manutenção de produtos tem que ser com Kanban. Se olharmos o quadro que a Léia Líder montou, para produto novo só Scrum.

Para manutenção de produtos, só Kanban. E para criar coisas novas, mas para um produto que já está em produção? Novas funcionalidades, novos módulos, então aqui ela acha que pode usar os dois. Essa é a explicação da Léia Líder. O que você acha? Devemos ou não mudar de Scrum para Kanban quando estamos trabalhando com manutenção dos sistemas?

Sobre o curso Kanban: análises para implementação

O curso Kanban: análises para implementação possui 126 minutos de vídeos, em um total de 38 atividades. Gostou? Conheça nossos outros cursos de Gestão de Produtos em Inovação & Gestão, ou leia nossos artigos de Inovação & Gestão.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• O que é Kanban
• Gestão visual
• Importante Vs urgente
• Work in Progress
• Medindo o trabalho