Agile virou sinônimo de Scrum para muita gente. Standup diário, sprint de duas semanas, planning, retrospectiva — isso é Scrum, não Agile. Agile é um conjunto de valores e princípios que descrevem uma forma de pensar sobre como construir software. Scrum é um dos frameworks que tenta operacionalizar esses princípios.

Um PM que entende Agile pelos princípios — não só pelos rituais — consegue trabalhar bem em qualquer contexto, seja Scrum, Kanban, Shape Up ou qualquer variação híbrida.

O Manifesto Ágil em linguagem de produto

O Manifesto Ágil de 2001 tem quatro valores centrais. Traduzindo para o dia a dia de PM:

Indivíduos e interações acima de processos e ferramentas significa que nenhum processo substitui a clareza de comunicação direta. A planning de sprint não substitui uma conversa de cinco minutos para alinhar a prioridade mais importante da semana.

Software funcionando acima de documentação abrangente significa que um protótipo testado com um usuário é mais valioso do que um PRD de 30 páginas que ninguém vai ler por inteiro. Documentação tem valor — mas como suporte à comunicação, não como substituta dela.

Colaboração com o cliente acima de negociação de contratos significa que o usuário não é um requisito a ser capturado no início do projeto. É uma fonte contínua de aprendizado ao longo de todo o desenvolvimento.

Responder a mudanças acima de seguir um plano significa que o roadmap é um plano baseado no que você sabe hoje — e que mudar de direção quando você aprende algo novo não é falha, é o comportamento esperado.

O que Agile implica para o trabalho do PM

Agile implica que o PM nunca termina o trabalho de descoberta. Não existe "fase de discovery" seguida de "fase de delivery" — discovery é contínuo, porque o contexto sempre muda e o aprendizado nunca para. Para entender como equilibrar as duas atividades, veja o artigo sobre discovery e delivery em produto.

Implica também que o backlog não é uma lista de compromissos — é uma lista de hipóteses ordenadas por valor esperado. Itens que estão no fundo do backlog podem sumir sem problema se o contexto mudar. O PM que trata o backlog como compromisso vai defender features desatualizadas por meses só porque alguém as pediu.

Scrum: o que o PM precisa entender

No Scrum, o PM frequentemente assume o papel de Product Owner (PO) — responsável pelo backlog e pela priorização. É importante distinguir: Product Owner é um papel dentro do Scrum. Product Manager é uma função que pode ou não exercer esse papel, dependendo da organização.

Os rituais do Scrum — planning, daily, review, retro — existem para criar ritmo e visibilidade. Planning define o que o time vai fazer. Daily identifica impedimentos. Review valida o que foi construído com stakeholders. Retro melhora o processo do time. Um PM que entende o propósito de cada ritual vai muito além de seguir o protocolo.

Kanban como alternativa

Kanban é um sistema de gestão de fluxo de trabalho baseado em limitar o trabalho em progresso. Não tem sprints, não tem papéis fixos, não tem rituais obrigatórios. O princípio é: visualize o trabalho, limite o WIP (work in progress), melhore o fluxo.

Times de produto que fazem manutenção contínua, suporte e desenvolvimento em paralelo frequentemente se beneficiam mais do Kanban do que do Scrum. O Scrum funciona melhor quando o trabalho pode ser planejado em ciclos — o que nem sempre é o caso.

O que o PM deve questionar em qualquer framework

Independente do framework, o PM deve questionar rituais que existem por hábito sem entrega de valor real. Uma daily de 30 minutos onde as pessoas leem status não é Agile — é burocracia em pé. Uma sprint review onde o time apresenta para si mesmo sem stakeholders não está cumprindo o propósito. O PM que entende o porquê de cada ritual consegue adaptá-lo ao contexto — ou propor que seja descontinuado se não servir mais.