Do kanban ao scrum. Como a gente escolheu o método ágil

Por que a equipe de Micros Scale da Atlassian mudou do kanban para o scrum

Nelly Sattari Por Nelly Sattari
Buscar tópicos

Parte de ser uma boa equipe de engenharia é ser uma equipe auto-organizada! É ser uma equipe com funções e responsabilidades claras e estar comprometida com a entrega do projeto com um plano bem elaborado.

No ano passado, a gente criou uma nova equipe chamada Micros Scale que se concentra na criação da Plataforma como Serviço (PaaS) interna da Atlassian, a plataforma de experiência para desenvolvedores. Como o trabalho tem um escopo fixo e prazos claros, a gente se tornou mais comprometido em concluir o trabalho gradual, mais focado, orientado a metas e proativo.

No entanto, no passado, a equipe recebia muitos trabalhos operacionais ad hoc que impediam que a gente realizasse o planejamento adequado dos sprints. Um mínimo de 55% da capacidade da equipe foi alocada para as rotações de trabalho sem interrupção (KTLO). Isso fez do kanban a metodologia mais adequada para a gente na época.

É importante notar que, de acordo com o modelo Tuckman, a equipe da Micros Scale estava na fase de formação e havia algumas áreas de melhoria, incluindo planejamento de capacidade, planejamento de sprint, definição de metas, reflexão em equipe, preparação e elaboração de histórias, estimativa, detalhamento do projeto e assim por diante.

imagem do modelo tuckman

Qual metodologia ágil foi a certa para a gente?

A Micros Scale tem dois grandes projetos que são muito complexos e têm um prazo anunciado para os clientes. Isso significa que enviar mais rápido é crucial. A gente precisava de confiança na abordagem de entrega e queria trabalhar no planejamento como um profissional ágil. A equipe deveria ser auto-organizada, atingir metas comuns e ser empírica.

A gente reavaliou a abordagem ágil fazendo as seguintes perguntas:

  • É possível definir uma meta para cada iteração para atingir um objetivo com um tema exclusivo?
  • A gente pode se comprometer com o escopo das entregas por uma ou duas semanas?
  • É possível elaborar e definir os requisitos que devem ser cumpridos?
  • A frequência de solicitações ad hoc para alterar a prioridade da tarefa é baixa e é menos provável que a gente tenha mudanças drásticas?
  • A equipe é nova e não está tão madura em processos ágeis?


Como as respostas a essas perguntas eram sim, a gente percebeu que o scrum era a melhor metodologia ágil para a equipe. Aqui estão as informações adicionais que a gente usou para informar a decisão:

 

 

 

 

Metodologia ágil

Do que se trata?

Está ajudando a gente?

Por quê?

Scrum

O Scrum se trata de um roteiro claro e de partes priorizadas do trabalho, enquanto o kanban trata da visualização do trabalho, que é comparado com a da equipe de forma ad hoc.

Sim

A gente tem um backlog claro e predefinido que precisa de refinamento e priorização. O trabalho é previsível, ao contrário da equipe anterior, que era cheia de surpresas e solicitações de alta prioridade.

As histórias não devem ser alteradas no meio do sprint.

Sim

A gente pode adotar uma abordagem mais flexível; nesse caso, scrumban (um híbrido de scrum e kanban).

O scrum é mais fácil de adotar para equipes ágeis que ainda estão aprendendo a liderar recursos. O scrum é mais prescritivo, com rituais e prazos que oferecem barreiras de proteção.

Sim

A gente tem uma nova equipe com novos membros, ainda na fase de formação e confronto, então ter o scrum ajuda a gente a se tornar mais maduro. Leia o modelo Tuckman.

Kanban

Limitar o trabalho em andamento e focar na redução do tempo de ciclo do projeto. O caso de uso é quando a equipe não tem um limite de tempo para trabalhar e um cronograma comprometido. A solicitação chega à equipe e é atendida o mais rápido possível (como o SLA que as equipes de central de atendimento têm).

Não

Outras equipes dependem da gente, por isso a gente precisa de prazos estimados para ajudar outras pessoas a fazerem um planejamento adequado. É feito um anúncio púbico aos clientes da Atlassian sobre alguns dos compromissos, por isso é preciso estar atento e se preparar para eles. A gente não tem muitas solicitações de curto prazo, como uma central de atendimento.

Ótimo para equipes que têm muitas solicitações operacionais recebidas que variam em prioridade e tamanho.

Sim

A gente não tem uma carga pesada de KTLO e o fluxo de trabalho é gerenciado pela função de uma pessoa na equipe em rotação. A gente pode executar esse papel afetado como kanban, se quisermos.

A gente adotou o scrum

Estou ciente de que agir como condutora é uma das principais características de gerentes de engenharia, além de ser uma conectora, bússola e orientadora. Então, eu precisava adquirir habilidades de condutora da mesma forma. Veja como eu alcancei esse objetivo:

Saiba mais sobre a metodologia ágil

Os recursos internos de aprendizado da Atlassian me ajudaram a aumentar minhas habilidades em práticas ágeis. Passei por cursos extensivos de agilidade e me consultei com um orientador em agilidade. Entrevistei alguns gerentes de engenharia para aprender sobre as experiências deles com outras empresas e equipes.

Use DACI

A estrutura de tomada de decisão DACI — que significa “dirigente, aprovador, colaborador, informado” — foi usada para tomar decisões de grupo eficazes e eficientes. Orientei minha equipe pela proposta de mudança do DACI para garantir que eu tivesse os comentários, concordância e apoio dela.

Use um template de sprint

Criei um processo para gerenciar os sprints e criei um template para cada sprint para ajudar com um planejamento mais razoável. O template de planejamento de sprint incluía:

  • Como revisar o sprint anterior para garantir que a gente tenha clareza sobre o que conquistou e comemorar.
  • Como fazer uma análise retrospectiva sobre o sprint anterior e aplicar o aprendizado ao próximo.
  • O que é cadência, nome, metas e objetivos do sprint?
  • Quantas histórias a gente se compromete a entregar? Qual é o escopo do sprint?
  • Como fazer o planejamento de capacidade com base na disponibilidade das pessoas.
  • De quais atividades no meio do sprint a gente precisa para estar preparado por completo para o próximo sprint?
  • Como escrever histórias, elaborar os requisitos e uma solução para lidar com isso.
  • Como rastrear o estado das histórias com as quais a gente se comprometeu e o que fazer com as histórias inacabadas.

A gente também tem um ótimo tutorial sobre como fazer sprints no Jira Software.

Valeu a pena mudar para o scrum

A seguir estão as melhorias que a gente fez ao migrar para o scrum:

Melhoria da velocidade

Na metodologia ágil, um dos fatores para medir a produtividade de uma equipe é a velocidade, que é a quantidade média de trabalho que uma equipe de scrum realiza durante um sprint. A gente usa um gráfico de velocidade para entender com o que a equipe se comprometeu e o que foi entregue. No gráfico de velocidade abaixo, a coluna cinza revela o número de pontos da história com os quais a equipe se comprometeu com base na capacidade dela. A gente a compara com a coluna azul, que mostra quantos pontos da história ela entregou de verdade. Então, a equipe pode usar isso para ajustar as previsões para futuros sprints.

Gráfico de velocidade

Risco identificado no início

Ser capaz de identificar riscos logo no início e propor uma solução é a chave para o sucesso dos projetos.

Ao definir as metas e os temas do sprint, a gente escolheu histórias coesas para atingir as metas. Nas sessões de meio do sprint, a equipe preparou, refinou e elaborou histórias. Durante a elaboração, a gente perguntou:

  • O que precisa ser feito?
  • Por que a gente está fazendo este trabalho?
  • Que valor comercial ele agregaria?

Isso ajudou os engenheiros a identificar dependências e priorizar tickets com maiores impactos para remover obstáculos. E também levou a uma mudança na forma como a gente trabalhava e a um melhor foco na equipe por projeto.

Comemore! A gente lançou

O planejamento de capacidades e o estabelecimento de metas trouxe uma motivação significativa para a gente e o desafio de ser transparente nos compromissos. A gente entregou com sucesso uma fase crítica da fragmentação de contas PaaS da Atlassian. A gente também está prestes a entregar a primeira fase do projeto de residência de dados para cobrir mais regiões da AWS para fins de confiabilidade, resiliência e conformidade.

Transição da formação para a normatização

Como mencionei acima, a equipe da Micros Scale é nova e tende a estar no estágio de formação de acordo com o modelo Tuckman.

Definir uma meta unificada para a equipe inspirou todos a se alinharem e apoiarem uns aos outros para alcançar as metas e aumentar a motivação da equipe. A gente falhou, refletiu, aprendeu e melhorou. Depois de três meses e meio, a gente contratou mais 50% para a Micros Scale, e eu ainda avalio com orgulho a equipe como uma equipe de normatização.

Comunicação melhorada

Ter um plano e ser dedicado durante cada sprint aumentou a visibilidade do que a gente planejava fazer para toda a equipe e permitiu que a gente falasse a mesma língua. É muito mais fácil para gerentes de engenharia e partes interessadas acompanharem os impedimentos e o progresso do projeto.

Como escolher sua metodologia ágil

  1. Não hesite em revisar os processos quando encontrar um problema. Pense com agilidade: pessoas, processos e ferramentas.
  2. Avalie o projeto e as responsabilidades da equipe para encontrar os melhores métodos ágeis adequados à equipe. Consulte a página kanban versus scrum para saber mais sobre esses métodos.
  3. Se você decidir mudar para o scrum, sugiro usar um painel do Jira Scrum ou criar um template no Confluence ou em sua ferramenta favorita.

Para cada sprint, crie uma página de planejamento para revisar e refletir sobre o último sprint e se planejar para o próximo com base na capacidade e na meta da equipe. Este é meu template pessoal do Confluence:

Imagem do template de planejamento de sprint

Este é o template de planejamento de capacidade que está incluído no meu template geral de scrum:

disponibilidades do scrum

Também aqui estão os objetivos de sprint e template de escopo:

imagem da meta de sprint

Para o meio do sprint, é útil ter outra página para acompanhar o desempenho da equipe durante a última semana, quais histórias a gente precisa passar para o próximo sprint, considerando o progresso atual do sprint (chamado de preparação) e elaborar as histórias que você preparou (refinamento da história). Este é o template de refinamento e revisão de tarefas no meio do sprint:

Preparação da lista de pendências

Cada equipe é diferente, e o que funcionou para a gente pode não funcionar para outras equipes. Scrum, kanban ou uma combinação de ambos, como scrumban e kanplan, pode ser uma metodologia melhor. É essencial avaliar as necessidades específicas da equipe e entender qual metodologia funciona para ela.