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.
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 funções. 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:
Conheça mais práticas ágeis
Os recursos internos de aprendizado da Atlassian me ajudaram a aumentar minhas habilidades em práticas ágeis. Passei por cursos abrangentes de agilidade e 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 gente fez as seguintes melhorias 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.
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
- Não hesite em revisar os processos quando encontrar um problema. Pense com agilidade: pessoas, processos e ferramentas.
- 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.
- 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:
Este é o template de planejamento de capacidade que está incluído no meu template geral de scrum:
Também aqui estão os objetivos de sprint e template de escopo:
Para o meio do sprint, é útil ter outra página para acompanhar o desempenho da equipe durante a última semana, quais histórias devem passar para o próximo sprint, considerando o progresso atual do sprint (chamado de revisão) e elaborar as histórias que você revisou (refinamento da história). Este é o template de refinamento e revisão de tarefas que uso no meio do sprint:
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.
