No ágil, o que funciona é um objetivo de sprint escrito em uma frase, no máximo duas tarefas em andamento por pessoa e cerimônias que terminam com uma decisão anotada, com dono e prazo. O resto do calendário de ritos você corta até o tempo em cerimônia ficar abaixo de 10% da semana do time.
Agilidade é entregar valor de forma contínua e ajustar a rota rápido quando o cenário muda. Scrum, Kanban e Shape Up servem de base para o time conhecer o terreno e saber a hora de sair dele. Quem trata framework como bíblia perde o tempo certo da entrega, que era a única coisa que importava.
Por que tanto time faz Scrum e entrega menos do que antes?
Eu vi o mesmo ciclo se repetir em empresa atrás de empresa. A empresa contrata um Agile Coach. O time aprende o vocabulário: backlog, sprint, story points, velocity, burndown. A daily de 15 minutos vira 45. A planning de 2 horas vira 5. O refinement se multiplica em três sessões por sprint. O time passa a entregar menos do que entregava antes do “ágil”, a empresa culpa a implementação e contrata o segundo coach.
Scrum nunca foi o problema nessas empresas. O problema é que ninguém ali entendia para que o Scrum existe, então cumpriam o ritual e abandonavam o propósito.
Faça uma pergunta ao seu time: quanto vocês entregaram, em valor de negócio mensurável, no último trimestre? Se você travou para responder em uma frase, vocês fazem teatro de Scrum, com crachá e post-it colorido.
Quais cerimônias manter e como encurtar cada uma?
Fique com quatro, cada uma com uma saída clara.
Planning define o objetivo da sprint e o conjunto de itens que sustenta esse objetivo. A saída é um compromisso realista. Com backlog refinado e priorizado antes, uma hora basta.
Daily dura de 10 a 15 minutos e trata de alinhamento e impedimento. Quando o gestor usa a daily para auditar cada pessoa, a reunião morre. Pergunta de acompanhamento vai para o 1:1.
Review mostra o que foi entregue, com foco em valor. Slide caprichado não conta como entrega.
Retro responde uma pergunta só: o que vamos mudar na próxima sprint? Ela termina com uma mudança, um responsável, um prazo e um critério de sucesso. O template que eu uso é este: “Mudança X será aplicada na próxima sprint. Responsável: Y. Critério de sucesso medido em Z. Reavaliamos na próxima retro.” Se a retro sai sem isso, você fez terapia em grupo. Corte a frequência dela pela metade até ela voltar a produzir ação.
O que é Sprint Goal e por que ele separa time maduro de time decorado?
Sprint Goal é o objetivo único da sprint, escrito em uma frase, que conecta as tarefas a um resultado de negócio. Sem ele, a sprint vira lista de desejos e o time fecha cards sem saber por que estavam ali.
Compare dois exemplos. Um objetivo bom: reduzir o tempo médio do cadastro de 3 minutos para 1, com teste A/B pronto para rodar. Um objetivo ruim, que é o que quase todo time escreve: entregar os 12 cards do backlog priorizado. O primeiro deixa o time recusar trabalho que não serve ao resultado. O segundo transforma o time em fila de execução.
Junto com o Sprint Goal, use um Definition of Ready: a tarefa só entra na sprint com critério de aceite escrito, ligação com o objetivo, dependência externa identificada e tamanho que o time consegue estimar com confiança. Tarefa que não passa volta para o refinement.
Por que limitar o trabalho em andamento acelera a entrega?
Porque tarefa parada em fila é o maior desperdício do seu fluxo, e quase ninguém mede isso. A regra que eu cobro é de no máximo duas tarefas em andamento por pessoa. Acima disso, você para de produzir e passa a alternar entre contextos.
A métrica que expõe o problema chama Flow Efficiency: o tempo em que a tarefa foi trabalhada dividido pelo tempo total entre começar e concluir. Uma tarefa de 10 dias com 2 dias de implementação, 3 esperando code review, 1 esperando QA e 4 esperando merge e deploy tem 20% de eficiência. Em 80% do tempo ela ficou parada. O cycle time de 10 dias, sozinho, esconde onde está o gargalo.
Na minha leitura de campo, a maioria dos times brasileiros de produto opera entre 10% e 20%. A régua que eu uso põe 25% como piso saudável e 40% como excelente. Pegue uma sprint fechada, calcule a média e descubra qual coluna do board concentra a espera. Essa coluna é a pauta da sua próxima conversa de processo.
Scrum, Kanban ou outra coisa: como escolher?
Pelo tipo de problema, usando o modelo Cynefin, do Dave Snowden. Problema simples, que você já resolveu dez vezes, pede checklist e procedimento. Problema complicado, com solução conhecida que exige análise, combina com Scrum ou Kanban. Problema complexo, em que você só descobre se funciona testando, pede Lean Startup ou Shape Up em modo descoberta. Incêndio em produção pede comando direto e sprint na gaveta.
Se você lidera time, faça o exercício de uma hora: pegue os últimos 30 a 50 itens entregues e classifique cada um. Se 40% ou mais caíram em “complexo” e o time roda Scrum tradicional, o framework está travando o time, e a escolha foi sua. Se 30% ou mais são incêndio, o sistema está mal mantido e o assunto vai para a agenda de confiabilidade.
Dá para ser ágil em empresa regulada?
Dá, e “somos banco, não dá para ser ágil” é a desculpa mais cara que eu conheço. O Nubank, regulado pelo Banco Central, sobe código em produção cerca de uma vez por minuto, segundo relato da própria engenharia. O Monzo, banco regulado no Reino Unido, passa de 100 deploys por dia. Nenhum dos dois pede bênção de comitê para cada mudança. O controle deles mora na esteira: pipeline automatizado, teste de contrato, trilha de auditoria que nasce a cada deploy.
A pesquisa do Accelerate mediu o comitê de mudança tradicional: aprovação externa piora lead time, frequência de deploy e tempo de recuperação, e não reduz a taxa de falha. Num comitê que eu acompanhei por dentro, nenhuma mudança foi reprovada no ano inteiro. Aquilo era pedágio com carimbo.
Na fintech regulada onde sou CTO, o time monta a sprint inteira sem pedir autorização, porque os trilhos foram desenhados antes: padrão de arquitetura, esteira de desenvolvimento, design e teste. O controle vive em três portões conhecidos, que são design review, sprint review contra critério de aceite e revisão de backlog. Auditor quer trilha, e quem entrega trilha consegue ser rápido e auditável na mesma semana.
Como um time cortou cerimônia e entregou mais?
Mariana (nome trocado, caso real de mentoria, com permissão) era engineering manager numa fintech, com seis pessoas e “Scrum há 2 anos”. Passei uma sprint inteira observando. Daily de 35 minutos, porque ela perguntava como se fosse auditoria. Planning de 4 horas toda segunda, discutindo story point em horas. Refinement de 6 horas por semana. Retro mensal sem nenhuma ação. Nenhum Sprint Goal. PO ausente em 70% das cerimônias. Somando tudo, 15% do tempo do time ia para cerimônia.
Ela topou refazer em quatro semanas. A daily caiu para 10 minutos, sem perguntas dela. A planning virou uma hora. O Sprint Goal passou a ficar colado no topo do board, e em duas sprints o time começou a recusar card que não servia ao objetivo. O refinement caiu para uma sessão, a retro virou 30 minutos com uma ação obrigatória e o PO passou a ir a toda planning e review, depois que ela negociou isso com o head de produto.
Em oito semanas, o tempo em cerimônia caiu de 15% para 6%. As tarefas concluídas ligadas ao Sprint Goal subiram 35%. A Flow Efficiency foi de uma estimativa inicial de 12% para 28%. Sete meses depois, Mariana virou Head of Engineering. O time continuou no Scrum e mudou a forma de rodar.
Quando vale sair do framework?
Em incidente de produção, com comando direto e cerimônia só depois. Em time de duas ou três pessoas, em que Kanban simples e conversa direta bastam. Em pesquisa e descoberta, com revisão semanal leve. E quando o time já entrega bem sem seguir o rito ao pé da letra: deixe esse time em paz.
Comece pela semana que vem. Some as horas que cada pessoa do seu time gasta em cerimônia e conte quantas decisões úteis saíram delas na última sprint.
Onde aprofundar
O capítulo 8 de Maturidade em TI traz o mapa Cynefin completo para decisor, o protocolo de incidente em ambiente regulado, as métricas de 30 dias para quem executa e para quem lidera e a lista de quando sair do framework. O livro está na Amazon: Maturidade em TI, de Vinícius Graciano.
Baixe os 22 templates do livro e leve o template de retro para a próxima reunião do seu time.