Quando uma pequena equipe decide trabalhar de forma mais ágil, uma das primeiras perguntas costuma ser: devemos usar Scrum, Kanban ou XP?

A pergunta parece razoável, mas talvez esteja começando pelo lugar errado. Em vez de escolher primeiro um framework e adaptar todos os problemas da equipe a ele, vale identificar onde a entrega está sofrendo e selecionar práticas que resolvam esses problemas.

Essa visão ganhou um reforço importante em 2026. Em julho, o Project Management Institute publicou a segunda edição do Agile Practice Guide, desenvolvido em colaboração com a Agile Alliance. A atualização continua deliberadamente neutra em relação a frameworks e amplia a atenção para fluxo, resultados, valor, gestão de produto, DORA, DevOps, IA e equipes distribuídas.

Fonte: Agile Practice Guide — Second Edition, PMI, julho de 2026.

Agilidade não é uma coleção de cerimônias

Scrum popularizou uma estrutura fácil de reconhecer: ciclos curtos, backlog, planejamento, revisão e retrospectiva. Para muitas equipes, essa cadência cria um ritmo útil para decidir prioridades e inspecionar resultados.

Mas cumprir todas as cerimônias não garante que o trabalho flua. Uma equipe pode terminar cada sprint com todas as reuniões realizadas e ainda acumular Pull Requests esperando review, tarefas bloqueadas, histórias grandes demais e releases que demoram semanas para chegar aos usuários.

Por isso, a edição de 2026 do guia do PMI expande explicitamente a discussão sobre métricas de fluxo e resultados, em vez de se limitar a contagens de entregáveis. O foco passa de "quanto trabalho fizemos?" para perguntas mais úteis: quanto tempo uma mudança leva para atravessar o sistema, onde ela espera e que valor produziu?

O que cada abordagem pode ensinar

Scrum ajuda a criar cadência. Seus ciclos e eventos fornecem momentos claros para priorizar, revisar o que foi entregue e adaptar o plano. Isso pode ser especialmente útil quando produto e engenharia precisam criar um hábito de decisão frequente.

Kanban ajuda a enxergar e melhorar o fluxo. O Kanban Guide, atualizado em maio de 2025, mantém como elementos centrais a definição explícita do fluxo de trabalho, o controle do trabalho em andamento e o acompanhamento de métricas de fluxo. Para uma equipe com muitas tarefas simultâneas e longas filas de espera, limitar WIP pode ser mais transformador do que adicionar uma nova reunião.

Fonte: The Kanban Guide — edição de maio de 2025.

Extreme Programming (XP) lembra que agilidade também é engenharia. Feedback rápido perde valor se cada mudança for cara e arriscada. Testes automatizados, integração contínua, refatoração e pequenas entregas ajudam a manter o software modificável. Uma equipe pode organizar perfeitamente seu backlog e ainda perder velocidade se a base técnica tornar cada release uma operação delicada.

Essas ideias não precisam competir. Cadência, fluxo e excelência técnica tratam de dimensões diferentes do mesmo sistema de entrega.

Uma pequena equipe pode combinar práticas

Imagine um time com cinco pessoas desenvolvendo um produto digital. O grupo usa ciclos quinzenais para revisar objetivos e prioridades, mas não precisa esperar o fim da sprint para colocar uma melhoria pronta em produção.

O quadro torna o fluxo explícito e limita quantos itens podem estar simultaneamente em desenvolvimento e review. Mudanças pequenas seguem integração contínua, testes automatizados e deploy frequente. Na retrospectiva, a equipe não discute apenas se "completou o sprint": observa onde o trabalho ficou parado e decide um experimento para melhorar o sistema.

Isso pode conter elementos de Scrum, Kanban, XP e Lean sem exigir que a equipe invente um novo nome para seu processo.

Meça o sistema, não a ocupação das pessoas

Outra mudança relevante está nas métricas. Em abril de 2026, o DORA atualizou seu Quick Check para trabalhar com cinco métricas de performance de entrega, incluindo a nova deployment rework rate, além de apresentar visões de throughput e estabilidade.

Fonte: DORA Quick Check updates — 22 de abril de 2026.

Para uma equipe pequena, não é necessário começar com dezenas de indicadores. Quatro perguntas já criam uma conversa melhor:

• Quanto tempo normalmente passa entre começar e terminar uma mudança?
• Quantos itens ficam em andamento ao mesmo tempo?
• Onde o trabalho passa mais tempo esperando?
• Com que frequência uma entrega exige correção ou retrabalho?

Essas respostas ajudam a distinguir uma equipe realmente rápida de uma equipe apenas muito ocupada.

Um caminho simples para começar

Para pequenas equipes, uma transformação completa raramente é necessária. Um caminho mais seguro é começar pelo problema mais visível.

1. Visualize o fluxo real, incluindo review, testes, homologação e deploy — não apenas "a fazer, fazendo e feito".
2. Reduza trabalho simultâneo antes de tentar aumentar a velocidade individual.
3. Quebre entregas em partes menores para reduzir tempo de feedback e risco.
4. Automatize a segurança da mudança com testes, CI e práticas de engenharia adequadas ao produto.
5. Escolha poucas métricas de fluxo, estabilidade e resultado e acompanhe sua evolução.
6. Use retrospectivas para experimentar, alterando uma política ou prática por vez e observando o efeito.

A pergunta deixa de ser "qual framework estamos seguindo corretamente?" e passa a ser "qual é o principal impedimento para entregar valor hoje e qual prática pode nos ajudar a melhorá-lo?"

Agilidade como capacidade, não como identidade

Scrum, Kanban e XP continuam oferecendo ideias valiosas. O que está amadurecendo é a forma de usá-las. A atualização do PMI em 2026 reflete um mercado no qual produto, engenharia, fluxo, métricas e automação estão cada vez mais conectados.

Para pequenas equipes, isso é uma vantagem. Há menos necessidade de reproduzir estruturas criadas para organizações muito maiores. É possível construir um sistema de trabalho leve, explícito e mensurável, preservando aquilo que cada abordagem tem de melhor.

Na Agileeze, esse é o tipo de problema que tratamos em consultoria de software e engenharia: entender o fluxo atual, encontrar gargalos e evoluir práticas técnicas e de produto sem adicionar processo apenas por adicionar. O objetivo não é "instalar agilidade", mas criar uma equipe capaz de aprender e entregar com segurança.

Seu processo deve servir ao produto e à equipe — não o contrário.