PDCA e Scrum: semelhanças e diferenças entre os ciclos
PDCA e Scrum aparecem juntos em muitas empresas que vêm da qualidade e estão adotando o ágil. A pergunta costuma ser direta: "a Sprint não é só um PDCA com outro nome?". A resposta curta é que os dois compartilham a lógica de planejar, executar, verificar e ajustar, mas foram feitos para problemas diferentes e têm estruturas muito diferentes.
Entender a semelhança ajuda quem já domina o PDCA a aprender Scrum mais rápido. Entender a diferença evita dois erros comuns: tratar a Sprint como um plano rígido a ser cumprido e verificado no fim, ou usar o PDCA como se fosse um framework de gestão de produto.
Abaixo estão as etapas de cada ciclo lado a lado, onde eles diferem e como usar o PDCA dentro do Scrum, especialmente na Retrospectiva.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que é o PDCA, em poucas linhas
O PDCA é um ciclo de melhoria em quatro etapas: Plan (planejar), Do (fazer), Check (verificar) e Act (agir). Ele tem origem no trabalho de Walter Shewhart sobre controle estatístico de processos e foi difundido por W. Edwards Deming, que o ensinou no Japão no pós-guerra. Mais tarde, Deming passou a preferir a forma PDSA, trocando Check por Study, para deixar claro que a terceira etapa pede análise, e não só conferência.
O ciclo serve para resolver problemas e melhorar processos: definir o problema e a hipótese de solução, testar em pequena escala, medir o efeito e padronizar o que funcionou ou recomeçar. A aplicação em projetos, com etapas detalhadas, está no artigo sobre ciclo PDCA em gestão de projetos.
O que é o Scrum, em poucas linhas
O Scrum é um framework para gerar valor em problemas complexos, definido no Guia do Scrum. Ele se apoia no empirismo e em três pilares: transparência, inspeção e adaptação. O trabalho acontece em Sprints de até um mês, com papéis (Product Owner, Scrum Master e Developers), cinco eventos e três artefatos com seus compromissos. O panorama completo está no guia de métodos ágeis e Scrum.
PDCA e Scrum lado a lado: onde cada etapa aparece
| Etapa do PDCA | Onde aparece no Scrum | O que acontece |
|---|---|---|
| Plan | Sprint Planning | O Scrum Team define a Meta da Sprint, seleciona itens do Product Backlog e os Developers planejam o trabalho |
| Do | A Sprint em andamento | Os Developers constroem o Incremento seguindo a Definição de Pronto |
| Check | Daily Scrum, Sprint Review e Sprint Retrospective | Inspeção diária do progresso, inspeção do resultado com as partes interessadas e inspeção da forma de trabalhar |
| Act | Ajustes no Sprint Backlog, no Product Backlog e no processo | O time adapta o plano da Sprint, o Product Owner reordena o backlog e as melhorias da Retrospectiva entram em prática |
A correspondência mostra uma coisa interessante: no Scrum, o Check e o Act não acontecem só no fim. A Daily Scrum é um ciclo curto de verificação e ajuste todos os dias; a Sprint Review verifica o produto; a Retrospectiva verifica o processo. São ciclos dentro de ciclos, todos movidos pela mesma lógica empírica, explicada em empirismo e pilares do Scrum.
As diferenças que importam
| Critério | PDCA | Scrum |
|---|---|---|
| Natureza | Método genérico de melhoria e solução de problemas | Framework para desenvolver produtos em ambiente complexo |
| Objeto típico | Um processo ou um problema específico | Um produto e o seu Incremento |
| Cadência | Livre, cada ciclo dura o necessário | Sprints de duração fixa, de até um mês |
| Papéis | Não define | Product Owner, Scrum Master e Developers, com responsabilidades claras |
| Artefatos | Não define (as equipes costumam usar plano de ação e indicadores) | Product Backlog, Sprint Backlog e Incremento, com Meta do Produto, Meta da Sprint e Definição de Pronto |
| Timebox dos eventos | Não tem | Cada evento tem duração máxima |
| Entrega a cada ciclo | Um processo melhorado ou uma hipótese testada | Um Incremento utilizável |
| Ponto de partida | Problema ou meta de melhoria | Meta do Produto e backlog ordenado |
Duas diferenças merecem atenção:
O Plan do Scrum é deliberadamente curto e parcial. No PDCA, um bom plano costuma ser detalhado antes da execução. No Scrum, os Developers detalham o suficiente para começar, e o plano da Sprint muda conforme o time aprende. O que fica fixo é a Meta da Sprint, não a lista de tarefas.
O Scrum entrega produto a cada ciclo. Um ciclo PDCA pode terminar só com aprendizado ("a hipótese não se confirmou"). Uma Sprint termina com pelo menos um Incremento que atende à Definição de Pronto, além do aprendizado.
Como usar o PDCA dentro do Scrum
O lugar onde o PDCA mais ajuda é a Sprint Retrospective. O Guia do Scrum diz que as melhorias de maior impacto devem ser tratadas o quanto antes e podem até ser incluídas no Sprint Backlog da Sprint seguinte. O problema é que muitas retrospectivas geram listas de boas intenções que ninguém acompanha. Tratar cada melhoria como um pequeno ciclo PDCA resolve isso:
- Plan. Na Retrospectiva, escolha uma melhoria e escreva a hipótese: "se fizermos X, esperamos ver Y". Defina como vai medir e quem acompanha.
- Do. Coloque a ação no Sprint Backlog da próxima Sprint, para que ela tenha espaço real na capacidade do time.
- Check. Na Retrospectiva seguinte, olhe o indicador combinado. A mudança aconteceu? O efeito apareceu?
- Act. Se funcionou, vira padrão (por exemplo, entra na Definição de Pronto ou no acordo do time). Se não funcionou, descarte ou ajuste a hipótese.
Para a ação ficar concreta no passo Plan, um 5W2H curto (o quê, por quê, onde, quando, quem, como e quanto custa) ajuda. As técnicas para conduzir a própria reunião estão em dinâmicas de retrospectiva.
Exemplo ilustrativo: um defeito recorrente na implantação de um ERP
Um time Scrum está implantando um ERP numa distribuidora e trabalha em Sprints de duas semanas. Em três Sprints seguidas, a Sprint Review mostrou integrações com o sistema fiscal que falhavam em homologação por erro de cadastro de produtos. O exemplo é ilustrativo.
- Plan: na Retrospectiva, o time levanta a hipótese de que os cadastros chegam incompletos da área de compras. A ação proposta é um checklist de validação aplicado antes de cada carga, com a meta de zerar as falhas por cadastro na próxima Sprint. O indicador é o número de falhas por cadastro em homologação.
- Do: o checklist entra no Sprint Backlog como item próprio, com uma pessoa de compras convidada para validar o primeiro uso.
- Check: na Retrospectiva seguinte, as falhas por cadastro caíram, mas ainda apareceram em produtos importados, que o checklist não cobria.
- Act: o checklist é ampliado para importados e passa a fazer parte da Definição de Pronto das histórias de integração. Um novo ciclo começa para os importados.
O problema foi tratado sem sair do Scrum: a inspeção veio da Review, a decisão da Retrospectiva e a ação do Sprint Backlog.
Quando cada um é a ferramenta certa
- Use o Scrum para organizar o desenvolvimento de um produto ou entregável em que o caminho não está claro no início e o feedback frequente muda as prioridades.
- Use o PDCA para atacar um problema específico de processo, dentro ou fora de um time ágil: um defeito recorrente, um retrabalho, um gargalo.
- Use os dois juntos quando o time Scrum precisa transformar o aprendizado da Retrospectiva em mudança mensurável.
Para ver como a Sprint organiza esse ciclo no tempo, com regras de duração e cancelamento, leia o que é Sprint no Scrum.
O que fazer na próxima Retrospectiva
Escolha uma única melhoria, escreva a hipótese e o indicador, coloque a ação no Sprint Backlog e marque a verificação para a Retrospectiva seguinte. Para detalhar a ação sem esquecer responsável, prazo e custo, use a ferramenta gratuita de 5W2H da Projeto Diário, que gera o plano de ação pronto para levar ao quadro do time.
