Love The Road - Kanban não é um método "Team Level" (Agile Trends)

O título da palestra é Kanban não é um método team level. A ideia era explorar um pouquinho o Kanban além do nível de team level. Na verdade, não era nenhuma crítica ou nada falando mal de usar Kanban em nível de time, pelo contrário. A ideia era abrir um pouco a cabeça do pessoal de que em nível de time a gente só vai até certo ponto. E o que a gente pode ter além disso?

A metáfora que eu fiz no início é: você ter o Kanban em nível de time é a mesma coisa que você ter uma Alexa e só ficar pedindo para ela tocar raça negra. A Alexa tem um monte de funcionalidade. A inteligência artificial pode te ajudar com lista de compras, mexer em acender a luz da sua casa, cuidar de temperatura, termostato, todo esse tipo de coisa da casa inteligente. Então, o que a gente pode ir além do Kanban em nível de time? O Kanban em nível de serviço. Quando a gente fala em nível de serviço, a gente está falando de prestação de serviço. A gente está falando que alguém, uma empresa ou algum lugar tem um problema, acontece em uma série de atividades e aí essa pessoa ou essa empresa reconhece que o problema dela foi solucionado. Isso é um serviço, é um fluxo ponta a ponta.

A principal mensagem da minha palestra era: o Kanban em nível de time, ele te ajuda até certo ponto. Seria como numa pizzaria, você está preocupado com o forno e ter um forno melhor, e ter um forno que assa pizza rápido, que seja mais crocante, mas e o delivery? E o pessoal que pega o pedido? E a caixa da pizza? Tudo isso vai fazer diferença para a experiência final da sua pizzaria. E em nível de serviço seria a gente olhar ali para o desenvolvimento de software, de como olhar isso ponta a ponta.

O Kanban é um método para serviço. Ele já foi pensado nesse sentido. O que acontece é que em muitos lugares a gente começa pela equipe de desenvolvimento. O time vai lá e começa a limitar o seu WIP, aí usa aquelas práticas gerais do Kanban, faz o abastecimento do fluxo, e vai ali fazendo a sua Kanban Meeting e tudo mais. Só que o que acontece é que antes do item de trabalho chegar para a equipe de desenvolvimento, e muitas vezes depois que a equipe de desenvolvimento dá aquele item por concluído, acontece um monte de coisa. Tem áreas de negócio, tem áreas que fazem discovery, tem um monte de coisa que acontece, chega para a equipe de desenvolvimento, o pessoal desenvolve, e aí depois tem áreas de homologação, muitas vezes até separadas, de outras equipes. E aí tem a área de gestão, e aí a área que vai pôr o software em produção. E o Kanban respeita tudo isso. É como se a gente pensasse que aquele quadrinho do time de desenvolvimento, a gente escalasse ele na largura. É como se eu puxasse as pontas do quadro e fosse como um elástico, puxando. E deixa eu entender o que tem antes desse fluxo aqui do desenvolvimento. E o que tem depois. E olhar para isso para nos ajudar a gerenciar o fluxo ponta a ponta.

Entendido esse mapeamento ponta a ponta, a gente entende e gerencia esse fluxo. O principal é que nas lentes do Kanban, o serviço, ele independe se você tem um time, tem dois, tem dez. A questão é você ver o trabalho fluindo. O conhecimento, o trabalho do conhecimento partindo de um cenário que é uma ideia e se materializando. No caso do software, como o software funcionando. Então a partir do momento que você vê isso ponta a ponta, além de olhar em separado cada momento de cada time participando desse fluxo, o que você pode melhorar, você vê os atritos que acontecem nessa passagem de trabalho, às vezes até de uma equipe para outra. A sua organização é um sistema complexo. Existem dependências e onde você tem o trabalho fluindo. Ele não é uma soma de times. Se você pegar cada time da sua organização e tem uma implementação Kanban em nível de time só naquele pedaço, não quer dizer que você está melhorando a experiência do cliente ou melhorando o trabalho para o cliente. É todo um somatório de como o trabalho flui entre essas equipes e as suas dependências.

Para mim, o fluxo do serviço, enxergar o fluxo do serviço, traz esse ganho de: deixa o time de lado, vamos entender o trabalho aqui e vamos entender como isso pode ser melhorado.

Na palestra, eu dei quatro sugestões para o pessoal de coisas que podem ser feitas em relação ao olhar o serviço ponta a ponta. Uma delas é o fluxo upstream. É o universo das ideias, é o universo que os itens ali, eles ainda são opções. Uma dica bem legal, prática mesmo, que mudou o jogo para mim no upstream, é colocar no upstream, inclusive, o refinamento técnico. Às vezes, a gente fica achando que upstream é coisa de UX, upstream é coisa da área de negócio. Mas não. Quando você está selecionando opções, entender tecnicamente o que tem que ser feito, o que pode ser feito, abordagens ali, antes de você se comprometer com a demanda. Então, ter esse refinamento técnico em upstream é uma coisa legal.

Outra coisa que eu levei para o pessoal são as cadências em nível de serviço. No Kanban, a gente tem algumas cadências sugeridas. O replenishment, que é a cadência do abastecimento do fluxo. A gente tem a cadência da Kanban Meeting, que é a daily, aquele momento que a gente, estrategicamente, ali, discute sobre o trabalho, o que a gente vai fazer, ou se vai precisar reabastecer o fluxo. E a retrospectiva também. A gente pode, em um determinado momento, entender o fluxo de trabalho em nível de time. A gente pode extrapolar essas cadências em nível de serviço. O item de trabalho está entrando lá na ponta esquerda do nosso quadro, ele ainda é uma ideia, e aí essa ideia vai amadurecendo. Poxa, por que que a hora que a gente não abastece ali o fluxo, de repente, no nosso serviço, tem três, quatro equipes envolvidas? Tem um time de homologação, tem um time de desenvolvimento. Por que que o time de homologação vai saber o que está sendo feito? Será que eles não poderiam estar preparando uma massa de dados, automatizando alguma coisa, só por saber que aquele tipo de item de trabalho está entrando lá na ponta do lado esquerdo do fluxo, ainda, como uma ideia? Então, essa cadência de abastecimento do ponto de vista de serviço, a Kanban Meeting, do ponto de vista de serviço, ela não precisa ser diária, mas ela pode ser semanal, com os envolvidos no serviço. Se tiver cinco equipes envolvidas no serviço, ela pode ser para todo mundo, pode ser só as lideranças dessas equipes, ou pessoas que tenham trabalho no fluxo, para a gente entender dependência. A retrospectiva, que é o Flow Review, a mesma coisa. Por que que a gente não faz uma retrospectiva em nível de serviço? Não da equipe, mas dos envolvidos no serviço como um todo, para buscar essa melhoria, inclusive na transição entre equipes, se ela existir. E aí, com base nisso também, às vezes você pode ter até uma cadência separada, que a gente chama de Block Clustering. Todo o impedimento que você teve dos itens de trabalho passando pelo fluxo, você guarda aquele impedimento, para depois você discutir com os envolvidos no serviço, se aquele impedimento a gente aprendeu alguma coisa, pode ser evitado, se tem algum plano de ação.

Além disso, eu trouxe o conceito do Customer Lead Time, a métrica do Customer Lead Time, que é quanto tempo na percepção do cliente ele levou para ele receber alguma coisa, para ele reconhecer o valor entregue. Seria como se você ligasse na pizzaria e da hora que você desligou o telefone e a pizza chegou na sua casa, quanto tempo levou? E se a gente ficar medindo só o Lead Time do serviço, talvez você só está medindo se a sua pizzaria está sendo rápida em fazer a pizza. Mas e o tempo de processar esse pedido, do entregador pegar o pedido e levar até a casa da pessoa? Tudo isso conta na experiência de usuário. E às vezes o Customer Lead Time é muito maior do que o seu Lead Time, pensando no serviço ponta a ponta e na percepção do seu cliente.

E por último, eu comentei de você olhar métricas de fluxo como o CFD, você olhar pensando no serviço. E não necessariamente só na equipe. Entender, porque às vezes você tem um desbalanceamento entre equipes dentro de um mesmo serviço, e aí o trabalho enrosca, o trabalho para em filas.

Então a ideia ao final da palestra era: abre a cabeça, não pense em time, pense em trabalho fluindo. Se isso passar por um time, por cinco ou por dez, você consegue gerenciar esse fluxo e ver os benefícios a partir desse gerenciamento.

Dentro do conteúdo de Kanban, do próprio David Anderson, o livro da Capa Azul, tudo isso tem serviços envolvidos ali. Então, às vezes o pessoal olha em separado, o upstream e o delivery, é juntar tudo, é tudo a mesma coisa. Então, essa é uma forma fácil de entender.