Você já se viu trabalhando em um projeto e sentiu que talvez uma estratégia diferente possa ajudá-lo a ser mais flexível em face das contínuas mudanças nos negócios? Normalmente, as equipes enfrentam a decisão de implementar um framework ágil e o mais comum é o Scrum. Mas nem sempre é a maneira mais adequada de atingir nossos objetivos. Explicarei um exemplo onde Kanban ajudou minha equipe a melhorar a satisfação das partes interessadas e enquanto nos organizarmos melhor como equipe.
O Scrum está funcionando aqui?
Há um ano, nossa equipe tinha como objetivo implementar mudanças de software para diferentes áreas de negócio de uma empresa de varejo. Inicialmente, decidimos implementar o framework Scrum. Uma cadência de sprint de duas semanas nos permitiria nos concentrar na meta do sprint e receber feedback de negócios nas revisões de sprint.
Nossa ideia era ter as histórias de usuários mais importantes para a empresa no topo da lista de pendências. Às vezes, nos deparamos com a decisão de substituir uma história de usuário que já estava em andamento no sprint por outra que apareceu repentinamente no radar de negócios. O problema é que essa situação se tornou muito frequente e esses requisitos emergentes eram difíceis de adicionar durante o sprint.
As equipes que implementaram Scrum sabem que existe alguma flexibilidade. É possível substituir itens no backlog do sprint se as prioridades do produto mudarem repentinamente durante a execução do sprint. A questão é que essa era a regra, e não a exceção. Então, como podemos gerenciar um fluxo de trabalho que nos ajude a reagir melhor a essas mudanças imprevisíveis? E a questão subjacente: essas mudanças são reais nas prioridades dos negócios? Ou não estamos considerando algumas ideias dos stakeholders ao definir nossas metas de sprint?
Inspecionar e adaptar o processo
Em primeiro lugar, o Product Owner confirmou que essas mudanças repentinas realmente faziam parte do contexto dos negócios. Diversas áreas do negócio estiveram representadas por diferentes stakeholders que solicitaram os nossos serviços. A priorização, com base na urgência e na importância de suas solicitações, era volátil e difícil de prever.
Como resultado, decidimos adaptar nosso processo com o objetivo de fazer planos breves e sermos capazes de reagir mais rapidamente às possíveis mudanças. O método Kanban pareceu a forma mais adequada de implementar nosso fluxo de trabalho e o Dono do Produto apoiou essa decisão. Tínhamos algumas preocupações, algumas relacionadas à nossa equipe e outras relacionadas aos stakeholders.
- Internalize Kanban com a equipe
A equipe identificou, em retrospectivas anteriores, que uma estratégia diferente nos ajudaria, então estávamos abertos às possíveis mudanças. A questão era que nem todos tinham experiência anterior em trabalhar com Kanban, então poderia ser confuso mudar os processos. Talvez, a maneira tradicional de introduzir Kanban a uma equipe seja que os líderes expliquem os conceitos e definam as regras iniciais – mas tentamos algo diferente. Jogamos um jogo chamado “Pizza Kanban” que é um exercício adaptado dessa dinâmica para ensinar conceitos básicos. A ideia era descobrir iterativamente em equipe o melhor layout possível para gerar um fluxo contínuo cozinhando o máximo de pizzas possível. Vivenciamos as diferentes situações que ocorrem quando uma equipe implementa um sistema “Pull” e este jogo nos ajudou a entender os valores, princípios e práticas do Kanban. A lição mais importante aprendida com este jogo foi “parar de começar e começar a terminar”.
Como resultado, definimos os limites do trabalho em andamento e criamos uma ideia inicial de quando um item de trabalho está pronto e concluído. Claro, foi mais fácil para nós porque já tínhamos trabalhado com o Scrum antes e mantivemos as funções e responsabilidades. Além disso, continuamos a realizar reuniões diárias e retrospectivas (a cada 2 semanas).
2. Envolva as partes interessadas com o método Kanban
O projeto estava em andamento, portanto, havia o risco de perder a data de entrega de histórias em andamento. Usamos o processo STATIK (Abordagem de Pensamento Sistêmico para Implementar Kanban) para identificar a demanda, capacidade e pontos problemáticos reais. Constatamos que as prioridades não foram definidas corretamente devido à falta de comunicação com algumas partes interessadas. Também observamos que, se organizássemos nossas atividades prioritárias, poderíamos definir uma expectativa mais adequada com essas partes interessadas sobre quando um item de trabalho poderia ser concluído.
Decidimos introduzir uma reunião de reposição a cada duas semanas com todas as partes interessadas e incentivar sua participação. Este evento permitiria a eles comunicar suas necessidades e os motivos de cada nova solicitação em primeiro lugar, comparado aos seus parceiros . A ideia era que o Product Owner facilitasse a conversa e ouvisse todos eles. Poderíamos então decidir, após uma discussão saudável, quais dessas solicitações seriam atendidas primeiro por nossa equipe.
- Priorize usando Classes de Serviço (CoS)
O envolvimento das partes interessadas foi importante, mas o método para priorizar suas solicitações foi um fator ainda maior para ser totalmente transparente ao decidir em qual história de usuário trabalhar primeiro. Queríamos ser justos e usar de bom senso ao organizar nossa lista de pendências para que os usuários não se sentissem desconfortáveis. Decidimos experimentar o uso de Classes de Serviço (CoS), que é uma ferramenta versátil para lidar com situações incertas e imprevisíveis. Isso nos permitiria gerenciar dependências de acordo com o Custo de Atraso (CoD) dos itens de trabalho, que é o impacto econômico ao não entregar o serviço no prazo.
Analisamos quais tipos de solicitações foram recebidas no passado. Eram diferentes porque às vezes uma área de negócios só queria um recurso interessante em um processo. Outras vezes, eles precisavam de funcionalidade crítica que causaria várias perdas se atrasássemos a implementação. É assim que decidimos quando um item seria considerado Expedido, Tempo Fixo, Padrão e Intangível.
Inspecione novamente – estamos melhorando!
Após vários meses aplicando essas mudanças, recebemos um bom feedback das diferentes áreas de negócios e também pudemos aprender diferentes coisas:
- Limite o trabalho em andamento (WIP): nos ajudou a melhorar a colaboração e implementar um sistema “Pull”. O momento típico em que uma das histórias fica complicada leva uma conversa em equipe a encontrar uma maneira de finalizar essa história, em vez de começar uma nova. Foi surpreendente ver um desenvolvedor, que tem grande conhecimento de negócios, passar uma semana inteira ajudando os testadores a chegar, de fato, à definição para algumas histórias de usuário antes de iniciar o desenvolvimento de uma nova. Um fluxograma cumulativo foi usado para inspecionar periodicamente se esses limites estavam ajudando a melhorar nosso fluxo de trabalho.
- Visualize o fluxo de trabalho: Fomos muito transparentes no quadro Kanban. Quando uma história de usuário é bloqueada, ela permanece no quadro ocupando um espaço disponível. Isso nos obrigou a conversar com outras áreas de TI para obter ajuda e desbloquear o item. Além disso, isso nos permite dar visibilidade aos stakeholders sobre como foi o progresso e compartilhar com eles se temos a necessidade de uma resposta comercial para desbloquear um item – tendo em atenção que este tempo de espera impedirá o atendimento de outras áreas de negócio.
- Acordo no sentido de urgência: Ter uma reunião de reposição com todas as partes interessadas a cada duas semanas foi uma oportunidade perfeita para socializar com eles quais itens de trabalho foram concluídos e entregues por nossa equipe e para entender suas necessidades e expectativas. Foi surpreendente que, no passado, alguns deles tivessem tentado priorizar seus pedidos como urgentes porque queriam ter certeza de que estariam prontos para uma data específica. Aos poucos, a equipe ganhou a confiança dos stakeholders graças à implantação contínua de funcionalidades que fizemos. Além disso, gerenciamos métricas para saber se havia áreas dos negócios que não estavam sendo atendidas por um longo tempo para ajudá-las a justificar seus requisitos usando a ferramenta Classes de Serviço.
Conclusão
Este artigo não pretende afirmar que Kanban é melhor que Scrum ou vice-versa. Não existe uma receita estática para determinar quando um ou outro é mais apropriado. A ideia é que devemos sempre ter em mente que escolher um framework ou método para implementar em um projeto é apenas o primeiro passo. Portanto, devemos nos perguntar periodicamente como equipe o que está indo bem e o que não está. Devemos estar abertos para adaptar nossos processos de acordo com as mudanças ambientais e o contexto da situação.
