Migrando do framework Scrum para ScrumBan

Sou uma Agilista há quase 5 anos, mas, durante toda minha carreira, pude ter a vivência de gerenciar projetos durante mais de 12 anos, o que me possibilitou adquirir experiência suficiente satisfatória para que, ao invés de focar em seguir o Guia do Scrum, analisar o cenário em que atuo no momento, identificar seus problemas e, por fim, sugerir mudanças nos processos com base em outros frameworks, métodos e metodologias, que venham a resolver essas questões, gerando valor para aquela determinada realidade.

Depois de ter atuado como Gerente de Projetos, Mestra do Scrum e Dona do Produto em diversos setores tais como Saúde Animal, Telecomunicações, Tecnologia, Logística, Expatriação, Instituições Financeiras, entre outros, de junho de 2020 a Março de 2021 atuei como Agilista em um conceituado e internacional Programa para um cliente, que é uma rede de postos de gasolina e lojas de conveniência américo-canadense.

Desde o início estávamos rodando o framework Scrum, com o qual o time já estava familiarizado e tínhamos o seguinte cenário:

• Time de Desenvolvimento atuava em dois produtos ao mesmo tempo;
• Meta da sprint clara a ser atingida a cada 2 semanas;
• Dev Team trabalhava mais junto, num mesmo item, para entregar aquele objetivo;
• Havia poucas alterações nas demandas;
• Saber sua velocidade era essencial para o planejamento da próxima iteração (Sprint);
• Os stakeholders viam mais valor em entregarmos o objetivo (meta da sprint) inicialmente definido;
• Time estava adaptado e via valor nos eventos do Scrum.

O que nos motivou a mudar os processos, visando a adaptá-los a uma nova realidade:

Depois de 10 sprints rodando com o framework Scrum, com base em feedbacks constantes do Time de Desenvolvimento, pude perceber que houve alterações no nosso cenário, as quais, possivelmente, demandariam mudanças nos nossos processos. Nossa nova realidade passou a ser esta:

- A sprint começou a falhar, pois havia a necessidade de atender a mais de uma meta contendo diversos objetivos, simultaneamente, e estes mudavam ao longo da iteração;

- Surgiu a necessidade de que cada Dev trabalhasse, individualmente, em cada demanda que chegasse, a fim de darem conta de todas elas, que chegavam em maior quantidade;

- Os stakeholders começaram a mudar, com grande frequência, suas demandas, então passaram a ver mais valor na agilidade do Dev Team, ou seja, em se adaptar rapidamente a essas mudanças;

- Time de Dev carecia saber em qual momento deveria arrastar, no board do Jira, um item, para a próxima etapa do ciclo de entrega de valor, ou seja, queria saber o que seria considerado pronto para iniciar a próxima etapa;

- O Time de Desenvolvimento sentia falta de mais informações para considerar um item pronto para começar, tendo que dedicar muito tempo em refinamento;

- Time perdia tempo estimando o esforço de itens, sendo que, a qualquer momento, poderiam chegar outros mais prioritários, tendo que serem acomodados na sprint.

Como Foi o Processo:

Então, como Agilista e, portanto, parte do Time de Scrum, resolvi selecionar alguns pontos desse novo cenário, deixá-los mais transparentes e resumidos e levá-los para serem discutidos, como pontos a melhorar, na Reunião de Retrospectiva da Sprint; foram eles:

• Não estávamos conseguindo seguir o planejamento da reunião de Planejamento da Sprint (não atingimos a meta da Sprint com uma certa frequência);
• As prioridades mudavam com frequência e, muitas vezes, não tinham nada a ver com a meta da sprint (meta fica obsoleta);
• Nossa equipe trabalhava em mais de um produto ao mesmo tempo, o que dificulta o estabelecimento do objetivo e o entendimento da priorização;
• Precisávamos ser mais flexíveis para atender às mais diversas demandas dos clientes (eles viam mais valor na nossa agilidade, capacidade de se adaptar rapidamente a mudanças).

Após uma produtiva discussão entre os membros do time sobre os pontos acima, no momento da definição do plano de ação, o Time de Desenvolvimento verbalizou a necessidade de que processos fossem alterados, de modo a se adequarem ao novo cenário, a fim de que ele pudesse continuar trabalhando com motivação, propósito e produtividade, entregando valor.

Assim, o ponto de ação que o Time de Scrum definiu, em conjunto, foi: “Vanessa proporcionará ao time uma reunião para falar sobre as sugestões que a equipe trará sobre os novos processos.” Eu poderia ter aberto a discussão com um brainstorming, incentivando o time a trazer sugestões, porém, para não tornar essa reunião longa e maçante, no mesmo dia da Retro, abri um board na ferramenta FunRetro (atual EasyRetro) e pedi que o time já fosse registrando suas sugestões, dias antes da discussão. Dessa forma, no dia do nosso bate-papo, a ideia era passarmos por cada sugestão, pedindo que o dono dela esclarecesse do que ela tratava, dando transparência, fizéssemos uma votação, elegendo as mais importantes delas e colocando um plano de ação imediato para elas, o que resultaria na redefinição de processos. Realizei que esses novos processos, por contarem com elementos do framework Scrum e do método Kanban, poderiam ser traduzidos em um método híbrido que uniria características do framework Scrum com aspectos do método Kanban, o qual chamaríamos de “ScrumBan”. Este funcionaria da seguinte forma:

• Substituição do board de Scrum pelo board de Kanban de forma que o time trabalhe de forma mais “tarefeira”, a fim de atender às constantes mudanças de demanda;
• Utilizar a limitação de WIP, de forma que um Dev trabalhe em apenas um item por vez;
• Eventos do Scrum mantidos, pois o time acreditava que gerava valor e que não havia necessidade de substitui-los pelos do Kanban e também porque outros quatro times internacionais também faziam parte desses eventos junto ao time do Brasil;
• Não mais definir uma meta e que a Dona do Produto sempre deixasse ao time as prioridades atualizadas;
• Modificar o fluxo de entrega de valor, na ferramenta Jira, a fim de que transparecesse a atual realidade, inclusive detalhando melhor as colunas dentro do fluxo;
• Na Reunião de Planejamento da Sprint ou na reunião de Refinamento não mais estimar esforço dos itens de trabalho;
• Implantação de Políticas Explícitas, ou seja, acordos que possibilitariam entre membros do Time de Scrum, que abrangiam, entre outros, os seguintes aspectos:

1. As estórias / bugs conterão uma estrutura específica para que o Dev Team esteja munida da informação necessária para começar a atuar;

2. Campo “prioridade” das pendências será utilizado: ao invés de fazer uso das Classes de Serviço, por ora, o time preferiu que nosso board fosse configurado baseado em 4 níveis de prioridades: crítica, média, menor, trivial;

3. Product Owner é quem define e redefine prioridades (antes estas chegavam através de diversas fontes, tais como stakeholders, arquitetos, gerente de projetos, líderes técnicos);

4. Dev Team focar em dar seguimento aos itens que estão mais próximos de estarem prontos (“parar de começar” e começar a terminar”);

5. Ao mudar a prioridade de uma estória, a Dona do Produto avisar a Mestra do Scrum, num canal específico da ferramenta Slack, e a Scrum Master vai atualizar as prioridades das respectivas subtasks, que seriam tarefas técnicas, escritas pelo Time de Desenvolvimento, a fim de atingir o objetivo da respectiva história.

Resultados:

O aumento da motivação do Time de Desenvolvimento ficou evidente e demonstrado através do aumento da pontuação média do Dev Team no Team Health Check, que eu aplicava, quinzenalmente, nele.

Além disso, começaram a aparecer, nas Reuniões de Retrospectiva das Sprints seguintes, como tópicos positivos, comentários que reforçam a eficácia da mudança para o ScrumBan, bem como um notável aumento na motivação do time como, por exemplo:

• Sprint 11:
• “A equipe sempre se esforçou para atender as frequentes mudanças de demandas”.
• Sprint 12:
• “A equipe colaborou muito, trazendo sugestões de melhorias para a reunião de mudança de processos”;
• “Mudança do Scrum para o Scrumban”;
• “Discussão muito útil sobre a melhoria dos processos, bem como a boa atitude da equipe em relação à essa necessidade”;
• “Equipe comprometida com a qualidade da entrega”;
• “Discussão muito útil sobre a melhoria dos processos, bem como a boa atitude da equipe em relação à essa necessidade”.
• Sprint 13:
• “Discussões relacionadas à implementação do ScrumBan e à adaptabilidade da equipe para ajustar o board nas últimas duas semanas”;
• “A equipe se ajustou muito bem ao Kanban e deu excelentes sugestões sobre mudanças no board”;
• “A equipe deu muito apoio e ofereceu ajuda sempre que necessário”.
• Sprint 14:
• “Nossa Scrum Master, Vanessa, é sempre muito útil e rápida em relação às nossas necessidades sobre o Quadro Kanban”;
• “Mudança no framework de desenvolvimento”.

Conclusão:

Gosto de reforçar que nenhum framework, método ou metodologia é uma “bala de prata”. É imprescindível que o Agilista observe, a fundo, o cenário em que está inserido e, constantemente, reveja se os processos antes implementados por ele, continuam ou não fazendo sentido.

É essencial também que o Mestre do Scrum, através da observação do contexto atual, escolha focar, com perspicácia, na instância de seu papel mais adequada para aquele determinado momento, como a de agente de mudanças, utilizada por mim nesse caso.

Uma outra dica é, ao notar que há disfunções que o time não identificou ocorrendo repetidamente, o Agilista aja rapidamente, levando-as como pontos a melhorar na Reunião de Retrospectiva da Sprint, que é a oportunidade formal de se discutir também sobre processos.

Não menos importante é o Agilista não se apegar a frameworks, mas sim a entender os problemas e necessidades atuais do time, incentivando-os a refletir e apresentar sugestões, o que os ajuda a ter sentimento de pertencimento e motivação e só então ir em busca de aspectos dos mais variados métodos ou metodologias que vão colaborar para a resolução das disfunções, ou seja, que gerem valor.

Por fim, os Agilistas precisam ser ótimos ouvintes e observadores e verdadeiros captadores de feedback do time! Afinal, como bons facilitadores, precisamos sempre inspecionar — a fim de verificar se os processos estão ou não funcionando — e adaptar — de maneira que nossos processos estejam sempre aderentes à nossa realidade, colaborando diretamente para uma entrega de incremento eficaz e mantendo a saúde e felicidade do time e deixando satisfeitos nossos clientes.