Utilizando as práticas gerais do método Kanban no contexto do framework Scrum

Imagine por um momento que não precisamos comparar nada entre Kanban e Scrum. O objetivo deste texto é mostrar as práticas gerais do método Kanban e como podemos utilizá-las em um contexto Scrum. Apenas isso!!

Visualizando as demandas: Em termos gerais, equipes Scrum já utilizam um quadro Kanban. No entanto, será que estamos utilizando-o apenas para organizar o Sprint backlog, ou estamos trabalhando em conjunto com os estrategistas da companhia para filtrar o que realmente é importante para a organização e nossos clientes? Será que estamos realmente visualizando todo o trabalho em execução, ou existe trabalho oculto? São perguntas que levantamos na prática de visualização, e assim podemos elaborar um design de card com as informações necessárias, compreender a turbulência do fluxo e identificar onde estão os gargalos ou até mesmo as fontes de atrasos, dependendo da maturidade do grupo

Limitando WIP: O seu grupo está equilibrando de maneira saudável a capacidade e a demanda do que foi definido na Sprint, ou continuam engargalando processos no fluxo e usando a desculpa verdadeira “já fiz a minha parte!!!”, ou em casos extremos “agora esse problema é do tipo DELE(A)!”. Poderíamos citar várias situações onde o trabalho em progresso pode ser limitado, mas não queremos apenas colocar um número no cabeçalho de uma coluna. Queremos que o time de desenvolvimento construa políticas explicitas sustentáveis que façam parte da realidade do contexto, e assim emerja a limitação do trabalho em progresso naturalmente.

Gerenciando o fluxo de trabalho: Os incrementos no final de uma Sprint são balizados pela capacidade/velocidade da equipe, pelo histórico de entregas ou, até mesmo, por questões empíricas norteadas pela falsa sensação de tamanho proporcionada pelas escalas muitas vezes lúdicas que provavelmente não farão sentido na próxima Sprint. Aqui buscamos a oportunidade de gerenciar o fluxo de trabalho para alcançar o equilíbrio entre a demanda e a capacidade, usando um retrovisor honesto do nosso ritmo de trabalho. Algumas informações importantes que podemos destacar: classe de serviço, eficiência no fluxo, lead time do cliente e lead time do sistema podem e devem ajudar na construção do retrovisor. Lembrem-se de que o objetivo do fluxo de trabalho deve maximizar a entrega de valor, minimizar os ciclos de tempo e ser o mais previsível possível.

Construindo Políticas Explícitas: Provavelmente um dos pontos mais desafiadores em equipes Scrum, pois afeta significativamente a elaboração da Sprint backlog durante a Sprint planning e a análise do incremento no Sprint Review. Nesta situação, estabelecemos as bases para um processo de reabastecimento consistente, alinhado com as necessidades do cliente, juntamente com a estrutura de entrega, onde verificamos se estamos cumprindo o acordado. Logicamente, estamos falando de DoD, DoR, critérios de aceitação, enfim, todos os elementos essenciais para entregar com qualidade o que foi solicitado. Aqui não se trata de “Entrega de Valor”, mas sim de “Escolha de Valor”! Essas políticas são visíveis para todo o time, ou chegamos no final da Sprint e os membros mais antigos repetem a frase “Não acredito que você não fez TDD???”?

Estabelecendo ciclos de feedback: Dentre os benefícios evidentes que podemos destacar nos ciclos de feedback, seguramente o que ganha destaque é a tomada de ação após receber e entender o contexto. Isso significa que, uma vez que conhecemos o problema, é obrigação do grupo buscar uma solução e seguir em frente. Claro que algumas ações necessitam que aterrizemos no Sistema 2 e que apliquemos um pouco mais de intelecto para encerrar o assunto. Em outro momento, “vamos que vamos!” com o Sistema 1, pois entendemos os riscos e conhecemos bem os impactos e alternativas pós mortem. Lembre-se de que problemáticas do Sistema 1 para algumas pessoas podem não ser problemáticas do Sistema 2 para outras pessoas, então lembrem-se de que “Não há julgamentos no Kanban” (frase de David J. Anderson).

Melhore colaborativamente, evolua experimentalmente: De maneira sucinta, podemos começar a pensar em um processo evolutivo condicionado à identificação dos motivos da insatisfação do cliente: Por que os clientes estão insatisfeitos? Além disso, em um trabalho conjunto, podemos abordar as fontes de insatisfação interna que estão bloqueando as pessoas e equipes de entregar algo alinhado às expectativas do cliente. É de suma importância pensar em entregas menores, porém consistentes, onde a validação da hipótese seja palpável e haja retroalimentação sobre como nossos clientes estão consumindo nossos produtos ou serviços, para os grupos que se sentirem à vontade. Colocar o F4P Card na mesa após a Sprint Review pode ser uma boa sugestão.