Empirismo no Scrum: transparência, inspeção e adaptação
No Scrum, empirismo quer dizer tomar decisões com base no que foi observado, e não no que foi previsto. Parece óbvio, mas contraria o hábito de muitos projetos: fazer um plano detalhado no início, aprovar e depois medir quanto a realidade se desviou dele. No modelo empírico, o plano é uma hipótese, e cada ciclo curto de trabalho serve para testá-la.
O Guia do Scrum 2020 diz que o framework se fundamenta no empirismo e no pensamento enxuto (lean thinking). O empirismo afirma que o conhecimento vem da experiência; o pensamento enxuto reduz o desperdício e concentra o esforço no essencial. Daí vem a abordagem iterativa e incremental do Scrum, usada para melhorar a previsibilidade e controlar o risco.
Para que o empirismo funcione, o Guia aponta três pilares: transparência, inspeção e adaptação. Os três parecem simples. O difícil é perceber quando um deles falta, porque o time continua realizando todos os eventos e mesmo assim deixa de aprender.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que é empirismo e por que o Scrum depende dele
Existem dois jeitos de controlar um trabalho. No primeiro, o processo é conhecido e repetível: se você seguir os passos, o resultado sai igual. Montar um móvel com manual é assim. No segundo, o processo tem variáveis demais para prever: você precisa observar com frequência e corrigir no caminho. Desenvolver um produto que ninguém fez antes é assim.
O Scrum foi desenhado para o segundo tipo, que o Guia chama de problemas complexos (a definição completa do framework está no artigo sobre o que é Scrum). Neles, o planejamento detalhado no início não elimina a incerteza, só a esconde. O empirismo troca a pergunta "estamos seguindo o plano?" por "o que aprendemos e o que isso muda?".
Isso não significa ausência de planejamento. O Scrum planeja o tempo todo: a Meta do Produto dá a direção, a Sprint Planning define a próxima etapa, a Daily ajusta o plano do dia. A diferença é que cada plano é curto e revisado com dados reais. Para ver como esses elementos se encaixam no framework como um todo, o guia completo de métodos ágeis e Scrum traz o panorama.
Transparência: tornar o trabalho visível para quem decide
O Guia define transparência assim: o processo e o trabalho que está surgindo precisam estar visíveis para quem faz o trabalho e para quem o recebe. As decisões importantes se baseiam no estado dos três artefatos, e artefatos pouco transparentes levam a decisões que diminuem o valor e aumentam o risco.
Na prática, transparência é mais que deixar o quadro aberto para todos. É garantir que o que está no quadro corresponde à realidade:
- Product Backlog transparente: qualquer parte interessada consegue ver o que vem a seguir e por quê. Um backlog com itens que ninguém entende, ou com prioridades decididas fora dele, não é transparente.
- Sprint Backlog transparente: mostra o trabalho real da Sprint, incluindo o que travou. Um item "em andamento" há oito dias sem explicação esconde um problema.
- Incremento transparente: atende à Definição de Pronto. Um "pronto" que ainda precisa de testes fora da Sprint engana quem toma decisões com base nele.
Cada artefato tem um compromisso que reforça a transparência (Meta do Produto, Meta da Sprint e Definição de Pronto), detalhado no artigo sobre artefatos do Scrum.
Inspeção: examinar com frequência para detectar desvios
O Guia pede que os artefatos e o progresso rumo às metas sejam inspecionados com frequência e atenção, para detectar variações ou problemas indesejáveis. Os cinco eventos existem para dar ritmo a essa inspeção.
Dois cuidados tornam a inspeção útil:
- Inspecionar o que importa. A Daily inspeciona o progresso rumo à Meta da Sprint, não a ocupação de cada pessoa. A Review inspeciona o Incremento com quem vai usá-lo, não uma apresentação de slides sobre ele.
- Inspecionar na frequência certa. Rara demais, e o desvio cresce antes de ser visto. Frequente demais, e a inspeção atrapalha o trabalho. O Scrum resolve isso com timeboxes: cada evento tem duração máxima e momento definido.
O Guia também é direto sobre a relação com o pilar anterior: a transparência possibilita a inspeção, e inspecionar sem transparência leva a conclusões enganosas e a desperdício.
Adaptação: corrigir o rumo o quanto antes
Se algum aspecto do processo ou do produto sai dos limites aceitáveis, o ajuste deve ser feito o quanto antes, para minimizar novos desvios. Pelo Guia, a inspeção sem adaptação é inútil: examinar e não mudar nada só consome tempo.
O Guia acrescenta uma condição que costuma ser ignorada: a adaptação fica mais difícil quando as pessoas envolvidas não têm autonomia nem se autogerenciam. Um time que descobre na Review que uma funcionalidade não serve, mas precisa de três aprovações para tirá-la do backlog, não está sendo empírico. Está registrando problemas.
Adaptar pode significar mudar o produto (reordenar o backlog, abandonar uma ideia), o plano (trocar o item que entra na Sprint) ou o processo (mudar a Definição de Pronto, o horário da Daily, a forma de testar).
Como os três pilares aparecem em cada evento
| Evento | O que se inspeciona | O que se adapta |
|---|---|---|
| Sprint | O progresso rumo à Meta do Produto, a cada ciclo | A direção do produto, Sprint a Sprint |
| Sprint Planning | O Product Backlog, o último Incremento e a capacidade do time | A Meta da Sprint e o Sprint Backlog |
| Daily Scrum | O progresso rumo à Meta da Sprint | O plano do próximo dia de trabalho |
| Sprint Review | O Incremento e as mudanças no ambiente | O Product Backlog |
| Sprint Retrospective | Pessoas, interações, processos, ferramentas e Definição de Pronto | A forma de trabalhar na próxima Sprint |
Em todos os casos, a inspeção só vale se o que está sendo examinado é transparente, e só gera valor se termina em adaptação. A descrição de cada evento, com entradas e saídas, está no artigo sobre eventos do Scrum.
Os valores que sustentam os pilares
Os pilares descrevem o mecanismo; os valores descrevem o comportamento que o torna possível. O Guia lista cinco: compromisso, foco, abertura, respeito e coragem. Quando as pessoas vivem esses valores, os pilares ganham vida e se constrói confiança.
A ligação é concreta. Transparência exige abertura: mostrar o item atrasado em vez de maquiar o quadro. Adaptação exige coragem: dizer na Review que a funcionalidade entregue não resolveu o problema. Inspeção exige respeito: discutir o trabalho sem transformar a conversa em busca de culpados. Sem esses comportamentos, os eventos acontecem e o time não aprende nada com eles.
Exemplo ilustrativo de um ciclo empírico fora de TI
O cenário é ilustrativo. A área de RH de uma rede varejista usa Scrum para criar um programa de integração de novos funcionários das lojas. A Meta do Produto é reduzir a saída de contratados nos primeiros três meses.
- Transparência: o backlog fica num quadro que gerentes de loja podem consultar. Cada item descreve o problema que resolve, por exemplo "o novo vendedor não sabe operar o caixa no primeiro dia".
- Inspeção: na Sprint Review, o time apresenta o roteiro do primeiro dia, testado em duas lojas, e ouve os gerentes. Os dados mostram que os novatos gostaram do roteiro, mas que as saídas acontecem mais na terceira semana, quando terminam o acompanhamento.
- Adaptação: o Product Owner reordena o backlog e sobe o item de acompanhamento nas semanas três e quatro. Na retrospectiva, o time decide incluir um gerente de loja em todas as Reviews, porque as melhores informações vieram deles.
Num plano tradicional, o programa teria sido desenhado inteiro antes do teste, e o problema da terceira semana apareceria só depois do lançamento em toda a rede.
Sinais de que o time não está sendo empírico
- O quadro mostra uma realidade diferente da que o time comenta no café.
- A Review é uma apresentação, sem conversa e sem mudança no backlog depois dela.
- As retrospectivas repetem os mesmos problemas sem nenhuma ação concluída.
- O "pronto" de uma Sprint volta como defeito na seguinte.
- Mudanças de rumo precisam de aprovações que levam mais tempo do que a própria Sprint.
- O plano da Sprint nunca muda, mesmo quando algo inesperado acontece.
Cada sinal aponta para um pilar fraco. Os dois primeiros, para transparência. Os dois do meio, para inspeção sem adaptação. Os dois últimos, para falta de autonomia, que o Guia cita como obstáculo direto à adaptação.
Como levar o empirismo para o seu time
Na próxima retrospectiva, use os três pilares como roteiro: o que não está visível para quem decide, o que inspecionamos e não mudou nada, e que decisão não conseguimos tomar por falta de autonomia. Escolha uma ação para cada pergunta. Para conferir o texto original, o resumo do Scrum Guide em português percorre a teoria do Scrum e os demais capítulos. E se quiser estudar o framework completo, com os pilares aplicados a papéis, eventos e artefatos, o curso Agile Scrum Foundation da Projeto Diário oferece as aulas em vídeo, no seu ritmo, e prepara para o exame ASF.
