Baseado no Scrum Guide original de Ken Schwaber & Jeff Sutherland (40)

Recursos Coletados para o Pacote de Expansão (Expansion Pack) do Guia do Scrum
Este documento é uma coletânea de trabalhos independentes. Cada seção mantém sua licença ou status de direitos autorais original, conforme indicado. Consulte cada seção para conhecer os direitos e requisitos de uso específicos..

[Seção 1: Pacote de Expansão do Guia do Scrum 1 (Adaptação)
Título: Pacote de Expansão do Guia do Scrum Adaptação do: Guia do Scrum original
Autor: Ralph Jocham, John Coleman e Jeff Sutherland.
Fonte: Guia do Scrum 2020 , Pacote de Expansão do Guia do Scrum
Licença: Creative Commons Attribution-ShareAlike 4.0 International ( CC BY-SA 4.0 ).
© 2025 Ralph Jocham, John Coleman e Jeff Sutherland.
Aviso de Modificação: Esta é uma adaptação do Guia do Scrum 2020 original. Alterações foram feitas em relação ao original.
Isenção de responsabilidade: Nenhuma garantia é fornecida. Use por sua conta e risco.
Esta seção é oferecida sob a licença Attribution-ShareAlike 4.0 International da Creative Commons.
Ao usar este Pacote de Expansão do Guia do Scrum, você concorda com os termos da licença CC BY-SA 4.0 .]

Contexto

Ken Schwaber e Jeff Sutherland lideraram o desenvolvimento do framework Scrum. O Guia do Scrum 2020 (40) descreve os fundamentos essenciais do Scrum. A Simple Guide to Scrum (58), de Tobias Mayer, é uma versão abreviada e editada do Guia do Scrum oficial de Ken Schwaber e Jeff Sutherland. O Scrum Hexis (52) aprofunda o Guia do Scrum 2020 (40) sob a perspectiva de 2025. Para adoção em larga escala, o Guia do Scrum (40) precisava ser simples.

Propósito do Pacote de Expansão do Guia do Scrum

Para uma adoção ainda mais bem-sucedida, este Pacote de Expansão oferece orientações adicionais para os tempos atuais, fundamentado no Guia do Scrum 2020 de Ken Schwaber e Jeff Sutherland (40). A contribuição de Ralph Jocham (89) ao Guia do Scrum 2020 adicionou profundidade ao trazer as ideias originais do guia para esta expansão.

Este Pacote de Expansão explica o que e o porquê de cada elemento do Scrum com uma perspectiva voltada ao futuro. Cada elemento tem um propósito específico e contribui para o valor e os resultados obtidos com o Scrum. Este material evoluirá regularmente. Recomenda-se que o leitor percorra o documento sequencialmente, pelo menos na primeira leitura.

Este documento assume alguma familiaridade com o Scrum e seu vocabulário. Pode ser útil ler primeiro o Guia do Scrum 2020 antes de prosseguir. As referências são incluídas para fins de atribuição. Apêndices e referências oferecem ao leitor a chance de explorar, pesquisar e aprender para obter compreensão mais ampla e profunda.

Praticantes e stakeholders devem adotar o Scrum quando apropriado, com protagonismo, senso de urgência, coragem, transparência, inspeção, adaptação, ritmo e resiliência, e melhorar continuamente para apoiar as Metas do Produto e da organização. Espera-se que as adoções de Scrum vão além das orientações aqui apresentadas — abrangendo teoria, papéis, artefatos, eventos, escalabilidade e todas as demais facetas tratadas neste documento — e, assim, inspirem curiosidade duradoura para explorar, questionar e melhorar continuamente.

Este Pacote foi concebido para apoiar todos os aspectos da entrega de produtos por uma equipe autogerenciada (49) impulsionada pelas necessidades ou desejos de stakeholders em resposta a um problema ou oportunidade. Isso inclui (mas não se limita a) descoberta, desenvolvimento, entrega e realização de valor. Embora tenha raízes no desenvolvimento de software, o Scrum foi amplamente adotado em vários domínios, permitindo a entrega de valor por meio de trabalho complexo (30-35). À medida que seu uso se expande, profissionais como engenheiros, programadores, pesquisadores, analistas, advogados, profissionais de marketing e cientistas aplicam Scrum com sucesso em suas áreas.

Valor para os stakeholders refere-se a qualquer necessidade percebida que um stakeholder (incluindo, mas não limitado a, clientes, tomadores de decisão e usuários) considere importante e que uma equipe entregue. Entretanto, stakeholders nem sempre sabem o que pode ser valioso para eles. Observação ou evidências podem revelar valor — intencionalmente ou não — e influenciar prioridades. À medida que surgem novas informações, itens potencialmente valiosos devem ser identificados, inspecionados, refinados e adaptados. O valor permanece uma hipótese até ser confirmado por evidência, como observação ou resultados mensuráveis.

Scrum em Poucas Palavras

Scrum é um framework para entrega de Produtos complexos (30-35), em que especialização é valiosa, mas não suficiente, e causa e efeito só ficam claros retrospectivamente. O Scrum abrange todo o ciclo de vida do Produto, que inclui (mas não se limita a) criar, substituir, sustentar, adaptar, mudar continuamente, manter e aposentar Produtos ou funcionalidades. O Scrum ajuda indivíduos, equipes e organizações a manterem-se flexíveis e a criar valor ao se adaptarem às mudanças.

O Scrum promove um ambiente para compreender e responder de forma coerente às necessidades dos Stakeholders. Sua abordagem iterativa e incremental reduz riscos e estimula a melhoria contínua. O Scrum ajuda a equipe a equilibrar exploração de problemas, descoberta de necessidades de Stakeholders (incluindo clientes porém não somente limitado a eles), Entrega de soluções, gestão proativa de riscos e validação de valor.

Risco é qualquer fator que possa resultar em consequência adversa futura. Como a exposição ao risco permanece imprevisível com o tempo, a antecipação é fundamental. A exposição ao risco pode incluir (mas não se limita a) risco de mercado, adequação problema-solução, fit Produto-mercado, tecnologia, detecção de sinais, capacidade de resposta, compliance, remediação, decisões de trade-off ruins etc. O Scrum apoia a gestão proativa de riscos e a descoberta de oportunidades.

O Scrum incentiva a redução da separação existente entre os Stakeholders que apresentam problemas ou oportunidades e as pessoas que os resolvem.

Em resumo, o Scrum baseia-se em um ambiente onde:

1. Apoiadores (Supporters) fazem o que é solicitado para apoiar proativamente e aprimorar a adoção do Scrum, guiados e apoiados pelo Scrum Master.
2. O Product Owner define a Meta do Produto, fundamental para atender ao valor esperado pelos Stakeholders.
3. O Scrum Team autogerenciado (49) define, refina e converte o trabalho selecionado em resultados valiosos.
4. O Scrum Team e os Stakeholders inspecionam os resultados durante o Sprint e se adaptam.
5. Os Apoiadores ajudam o Scrum Team a prosperar.
6. Repete.

Entrega (Release) é o processo de disponibilizar uma versão nova ou atualizada de um Produto para os Stakeholders (incluindo clientes, tomadores de decisão e usuários finais). Ele marca um ponto de inflexão no ciclo de desenvolvimento e representa a transição do Produto do desenvolvimento para a disponibilidade de uso e a possível realização de valor para os Stakeholders.

O Scrum é intencionalmente incompleto. Em vez de prescrever processos detalhados, ele fornece um framework que orienta relacionamentos e interações com propósito. Diversos processos, técnicas e métodos podem complementar o Scrum, mas sua aplicação depende do contexto e varia conforme o uso.

O Scrum integra-se a práticas existentes ou, em alguns casos, torna-as desnecessárias ou obsoletas. Ao avaliar transparentemente a eficácia do Scrum Team, dos Apoiadores, da gestão atual, do ambiente de trabalho e das técnicas, o Scrum possibilita melhoria contínua.

No contexto do trabalho do conhecimento, o termo Scrum, emprestado do jogo de rugby, foi cunhado por Takeuchi e Nonaka (29) para descrever equipes que trabalhavam dessa forma e nas quais o conhecimento se espalhava rapidamente por toda a organização para entregar Produtos excepcionais.

Complemento e Suporte Teórico

O Scrum fundamenta-se em um Scrum Team autogerenciado (49), propriedades emergentes, empirismo (67) e Pensamento Enxuto (63). Ele se apoia na teoria de suporte e em ideias complementares como:

• Accountability (responsável por garantir o resultado de trabalhos realizados),
• Redução de desperdício que não agrega valor (incluindo ineficiências organizacionais),
• Enquadrar o trabalho como problemas ou oportunidades,
• Descoberta, Entrega, ou realização de valor, e
• Melhoria contínua.

Complexidade – A Justificativa para o Scrum

Para trabalhos complexos, como criar Produtos, há mais incógnitas que certezas; apenas expertise é valiosa, mas insuficiente, e causa e efeito só ficam claros em retrospecto. Complexity thinking (30-35) oferece ferramentas e ideias úteis e facilita insights. Os membros do Scrum Team precisam de tempo para pensar, ajudar uns aos outros, refazer ou mudar de rumo. Diversidade cognitiva e empirismo auxiliam a lidar com o trabalho complexo.

Tudo que se acredita “conhecer” — inclusive mercado e Stakeholders (clientes ou não) — pode estar errado. Expectativas, necessidades ou desejos podem surgir ou perder relevância ou urgência ao longo do tempo. Uma abordagem empírica oferece mecanismos para testar premissas, inspecionar e adaptar.

Em geral, nada permanece no mesmo estado para sempre. O Scrum Team pode atuar na “beira do caos”, pesquisando e trabalhando em algo sem precedentes. Depois de um tempo, ao descobrir padrões e heurísticas, o trabalho fica menos caótico e mais complexo; mais adiante, para a situação em questão, o time pode se aproximar do espaço ordenado — algo não fácil, mas planejável. Ou o caminho pode ser inverso. É boa prática o Scrum Team pausar e refletir se realmente está no domínio que imagina. O ponto-chave é que o desenvolvimento de Produtos lida com imprevisibilidade, e o Scrum costuma ser mais útil que abordagens com ilusão de previsibilidade.

As oportunidades oriundas da emergência — via Transparência, Inspeção e Adaptação do quem, por quê, o quê, quem, onde, quando — são abundantes. É importante atenuar o que não funciona e amplificar o que funciona. Transparência, Inspeção e Adaptação rumo a metas definidas, guiadas por feedback de resultados (e consequências não intencionais), geram criação de valor, insights, riscos e questionamento de premissas, fomentando a melhoria contínua.

Construa confiança por meio de uma equipe autogerenciada, Inspeção, Adaptação, Entrega de trabalho valioso e descoberta de novos insights.

Propriedades Emergentes

Propriedades Emergentes (71) ocorrem quando padrões ou comportamentos significativos surgem das interações dentro de sistemas complexos (30-35) — padrões impossíveis de prever apenas observando as partes isoladamente. No Scrum, as Propriedades Emergentes não são rigidamente controladas; elas são guiadas por restrições capacitadoras, como time-boxes, papéis e ciclos de feedback, que criam condições para autogestão e adaptabilidade sem definir resultados exatos. Essas estruturas funcionam como “ilhas” em um mar de imprevisibilidade, de modo semelhante aos padrões organizados que surgem espontaneamente em sistemas físicos em meio ao acaso, conforme descrito por Stephen Wolfram (38). O ponto-chave é que a estrutura do Scrum oferece orientação suficiente para que as equipes se autogerenciem e permitam que novas soluções apresentem Propriedades Emergentes, em vez de prescrever cada detalhe.

Scrum Teams, funcionando como sistemas adaptativos complexos, são influenciadas — não comandadas — por meio de experimentos curtos, paralelos e safe-to-fail, além de feedback contínuo. Padrões (53) como Swarming, Stable Teams e Kaizen ajudam a identificar e moldar comportamentos com Propriedades Emergentes. Em vez de forçar resultados, o Scrum permite que o Scrum Team descubra padrões desejáveis — incluindo soluções inovadoras ou novas formas de trabalho — e os amplifique, atenuando os indesejáveis.

Essa abordagem reconhece que a autogestão (49) não é criada de cima para baixo, mas descoberta no ambiente adequado — um ambiente intencional, coerente e “vivo”, em eco ao conceito de “Qualidade Sem Nome” de Christopher Alexander (39).

Em última análise, o Scrum trata as Propriedades Emergentes não como um risco a ser eliminado, mas como uma força a ser cultivada para excelência no desenvolvimento de Produtos.

Scrum Team Autogerenciado

Um Scrum Team autogerenciado (49) verifica se está no caminho certo, age quando não está, decide como trabalhar, resolve conflitos internos e corrige problemas dentro da própria equipe. Isso significa que, em geral, gerentes (111), se existirem, não dizem ao Scrum Team o que fazer nem escolhem qual membro deve ser afastado para resolver questões, direta ou indiretamente. Caso haja gerentes, é preferível que demonstrem liderança.

Scrum Teams autogerenciados em função de valor são cruciais para resolver problemas criativamente e captar Propriedades Emergentes; depender de equipes não autogerenciadas prejudica a capacidade de lidar com complexidade (30-35). Scrum Teams autogerenciados (49) não se confundem com autogestão individual. É a interação fluida que permite que uma grande equipe apresente Propriedades Emergentes. Facilitar autonomia de equipe e decisões mais eficientes em uma estrutura não hierárquica pode ajudar Scrum Teams a aprimorar sua autogestão.

Profissionalismo

Profissionalismo diz respeito a buscar a excelência e trabalhar em conjunto para Entregar valor de forma respeitosa, transparente e com accountability. Ser profissional significa que certas ações sempre serão tomadas — e outras jamais — independentemente das circunstâncias.

Ser Profissional implica assumir accountability total pelo Produto, do berço ao túmbulo, em todo o seu ciclo de vida. Inclui a manutenção — muitas vezes na forma de operações — e oferece ótimas oportunidades de aprendizado por feedback de resultados de engenharia para os Desenvolvedores de Produto.

No contexto de desenvolvimento de software, Profissionalismo inclui, mas não se limita, à excelência técnica (112). Excelência técnica abrange, entre outros: Specification by Example, Clean Code, Unit Testing, Test-Driven Development, Test Automation, Continuous Integration, Continuous Delivery, Architecture and Design, Acceptance Testing, além de uma consideração proposital e intencional sobre testes.

Lean Thinking

“Lean thinking (63) reduz desperdício tanto no trabalho quanto na forma de realizá-lo, focando no fluxo de valor e na melhoria contínua.” Os princípios Lean apoiam-se em melhoria contínua e respeito pelas pessoas. Ao adotar esses princípios, as organizações podem aumentar a eficácia com o menor custo de longo prazo, Entregar valor superior aos clientes e, ao mesmo tempo, fomentar um ambiente de aprendizado e desenvolvimento constante.

Empirismo

Empirismo (67) é o princípio de tomar decisões baseadas em evidências objetivas ou observáveis em ciclos de aprendizado, muitas vezes exploratórios. É valioso quando expertise por si só não basta. O Scrum baseia-se em Empirismo: decisões são guiadas por evidências ou pelo que se observa. A abordagem empírica envolve observações contínuas, desenvolvimento ou refinamento de teoria, operacionalização e testes/modificações para estabelecer ciclos de feedback eficazes.

Empirismo ajuda as Scrum Teams a Entregar algo que os Stakeholders valorizem quando o O QUÊ ou o COMO é incerto. O Scrum trata de tornar o improvável provável ao descobrir, Entregar e realizar valor — o que frequentemente inclui trade-offs ou experimentação. Experimentos geralmente se baseiam em hipóteses testáveis, mas às vezes em palpites fundamentados. A resposta essencial à experimentação é decidir com base em evidências.

Pausar e refletir combina elementos de Empirismo e Lean thinking, cria a base para transparência, inspeção e adaptação rumo à Meta do Produto, e ajuda o Scrum Team e os Apoiadores a melhorarem a si mesmos e seu ambiente.

Uma adoção eficaz de Scrum reduz a distância entre Stakeholders que apresentam problemas ou oportunidades e as pessoas que os tratam, mantendo objetivos tangíveis e significativos e Entregando valor rápida e frequentemente. Stakeholders muitas vezes têm uma falsa certeza sobre o O QUÊ e o COMO. O Scrum Team, por sua vez, pode ter uma falsa certeza sobre quem é impactado. Inspeção e adaptação devem ser mais valorizadas do que “cumprir promessas” ou atender aos Stakeholders errados. Qualquer suposição pode estar errada.

Cadência

Trabalhar em Sprints oferece um ritmo consistente que ajuda o Scrum Team a manter o foco em metas claras de curto prazo. Essa cadência sustenta inspeção e adaptação regulares, permitindo ao time aprender e ajustar-se com base no feedback. Com o tempo, constrói-se um ritmo sustentável de Entrega, aumentando a previsibilidade e fomentando a melhoria contínua.

Os Três Pilares do Controle de Processos Empíricos do Scrum

Empirismo é, em essência, a filosofia de que o conhecimento provém da experiência e da observação. Insights valiosos surgem de curiosidade, experiência, experimentação, dados, visualização e observação. Controle de processos empíricos (64-66) é um método de gerenciamento de processos complexos (30-35), como os do Scrum, que se adapta a partir dos resultados observados e se apoia nos três pilares: transparência, inspeção e adaptação.

Transparência

Transparência é um pilar do Scrum. Ela revela a realidade e a clareza do trabalho, habilitando o empirismo. Transparência fornece uma percepção mais precisa da realidade e é a porta de entrada para inspeção e adaptação. O processo, trabalho e resultados emergentes precisam estar visíveis para quem executa o trabalho ou recebe os insumos, na forma de metas, Itens do Product Backlog (Product Backlog Items) e respectivas saídas (outputs) em forma de Incrementos (Increments).

Decisões importantes baseiam-se em artefatos, experimentos, entregas ou feedbacks de resultados. Baixa transparência pode prejudicar a inspeção, levando a decisões que reduzem valor e aumentam risco. Transparência possibilita inspeção.

Feedback de resultado são dados — idealmente quantitativo e qualitativo — resultante de mudanças no Produto ou no ambiente. Ele contribui para o valor percebido pelos Stakeholders, esforço, recursos ou custos. Pessoas não são recursos.

Alcançar transparência pode ser inviável ou inaplicável caso existam ineficiências institucionais ou falta de confiança. Como corolário, o Scrum pode tornar ineficiências institucionais transparentes e, com vontade coletiva, a confiança pode ser construída.

Inspeção

Inspeção é um pilar do Scrum. Trata-se de olhar para a realidade, considerando a direção do Product (a Meta do Produto) e a eficácia do Scrum Team e dos Stakeholders. Inspeção habilita adaptação. Consiste em observar a realidade de forma intencional, apoiada naquilo que ficou transparente — evidências ou observações. Para favorecer inspeção e adaptação, o Scrum promove cadência por meio de seus eventos.

Os Artefatos Scrum, seus compromissos (Commitments) associados e o progresso rumo às metas acordadas devem ser inspecionados com frequência e diligência para detectar Propriedades Emergentes (71). Inspeção de artefatos, experimentos, entregas, mercado ou feedback de resultados pode gerar aprendizados ou efeitos colaterais. Efeitos colaterais são resultados ou consequências inesperadas ou não intencionais.

Inspeção sem Transparência é mal-informada, enganosa e gera desperdício.

Adaptação

Adaptação é um pilar do Scrum. Considerando a direção do Produto, o Scrum Team e os Stakeholders devem se adaptar à realidade assim que surgem oportunidades de melhoria — como resultados de experimentos, insights, riscos ou oportunidades. Adaptação torna-se mais difícil quando há ineficiências institucionais ou quando as pessoas envolvidas não estão prontas, dispostas ou aptas a fazer o necessário.

Adaptação começa ao aceitar a “realidade”, guiada por evidências. Normalmente ocorre nos Artefatos Scrum, compromissos associados, Scrum Team, Stakeholders, líderes e na organização. Se algum aspecto desviar além dos limites aceitáveis, ou se o Produto resultante for inaceitável, ajustes devem ser feitos o mais rápido possível para corrigir o curso.

Sem adaptação, transparência e inspeção tornam-se triviais e sem sentido.

Os Valores do Scrum

Os Valores do Scrum — foco, abertura, compromisso, coragem e respeito — criam um ambiente no Scrum Team que favorece segurança psicológica e colaboração positiva, alinhado a princípios da neurociência benéficos para aprendizado e trabalho em equipe eficaz. Considere o contexto.

Os Valores do Scrum fomentam transparência e confiança, garantindo alinhamento entre palavras e ações. Juntos, estabelecem base sólida para colaboração, desempenho e coerência dentro do Scrum Team.

A adoção bem-sucedida do Scrum depende de Scrum Team e Apoiadores (e demais Stakeholders) liderarem pelo exemplo, como profissionais. Os Valores do Scrum fortalecem a confiança entre Scrum Team e Stakeholders, além de promover ética (57), vocabulário, tom, trabalho, comportamento e ações que sustentam a confiança, reduzindo ou evitando o abismo entre discurso e prática.

O Scrum Team e os Apoiadores concordam em ser abertos sobre todo o trabalho e os desafios. Humildade sustenta a abertura. Abertura exige confiança, e confiança exige abertura. O Scrum Team e os Apoiadores devem solicitar e compartilhar feedback construtivo. Eles colaboram rotineiramente e aprendem por meio de conversas de alta largura de banda e feedback qualitativo ou quantitativo.

Conversas de alta largura de banda são aquelas que promovem uma comunicação rica, rápida e clara. Isso normalmente envolve discussões presenciais — seja fisicamente, por videochamadas, por gestão visual ou quadros brancos (físicos ou digitais) — nas quais os participantes podem usar não apenas palavras, mas também tom de voz, expressões faciais, desenhos e linguagem corporal para se compreenderem plenamente.

Como as Sprints são curtas, quaisquer falhas devem ser pequenas e rápidas, e o risco é identificado e gerenciado por meio de feedback aberto e ágil. Talvez a única falha real seja a ausência de aprendizado.

O Scrum Team e os Apoiadores devem ter Coragem para fazer o que é certo e enfrentar desafios difíceis. Devem ser corajosos ao explorar o desconhecido, mudar de direção, solicitar e compartilhar informações, e engajar-se em discordâncias respeitosas, como conflitos saudáveis e dissensos construtivos. O Scrum Team deve buscar ajuda de Apoiadores e líderes quando necessário.

O Scrum Team compromete-se a alcançar a Meta da Sprint e a apoiar uns aos outros. Comprometimento significa concluir trabalho relevante rumo à Meta da Sprint atendendo à Definição de Pronto da Entrega (Definition of Output Done), no máximo até o fim da Sprint — de preferência, muito antes. Também significa atingir os resultados desejados por meio da realização de valor.

O Foco principal é avançar o máximo possível rumo à Meta da Sprint. O foco secundário é avançar rumo à Meta do Produto. Os Apoiadores comprometem-se a fornecer um espaço psicologicamente seguro para que o Scrum Team entregue Incrementos; dentro desse Foco, o Scrum Team e os Apoiadores comprometem-se a reservar tempo para aprendizado contínuo e adaptação, bem como para a transferência de aprendizado entre Scrum Teams, garantindo eficácia no longo prazo. O Scrum Team e os Stakeholders devem ser intencionais ao lidar com trade-offs, considerando inclusive vitórias de curto prazo com consequências de longo prazo.

O Scrum Team e os Apoiadores (e demais Stakeholders) Respeitam uns aos outros como profissionais qualificados; eles Respeitam as diferentes expertises e perspectivas, e são construtivos ao discordar. Comportamento respeitoso sustenta a confiança. O Scrum Team e os Apoiadores devem criticar a ideia ou a abordagem para encontrar opções mais eficazes — não as pessoas.

O Respeito ajuda a proteger contra o uso distorcido dos outros Valores do Scrum. Demonstrações de Respeito incluem (mas não se limitam a): elogio genuíno, apoio mútuo, humildade, segurança psicológica, desacordo construtivo e diversidade cognitiva.

Os membros do Scrum Team e os Stakeholders podem observar os Valores do Scrum sob a lente do ciclo OODA de John Boyd (99, 100, 102). OODA foi criado pelo coronel da Força Aérea dos EUA John Boyd para ajudar pilotos a tomar decisões rápidas e inteligentes em situações dinâmicas, passando por quatro etapas: Observar, Orientar, Decidir e Agir. É um método simples, contínuo, iterativo e poderoso — muitas vezes subconsciente — de lidar com incertezas: notar mudanças no mercado (Observar), analisar tendências e riscos (Orientar), escolher funcionalidades do Produto para testar (Decidir) e entregá-las (Agir). OODA ajuda indivíduos a manterem flexibilidade e a responderem bem ao que surgir. O Scrum pode aprimorar o uso do ciclo OODA.

Membros individuais do Scrum Team podem observar os Valores do Scrum sob a lente do ciclo OODA, usando o Scrum para fomentar soluções com propriedades emergentes. No contexto do Scrum, os Valores do Scrum se aplicam a todas as etapas do OODA e, em especial, ajudam da seguinte forma:

• Observar — Abertura e Respeito favorecem a coleta de todas as evidências relevantes e perspectivas diversas.
• Orientar — Coragem é necessária para interpretar a realidade, lidar com a incerteza e concordar em adaptar ou mudar de direção, potencialmente usando uma pausa reflexiva para desafiar premissas e provocar novos insights.
• Decidir — Decidir o que fazer requer análise oportuna, como o refinamento do backlog, trazendo possíveis próximos passos ao Foco por meio de experimentos paralelos safe-to-fail para testar hipóteses, como sondagens de pequena escala (as sondagens devem ser pequenas, paralelas e desenhadas de forma que qualquer falha seja suportável e gere aprendizado).
• Agir — Com clareza sobre o que precisa ser feito, por que e por quem, o Comprometimento pode impulsionar o time a executar com eficácia dentro de restrições capacitadoras, como as Sprints time-boxed, fomentando soluções emergentes.

Complemento e Suporte Teórico Adicional

Product Thinking

As pessoas consomem Produtos (incluindo serviços), não projetos. Um Produto é o canal pelo qual se Entrega valor, equilibrando necessidades de curto e de longo prazo. Por isso o Scrum prevê um Product Owner, não um Project Owner. Produtos são de vida longa e exigem cuidado por toda a sua existência, ao passo que um projeto é limitado no tempo e, quando acaba, costuma deixar um Produto “órfão”.

Product thinking (86–88) lida com a tensão (111) de que, muitas vezes, um Produto precisa buscar crescimento imediato e, ao mesmo tempo, cuidar de questões de longo prazo — por exemplo, ganhar tração com early adopters, “atravessar o abismo” (5), expandir-se, lançar novas versões, lidar com mudança contínua, otimizar customer lifetime value e reduzir o custo total de propriedade.

Para “atravessar o abismo”, é preciso mudar a estratégia: sair de um público ousado e aberto a riscos para conquistar compradores, decisores, usuários ou demais Stakeholders mais pragmáticos e avessos a risco. Faz-se isso focando um nicho bem definido e Entregando uma solução completa e confiável que resolva problemas reais. Esse passo é crucial para a transição de um Produto do sucesso em nichos para a adoção em massa, pois a early majority quer provas concretas de confiabilidade e de resolução de problemas no contexto específico. Ao concentrar-se no nicho e fornecer uma solução completa, a empresa ganha credibilidade, cria clientes-referência e consolida posição, conectando de forma eficaz o abismo entre early adopters e mercado mainstream.

Product Owners precisam ser mestres em equilibrar o “aqui e agora” com o “lá e então” (148), exercitando coragem, humildade, consulta, colaboração e conflitos saudáveis para fazer trade-offs.

Se todos os envolvidos pensarem só no curto prazo, provavelmente surgirão efeitos colaterais de longo prazo, como dívida técnica, baixa moral do Scrum Team, excesso de ocupação e foco apenas em saídas. É por isso que se deve colocar fatores de mitigação que sustentem o longo prazo.

Dívida técnica é o trabalho extra que se acumula — consciente ou inconscientemente — quando se tomam atalhos de implementação ou design para Entregar algo mais rápido. Com o tempo, ele desacelera o time, assim como uma dívida financeira com juros, porque torna mudanças futuras mais difíceis e arriscadas. Profissionais buscam minimizar a dívida técnica e a negligência tanto quanto possível; se decidirem contrair dívida, ela deve ficar transparente e, de preferência, acompanhada de um plano emergente de mitigação.

No caso de Produtos, o Scrum apoia viabilidade, usabilidade, desejabilidade, valor e sustentabilidade — dentro de limites éticos (57) — por meio de:

• Design de Produto
• Gestão de Produto
• Consideração intencional da interação coesa entre Stakeholders, pesquisa, metas, descoberta, design, Entrega e realização contínua de valor
• Para Produtos tecnológicos em específico, engenharia de Produto

O Scrum favorece um equilíbrio saudável entre curto e longo prazo. A orientação a metas viabiliza resultados potenciais graças ao foco em valor e redução de riscos. A Meta da Sprint (aqui e agora) deve ser um passo rumo à Meta do Produto (lá e então), que por sua vez abre caminhos para o longo prazo. Geralmente, a Meta do Produto apoia a estratégia e a visão do Produto.

System Thinking

Systems thinking (55) reconhece a interconectividade dos elementos em contextos organizacionais e sociais, entendendo que ações em uma área geram efeitos em cadeia nem sempre previsíveis ou lineares. Experimentos baseados em teoria, feedback loops e análises posteriores de dados ajudam a revelar insights valiosos e acionáveis. Systems Thinking oferece ferramentas e ideias úteis e facilita esses insights.

Para que uma organização se torne adaptativa (80), é preciso evitar sub-otimizações locais, como reduzir custos unitários aumentando custos de longo prazo, sacrificar metas de qualidade e perder a confiança do cliente ou melhorar um Scrum Team, fluxo de trabalho ou processo que nem deveria existir. Em trabalho complexo (30-35), nem sempre é possível vincular causa e efeito, exceto em retrospecto. Ainda assim, é útil considerar impactos potenciais e reais a montante, ao longo do fluxo e a jusante de cada intervenção.

Descoberta

Descoberta (50-51) costuma começar entendendo expectativas, necessidades e desejos das pessoas por meio de observação, análise, conversas e síntese voltadas a um resultado desejado. Após coletar insights, o Scrum Team enquadra o problema ou oportunidade e os ordena pelo valor potencial. O time coleta (crowdsourcing) possíveis soluções sem julgá-las prematuramente. Se o valor potencial for alto, mas houver falta de evidência de que possa ser realizado, o Scrum Team deve pesquisar, testar premissas ou criar protótipos simples para validar com clientes, tomadores de decisão ou usuários reais. Descoberta nunca termina; considere realizar entrevistas ou observações regulares com clientes, tomadores de decisão, ou usuários.

Descoberta trata de aprender em direção a um resultado desejado por meio de priorizar, fazer, evitar ou melhorar continuamente ideias baseadas em observação de usuários, feedback e outros aprendizados. Descoberta enfatiza colaboração, criatividade e coragem para falhar e tentar de novo. Enquadra o trabalho como problemas ou oportunidades e ajuda o Scrum Team a criar, priorizar e testar opções de solução que equilibrem o que as pessoas desejam, o que é tecnicamente possível e o que faz sentido de negócio — tudo isso mantendo o fator diversão.

Se Descoberta for necessário, ela deve — na medida do possível — ser incorporada de forma coerente com o Scrum. Por exemplo, trabalho de descoberta fica transparente no Product Backlog e no Sprint Backlog; membros do Scrum Team praticam descoberta e outras habilidades; aprendizados são discutidos durante a Sprint e nos eventos do Scrum; e pelo menos um Incremento é produzido (idealmente entregue) a cada Sprint, independentemente do esforço de descoberta. É preciso equilíbrio: Descoberta ajuda a evitar construir a coisa errada, mas pode ser excessivo — no fim, o feedback do resultado é o que mais conta.

Liderança

Liderança é a capacidade de influenciar, guiar e inspirar um grupo de pessoas a alcançar um objetivo comum, evitando desmotivação. Ela inspira pensamentos, ações e paixão, fomentando direções estratégicas claras. Abrange o Veja (Go See), Ouça (Listen), e Entenda (Understand) intencional — coletar fatos e observações para embasar decisões, prática conhecida como Genchi Genbutsu (84).

Liderança é um processo social dinâmico que envolve responsabilidade, construção de relacionamentos e empoderamento. A liderança bem-sucedida resulta em co-criação de uma direção de viagem, alinhamento efetivo de recursos e pessoas necessários e compromisso mútuo entre os membros.

O Scrum busca um tipo específico de liderança: liderança para resiliência — um conjunto de qualidades, não um cargo gerencial. Portanto, Liderança deve incluir, mas não se limitar a, cultivar o ambiente para Scrum Teams autogerenciados, clareza, confiança, transparência, propriedades emergentes em uma direção, realização no trabalho, aceitação da incerteza (72) e das falhas, coleta de evidências para melhores decisões, gestão proativa de riscos e remoção de ineficiências organizacionais.

Liderança ocorre de todos os ângulos, em todos os níveis, e promove reflexão nos momentos certos. Deve buscar valor de forma incansável, mas com compaixão e ética. Exige protagonismo persistente para mudar fluxos de trabalho, processos, sistemas e o ambiente de trabalho — incluindo (mas não se limitando a) RH, finanças e gestão de fornecedores. Líder é quem demonstra Liderança.

Product Owners e Scrum Masters equilibram liderança, autoridade e controle sutil fornecendo clareza de propósito, fomentando iniciativa e reforçando accountability. Eles guiam em vez de microgerenciar, garantindo que o Scrum Team compreenda visão e metas, tenha autonomia para executar e permaneça accountable pelos resultados. Quando a intervenção é necessária, eles agem de forma decisiva, preservando a responsabilidade do time sobre suas accountabilities. Desenvolvedores de Produto demonstram Liderança por meio de orientação ao time autogerenciado, profissionalismo e foco em metas; a autogestão traz responsabilidades. Apoiadores exibem Liderança ao remover impedimentos de curto e longo prazo, tornar processos de gestão coerentes com o Scrum e apoiar mudanças emergentes em direção poderosa quando solicitado.

First Principles Thinking

First Principles Thinking, que podemos traduzir como Pensamento de Primeiros Princípios, é um método de resolução de problemas que consiste em decompor desafios em suas verdades fundamentais e descobrir soluções a partir do zero. Em vez de depender de analogias ou convenções estabelecidas, a abordagem pergunta: “O que sabemos com certeza?” e reconstrói entendimento e soluções a partir desses elementos básicos. Exemplos incluem, mas não se limitam a:

• Incentivar o Scrum Team a focar nos impulsionadores centrais de efetividade, adaptatividade (80) e tempestividade — como autonomia, transparência e adaptação — em vez de seguir processos cegamente ou copiar outras organizações.
• Questionar cada premissa e reconstruir soluções com base em fatos e princípios essenciais, possibilitando avanços significativos.
• Promover pensamento original, melhoria contínua e a coragem para desafiar o status quo — desbloqueando criatividade e permitindo resultados transformadores.

Pessoas e Mudança

O nível de dificuldade para adotar o Scrum não deve ser subestimado. O Scrum oferece princípios norteadores por meio de seus elementos e um caminho para retornar aos first principles.

Scrum não se resume à adoção de ferramentas — e tampouco termina com a remoção de impedimentos. Um impedimento no Scrum é qualquer coisa que bloqueie ou atrase o progresso. É essencial ser intencional, incansável e tenaz em relação a pessoas, mudança e comunicação. A mudança costuma envolver desenvolvimento de pessoas, designs, fluxos de trabalho, processos, sistemas, atitudes, comportamentos, linguagem, hábitos e clima de trabalho. Cultura é resultado de propriedades emergentes.

Uma adoção eficaz de Scrum usa uma abordagem emergente, conta com agentes de mudança efetivos e mobiliza apoio entusiástico de quem é afetado ou influencia o processo. Intencionalidade e progresso diário na adoção são cruciais; o trabalho de adoção não deve ficar para depois de “tudo o mais”.

Comece com mudança emergente disciplinada em uma direção. Busque tornar essa mudança tão normal que acabe integrada ao trabalho planejado. Uma adoção de Scrum tem direção, mas não destino predefinido. A mudança é emergente e, portanto, imprevisível. Curiosidade habilita um ciclo de perceber, escutar, aprender e adaptar em determinado rumo. É importante cultivar relacionamentos, compreender perspectivas e ouvir o que não é dito nem acontece. Mudança dá trabalho, mas é gratificante.

Os Papéis do Scrum no Pacote de Expansão

Os quatro papéis (roles) do Scrum são Product Owner, Desenvolvedor de Produto, Scrum Master e Stakeholder. Eles concedem, recompensam e conquistam confiança, além de habilitar liderança coerente. Somente três accountabilities — Product Owner, Desenvolvedor de Produto e Scrum Master — compõem o Scrum Team.

Uma pessoa pode acumular mais de um papel Scrum, mas deve ter cuidado para não ultrapassar limites. Os papéis do Scrum são projetados para garantir freios e contrapesos.

Um Scrum Team é um time que pratica Scrum, cobre as três accountabilities — Scrum Master, Product Owner e Desenvolvedor de Produtos —, lida com problemas ou oportunidades de Stakeholders (clientes ou usuários inclusive) e entrega Incrementos úteis, usáveis e potencialmente valiosos, tanto para o próprio time quanto para os Stakeholders, rumo à Meta do Produto. Para trabalho complexo (30-35), um Scrum Team deve ser pequeno, com diversidade cognitiva e autogerenciável, na qual membros humanos — muitas vezes assistidos por tecnologia — se importam com o trabalho uns dos outros e aprendem a executá-lo em conjunto.

O Scrum Team deve ser multifuncional (cross-functional), ou seja, multidisciplinar, incluindo habilidades técnicas e de domínio de negócio. Não há hierarquia explícita dentro do time. A equipe precisa ter todas as competências e suporte necessários para:

• Descobrir (incluindo pesquisa e design) conforme necessário;
• Entregar (incluindo engenharia, quando apropriado); e
• Validar a realização de valor (e também usabilidade, desejo e viabilidade dentro de limites éticos (57)).

O Scrum Team, com apoio dos Apoiadores, cuida coletivamente do domínio de problemas ou oportunidades, descoberta do Produto, entrega, verificação e qualidade embutida, go-to-market e validação de valor rumo à Meta do Produto. O time busca melhorias líquidas; sendo autogerenciado (49), decide quem faz o quê, como, quando e onde.

Validação de valor é a confirmação (ou refutação), dentro de limites definidos, de que o(s) resultado(s) esperado(s) foi(foram) alcançado(s).

O Scrum Team disponibiliza Incremento(s) a cada Sprint, gerencia-se continuamente (49) para encontrar e corrigir problemas, sincroniza-se o tempo todo e entrega frequentemente. A equipe é pequena o suficiente para ser ágil e grande o bastante para concluir trabalho significativo dentro do Sprint. Geralmente, Scrum Teams menores se comunicam melhor e são mais produtivas.

O Scrum baseia-se em Scrum Teams autogerenciáveis (49) dentro de uma estrutura organizacional ou de Produto definida. Existe autonomia, mas limitada pelos eventos do Scrum, accountabilities, artefatos (artifacts), compromissos, pilares, valores e necessidades da organização.

O Scrum reúne grupos de pessoas que, juntas, têm ou adquirem todas as habilidades necessárias para executar o trabalho, compartilhando-as quando preciso. Interações intencionais, com apoio de líderes, são necessárias para aumentar as chances de sucesso.

O Foco deve permanecer em atingir a Meta do Produto da forma mais eficaz, com o investimento adequado, ao mesmo tempo entregando resultados valiosos.

O Scrum estimula trabalho colaborativo, incentivando interação contínua e accountability compartilhada em vez de trabalho sequencial e em silos. Isso permite que Scrum Team e Stakeholders abracem a incerteza (72), possibilitando ajustes mais rápidos guiados por aprendizado e feedback contínuos. A sobreposição de descoberta, desenvolvimento e validação de valor assegura uma abordagem mais adaptativa (80) e orientada a valor no desenvolvimento de Produtos.

Trabalho sobreposto promove accountability compartilhada entre os membros do Scrum Team, aumentando engajamento e comprometimento. A equipe volta sua atenção para desafios e oportunidades, incentiva comportamento proativo, cultiva repertório diverso de habilidades e amplia a percepção das dinâmicas de mercado de todos os participantes.

O Scrum Team cuida de todas as atividades ligadas ao Produto, da colaboração com Stakeholders à validação de valor, incluindo verificação, manutenção, operação, experimentação, pesquisa e desenvolvimento, e o que mais for necessário. A equipe incorpora qualidade. Os Apoiadores asseguram que a organização ofereça uma estrutura adequada de clima organizacional e ambiente de trabalho, além de empoderar o time Scrum para a auto-organização (49). Trabalhar em Sprints a um ritmo sustentável melhora Foco e consistência.

Scrum Team e Stakeholders não sabem o que vão aprender. Alguns aprendizados trazem mais certeza; outros, mais incerteza (72). Certos pontos podem emergir, desaparecer, perder importância ou prioridade.

O Scrum Team possui autonomia alinhada. Isso significa liberdade para decidir como resolver problemas, mantendo foco em metas e resultados compartilhados, permitindo inovação e coerência organizacional. Incentivar diversidade cognitiva é essencial. A polinização-cruzada (cross-pollination) ocorre mais facilmente quando membros colaboram, confiam uns nos outros e praticam auto-reflexão.

Para resultados bem-sucedidos, Scrum Team e Apoiadores devem estar dispostos a desaprender princípios ultrapassados. Inspeção e Adaptação exigem um clima que antecipe e tolere erros. É essencial direcionar críticas a ideias, não a pessoas. Todos na equipe “jogam no mesmo campo”, com trabalho coerentemente sobreposto, e são todos accountable pelo sucesso.

Stakeholder

Stakeholder é um papel. Um Stakeholder pode ser entidade, indivíduo ou grupo interessado, afetado ou que impacta insumos, atividades e resultados. Os Stakeholders têm interesse direto ou indireto na organização, em seus Produtos ou serviços, dentro ou fora dela.

Exemplos de Stakeholders incluem (mas não se limitam a) clientes, tomadores de decisão, usuários, fornecedores, influenciadores, gerentes, colegas, líderes, legisladores, patrocinadores financeiros, especialistas no assunto e órgãos de supervisão de governança. Stakeholders inanimados ou não humanos, como a lei ou a IA, também contam. Alguns Stakeholders impactam mais — ou são mais impactados — que outros, e cada qual valoriza fatores distintos. O grau de poder ou influência varia.

Cliente é qualquer Stakeholder que recebe valor do Produto ao comprá-lo e/ou escolhê-lo. Clientes podem incluir compradores (quem paga ou adquire), tomadores de decisão (quem aprova ou autoriza a adoção) e usuários finais (quem interage diretamente). Às vezes o cliente não é o mesmo que o cliente final, como em B2B2C (79) ou B2B2B (78).

Para uma adoção de Scrum bem-sucedida, é fundamental haver interações intencionais e regulares entre os Stakeholders (incluindo, mas não se limitando a, clientes e usuários) e o Scrum Team.

Usuário é o Stakeholder que interage diretamente com o Produto para atingir objetivos ou resolver problemas. Usuários experimentam o Produto em primeira mão — serviço, plataforma ou experiência — e seu feedback e satisfação são essenciais para melhorias contínuas. Usuários podem ou não influenciar a decisão de compra, mas sua adoção e engajamento são vitais para o sucesso continuado. Por vezes, o usuário não coincide com o usuário final, como em B2B2C ou B2B2B. Para uma adoção de Scrum bem-sucedida, é fundamental haver interações intencionais e regulares entre usuários (e, possivelmente, usuários finais) e o Scrum Team.

Tomador de decisão (denominado “chooser” por Jeff Patton) (82) é o Stakeholder com autoridade para aprovar, escolher ou autorizar a adoção ou compra do Produto. É responsável por avaliar opções e tomar a decisão final, considerando geralmente as necessidades de usuários e da organização mais ampla. Tomadores de decisão podem ou não usar o Produto diretamente, mas suas escolhas impactam quais Produtos são adotados e como o valor é entregue a outros Stakeholders. Para uma adoção de Scrum bem-sucedida, muitas vezes é melhor seguir com informações imperfeitas e capturar feedback emergente de resultados.

Legisladores (e, neste documento, formuladores de políticas externas ou internas) estabelecem regras, políticas e limites para operação do Produto. Definem arcabouços legais, regulatórios ou organizacionais que moldam a entrega de valor aos Stakeholders e os padrões de profissionalismo. Asseguram que o Produto esteja alinhado a mandatos externos ou internos, orientando sua evolução e sustentabilidade. Para uma adoção de Scrum bem-sucedida, é crucial não exagerar nem subestimar requisitos legais.

Patrocinadores financeiros fornecem financiamento e recursos para o desenvolvimento, lançamento e aprimoramento do Produto. Avaliam a viabilidade, o valor e a exequibilidade, investindo de acordo com o potencial do Produto de entregar valor contínuo aos Stakeholders. Influenciam a visão, a estratégia e os objetivos para garantir o alinhamento com o retorno sobre o investimento e a sustentabilidade a longo prazo. Para uma adoção de Scrum bem-sucedida, é crucial ter uma atitude e um financiamento flexíveis à medida que novas informações surgem.

Especialistas no assunto trazem conhecimento profundo ou habilidades únicas essenciais à criação, evolução e manutenção do Produto. Sejam especialistas em tecnologia, design, compliance ou domínio específico, eles apoiam a usabilidade, exequibilidade, profissionalismo e extensibilidade do Produto, mas não atrapalham Scrum Teams autogerenciáveis (49). Podem ajudar a tratar lacunas de satisfação e contribuir para a capacidade do Produto de se adaptar e identificar, representar ou mensurar propriedades emergentes (71). Para uma adoção de Scrum bem-sucedida, é crucial promover a transferência regular de aprendizado dos especialistas no assunto para e entre o Scrum Team.

O termo lacuna de satisfação refere-se à diferença entre o que os Stakeholders experimentam hoje e o que gostariam de experimentar — ou seja, a lacuna entre o nível atual de satisfação e o nível potencial.

Governança refere-se a estruturas, padrões, regulações, normas, processos e práticas que conscientemente restringem e guiam a direção, a tomada de decisão e a accountability do Produto. Governança promove transparência e orienta a aderência a padrões de valor, viabilidade e profissionalismo. Proporciona mecanismos para gestão de riscos e adaptação do Produto a necessidades ou ambientes em mudança, sustentando sua natureza evolutiva e duradoura. Para uma adoção de Scrum bem-sucedida, é crucial que a governança seja coerente com o Scrum — por exemplo, um ponto único de contato por área de governança, com interações intencionais sobre qualidade e compliance com o Scrum Team, inspeção e adaptação regulares da própria governança e ausência de surpresas.

Apoiador

Apoiador é um tipo específico de Stakeholder. Apoiadores são Stakeholders de apoio e agentes de mudança. Frequentemente integram uma coalizão orientadora poderosa (83), inspirando e removendo fatores de desmotivação. Apoiadores ajudam o Scrum Team a prosperar e influenciam fluxos de trabalho, processos, sistemas, Produtos, serviços e ambiente de trabalho da organização para ficarem coerentes com a adoção do Scrum e com propriedades emergentes (71). Devem participar quando e onde necessário, ou quando solicitados. A criação de valor geralmente exige colaboração efetiva e construtiva com outros Stakeholders.

Dependendo do tamanho da organização, exemplos de Apoiadores incluem (mas não se limitam a) colegas, tomadores de decisão, patrocinadores financeiros, responsáveis por governança, gerentes, especialistas no assunto, equipe de marketing, RH, finanças, compras e early adopters (adotantes iniciais). Apoiadores que não dão poder aos Scrum Teams para fazer o recomendado neste documento não são Apoiadores de fato. Executivos e membros do conselho têm papel crucial em fomentar um clima onde Apoiadores apoiem. Apoiadores devem demonstrar liderança valorizada pelo Scrum Team.

Inteligência Artificial

Inteligência Artificial (IA) está cada vez mais presente no ambiente de trabalho e pode ampliar significativamente as capacidades do Scrum Team em descoberta, tomada de decisão, desenvolvimento do Produto e realização de valor.

A IA pode potencializar o Scrum por meio de:

• Controle Empírico de Processo (64‑66): análises suportadas por IA elevam transparência, inspeção e adaptação.
• Aumento Cognitivo: IA libera os membros humanos do Scrum Team para se concentrarem em aspectos estratégicos, criativos e éticos.
• Adaptação Contínua de Valor: IA pode atualizar e repriorizar os Itens do Product Backlog com base em feedback de usuários em tempo real e tendências.
• Visão Sistêmica: IA identifica interdependências ocultas, melhorando decisões baseadas em dado.

As possibilidades são infinitas. Scrum Teams podem usar IA para:

• Detectar ambiguidades em textos e inspecionar continuamente suas recomendações e resultados em busca de vieses, erros e consequências não intencionais.
• Validar e adaptar modelos e aplicações regularmente.
• Promover transparência na ordenação do Product Backlog.
• Criar agentes como membros IA da equipe.
• A IA pode ser útil para testar e desafiar deliberadamente o pensamento existente.

Os perigos também são infinitos. Mantenha accountability humana clara por todos os resultados (conforme as accountabilities do Scrum), usando IA como parceira poderosa porém supervisionada de decisão — manter o humano no controle. Embora IA possa aumentar inovação e efetividade a custos menores, ela não substitui a accountability humana. A IA deve apoiar — não sobrepor — o Controle Empírico de Processo (64‑66) do Scrum e decisões éticas (57). O Scrum Team continua accountable pela entrega de resultados valiosos, avaliar evidências e manter o profissionalismo.

A IA pode ser ferramenta de apoio quando usada com boa intenção. Ferramentas de IA devem ser avaliadas como qualquer outro elemento que contribua para estado de fluxo psicológico (70) e aprendizado: elas melhoram os ciclos de feedback? Ajudam a validar premissas mais rápido? Quando agem, agem de forma ética (57)?

Estado de fluxo psicológico (70) é um estado de completa imersão e prazer em uma atividade, no qual ação e consciência se fundem e o tempo parece passar de modo diferente.

Scrum incentiva o Scrum Team a experimentar IA com responsabilidade, usando testes pequenos e, às vezes, reversíveis. Adaptação e inspeção aplicam‑se não só ao Produto, mas também à forma como IA é integrada à entrega.

O foco deve permanecer na dinâmica humana de trabalho em equipe e colaboração, com a IA posicionada como auxílio potencial.

Desenvolvedor de Produto

“Desenvolvedor de Produto” é um papel e uma accountability. Todos os Desenvolvedores de Produto somados devem ter todas as habilidades necessárias para criar Incrementos. Esse conjunto de competências é chamado de multifuncional.

Um Desenvolvedor de Produto pode ser humano ou automatizado. Desenvolvedores de Produto humanos são Comprometidos com criar, pesquisar, inspecionar e adaptar qualquer aspecto de um Incremento publicável a cada Sprint. Seu Foco principal está na Sprint atual. Com frequência, parte da capacidade é investida em refinamento voltado ao futuro e na análise de feedback de resultados, efeitos colaterais ou outros aprendizados.

Desenvolvedores de Produto seguem a Definition of Output Done e buscam melhoria líquida. Obtêm melhores resultados quando se dedicam a um único Produto. Se, em determinado momento, o Product Owner ou o Scrum Master trabalhar ativamente em Itens do Sprint Backlog, atuará como Desenvolvedor de Produto.

Os Desenvolvedores de Produto devem adotar comportamentos apropriados à situação; incluem‑se (mas não se limitam a) colaborador, criador e defensor da qualidade técnica, descoberta, entrega e validação de valor.

Pelo menos um Desenvolvedor de Produto deve ser humano. Vários Desenvolvedores de Produto humanos geralmente aumentam a diversidade cognitiva, útil para lidar com complexidade.

Desenvolvedores de Produto são sempre coletivamente accountable por:

• Criar um plano emergente no Sprint Backlog para atingir a Meta da Sprint;
• Incorporar qualidade seguindo e aprimorando a Definition of Output Done;
• Criar pelo menos um Incremento utilizável a cada Sprint;
• Aprender, muitas vezes por meio de dados orientados pela Definition of Outcome Done;
• Adaptar o plano diariamente rumo à Meta da Sprint;
• Responsabilizar‑se mutuamente como profissionais; e,
• Buscar melhoria líquida.

Contexto importa, é crucial considerar as circunstâncias. Mas, como regra geral, um Desenvolvedor de Produto que não esteja disposto, pronto ou apto a ser profissional deve deixar o papel de Desenvolvedor de Produto.

Product Owner

Product Owner é um papel e uma accountability. O Product Owner deve ser humano. Para ser efetivo, precisa atuar como líder do Produto. O Product Owner maximiza o valor de longo prazo e precisa saber onde está o valor e quando ele é necessário. Espera‑se que trabalhe em todos os níveis e áreas de negócio relevantes. Colabora com Stakeholders, Scrum Master e Desenvolvedores de Produto para gerar valor.

O Product Owner usa o Product Backlog para definir o que será construído e em que ordem aproximada. Mantém a Meta do Produto sempre em mente; seu principal Foco é maximizar o valor de longo prazo a cada passo.

O papel do Product Owner não é ficar analisando e redigindo Itens detalhados do Product Backlog. Cada minuto sem confiar nos Desenvolvedores de Produto é uma oportunidade perdida de pensar mais estrategicamente, trabalhar mais com Stakeholders ou criar mais valor. O Product Owner deve adotar comportamentos adequados a cada situação, incluindo (mas não se limitando a) visionário, representante do cliente, colaborador, influenciador, experimentador, tomador de decisão e defensor do engajamento dos Stakeholders, clareza, qualidade do Produto e realização de valor.

O Product Owner é sempre accountable por:

• Engajamento dos Stakeholders, compreensão de seu poder, expectativas, necessidades e desejos;
• Perceber, ouvir, aprender e adaptar continuamente conforme necessário;
• Equilibrar continuamente trade-offs, incluindo, mas não se limitando a:
  • Qualidade, velocidade, capacidade, redução de risco, valor, simplicidade (149);
  • Stakeholders e suas expectativas e limites diversos;
  • Valor, clima de trabalho, potenciais clientes;
• Desenvolver e comunicar explicitamente a Meta do Produto;
• Criar e comunicar efetivamente uma narrativa coerente do Produto;
• Criar e comunicar claramente os Itens do Product Backlog;
• Ordenar os Itens do Product Backlog;
• Garantir que o Product Backlog seja transparente e compreendido;
• Comunicar efetivamente os outcomes respaldados por métricas na Definition of Outcome Done;
• Ter a palavra final sobre a Definition of Outcome Done;
• Promover a criação, descoberta, entrega e validação de valor em alta qualidade;
• Outras atividades de gestão de Produto conforme necessário.

O Product Owner pode executar essas tarefas ou colaborar com o Scrum Team para acordar responsabilidades. Em qualquer caso, o Product Owner continua accountable.

Para o sucesso do Product Owner, todos os Stakeholders e Apoiadores devem Respeitar suas decisões. Essas decisões ficam visíveis no conteúdo e na ordem do Product Backlog e no Incremento inspecionável na Sprint Review. O Product Owner possui autoridade delegada pela organização.

Product Ownership exige sólidas habilidades de gestão de Produto e domínio de negócio. Um Product Owner carente dessas competências pode necessitar de apoio e orientação até desenvolvê‑las. Contexto importa. Mas, em geral, um Product Owner que não esteja disposto, pronto ou apto a adquirir habilidades de gestão de Produto deve deixar o papel. Um especialista no assunto nem sempre é a melhor escolha para Product Owner, pois são necessárias habilidades de gestão de Produto e liderança; muitas vezes a accountability de Desenvolvedor de Produto é mais adequada.

Se o Scrum Team, de forma não recomendada, trabalhar em múltiplos Produtos, plataformas ou projetos, cada gerente de Produto, plataforma ou projeto deve ser Stakeholder (e Apoiador) do Product Owner e colaborar para maximizar o valor de longo prazo. O Scrum incentiva a equipe a manter Foco e Comprometimento, ajudando a entregar resultados valiosos e evitar armadilhas de atuar como “fábrica de recursos” (feature‑factory).

O Product Owner é uma pessoa, não um comitê nem tecnologia. Quem quiser alterar o Product Backlog precisa convencer o Product Owner. Ele maximiza o valor de longo prazo e frequentemente faz trade‑offs para isso.

Scrum Master

O Scrum Master é um papel e uma accountability. O Scrum Master precisa ser humano. É um agente de mudança que atua em todos os níveis da organização e áreas de negócio. Lidera pelo exemplo e orienta a eficácia de Product Owner, Scrum Team, Stakeholders e Apoiadores na adoção do Scrum. Compreende complexidade (30‑35) e habilita com habilidade “o próximo passo certo”.

O Scrum Master deve adotar comportamentos adequados à situação; incluem‑se (mas não se limitam a) guia, coach, mentor, professor, observador, removedor de impedimentos, agente de mudança, facilitador de efetividade e campeão de melhoria contínua. O Scrum Master não é administrador de equipe, gerente de status, mestre de tarefas, ditador de regras, agendador de salas, administrador de dashboards, presidente de reuniões, herói, coordenador, nem um Scrum Master ausente que “deixa tudo por conta da autogestão”.

O Scrum Master é accountable pela efetividade do Scrum Team, dos Stakeholders, dos Apoiadores e das pessoas impactadas na adoção de empirismo (67), autogestão e Scrum conforme descrito neste documento. Ele trata tudo o que impede ou atrasa o progresso do Scrum Team e que ela não consiga resolver sozinha.

O Scrum Master apoia o Scrum Team, Product Owner e Apoiadores de várias maneiras, incluindo:

• Ajudando todos a compreender teoria e prática do Scrum, educando ou fazendo coaching quando necessário;
• Possibilitando melhoria contínua do Scrum Team e dos Apoiadores de diversas formas;
• Promovendo interações oportunas, intencionais e com propósito;
• Garantindo que o Scrum Team possua Definition of Output Done adequada;
• Assegurando que todos os eventos do Scrum ocorram, sejam construtivos, produtivos e dentro do timebox;
• Causando a remoção de impedimentos ao trabalho de Produto e à adoção eficaz do Scrum;
• Fazendo coaching para autogestão (49) e multifuncionalidade;
• Ajudando Scrum Team, Stakeholders e Apoiadores a entender a importância de apoiar Incrementos de alto valor que atendam à Definition of Output Done rumo à Meta do Produto e à Definition of Outcome Done;
• Melhorando a adaptatividade (80) e otimizando o fluxo de valor;
• Fomentando confiança baseada em evidências, com compaixão e timing para evitar excesso de confiança;
• Estimulando a atuação como agente de mudança e a iniciativa por parte do Scrum Team e dos Apoiadores;
• Encorajando comportamentos úteis dentro do Scrum Team, alinhados aos Valores do Scrum, fomentando confiança, colaboração e alta performance; e,
• Incentivando o Scrum Team a entregar trabalho valioso, obter feedback e fazer retrabalho quando necessário, de forma rápida e frequente.

O Scrum Master apoia o Scrum Team de várias maneiras, incluindo:

• Apoiando na formação, no desenvolvimento de habilidades e na melhoria contínua do Scrum Team;
• Ajudando o Scrum Team a entender a necessidade de Itens do Product Backlog claros, concisos e que entreguem valor; e,
• Mantendo-se atento para garantir que todo o Scrum Team esteja colaborando de forma intencional e com propósito entre si e com os Stakeholders, respeitando a Definition of Output Done e focando na criação de Incrementos de alto valor, conforme a Definition of Outcome Done.

O Scrum Master apoia o Product Owner de várias maneiras, incluindo:

• Ajudando a encontrar técnicas para definir a Meta do Produto e gerenciar o Product Backlog de forma eficaz;
• Ajudando a estabelecer planejamento emergente do Produto em ambiente complexo (30‑35);
• Ajudando o Product Owner a expressar resultados como métricas via Definition of Outcome Done;
• Ajudando o Product Owner a entender a necessidade de Itens do Product Backlog claros e concisos que entreguem valor; e,
• Ajudando o Product Owner a Focar na realização de valor.

O Scrum Master apoia os Stakeholders de várias maneiras, incluindo:

• Quando mais do que expertise é necessário, ajudando as pessoas afetadas e os Stakeholders a compreender e adotar:
  • Uma abordagem empírica para trabalhos complexos (30–35), em que causa e efeito só se tornam coerentes em retrospecto;
  • Ir além do controle empírico de processo, por exemplo, conduzindo vários experimentos paralelos seguros para falhar (safe-to-fail); buscando pensamento novo, exaptação ou testes de hipóteses fundamentadas. Exaptação significa pegar algo que foi criado ou usado para um determinado propósito e utilizá-lo para um propósito diferente — especialmente quando se enfrenta situações novas ou incertas.
• Fomentando ações que apoiem o mantra “Pare de colocar itens em andamento; comece a finalizar itens;”
• Facilitando a colaboração dos Stakeholders quando solicitado ou necessário;
• Ajudando os Stakeholders a entender a necessidade de Itens do Product Backlog claros e concisos que entreguem valor; e,
• Ajudando os Stakeholders a Focar principalmente na realização de valor.

O Scrum Master trabalha com os Apoiadores de várias maneiras, incluindo:

• Liderando, treinando e fazendo coaching dos Apoiadores na adoção do Scrum;
• Esclarecendo o que está dificultando a adoção efetiva do Scrum;
• Facilitando mudança emergente disciplinada em uma direção que apoie a adoção do Scrum; e,
• Promovendo mudanças organizacionais visando facilidade de entrega em vez de facilidade de gestão.

O Scrum Master trabalha com a organização de várias maneiras, incluindo:

• Liderando, treinando e fazendo coaching da organização em suas adoções de Scrum;
• Planejando e aconselhando adoções de Scrum dentro da organização;
• Trabalhando com departamentos correlatos sobre como podem apoiar a adoção de Scrum; e,
• Removendo barreiras às adoções de Scrum.

Scrum Masters podem formar parcerias com outros Scrum Masters ou Apoiadores para apoiar toda a organização; também podem colaborar com outros agentes de mudança ou líderes quando necessário. Como agente de mudança, o Scrum Master é accountable pela qualidade da adoção de Scrum e deve colaborar com outros agentes para melhorá‑la.

O Scrum Master é uma pessoa, não um comitê nem tecnologia, e serve ao Product Owner, ao Scrum Team, aos Stakeholders e à organização em geral. Como agente de mudança e líder, deve convidar as pessoas a participar da mudança. É útil que o Scrum Master compreenda o fluxo de valor (68,69), Lean (63), complexidade (30‑35) e outras teorias de apoio deste documento, além de auxiliar as pessoas no como. Também ajuda se for incansável e tiver apetite insaciável por aprendizado e mudança.

Ser Scrum Master é uma vocação em que ajudar os outros a ter sucesso já é recompensa suficiente. Não busca os holofotes. Como bom líder, dá crédito aos outros e assume responsabilidade quando algo sai errado. Permanecer mais tempo no papel ajuda a guiar o Scrum Team até seu pleno potencial — mas somente se os Desenvolvedores de Produto desenvolverem autogestão coletivamente. Comportamento de “pai‑mãe” não promove Scrum Teams autogerenciáveis. Contexto importa. Mas, em geral, um Scrum Master que não esteja disposto, pronto ou apto a ser agente de mudança deve deixar o papel de Scrum Master.

Os Artefatos Scrum no Pacote de Expansão

Os artefatos do Scrum oferecem Transparência sobre aquilo que o Scrum Team e os Stakeholders acreditam que Entregará valor. Dessa forma, todos compartilham a mesma base para Inspeção e Adaptação.

Cada artefato possui um compromisso:

• Para o Produto que atende os Stakeholders, o compromisso é a Definition of Outcome Done.
• Para o Incremento, que é uma atualização candidata do Produto, o compromisso é a Definition of Output Done.
• Para o Product Backlog, o compromisso é a Meta do Produto.
• Para o Sprint Backlog, o compromisso é a Meta da Sprint.

Ao entregar o Incremento (saída), é o Produto que gera valor (resultados). Valor é o atendimento ou criação mensurável ou observável de expectativas, necessidades ou desejos, do ponto de vista dos Stakeholders.

Esses compromissos reforçam os pilares de Transparência, Inspeção e Adaptação, viabilizando o controle empírico de processo (64–66). A Meta do Produto permanece fixa enquanto não surgirem evidências ou observações contrárias na Definition of Outcome Done do Produto observado. A Definition of Output Done não deve ser enfraquecida durante a Sprint. Então, o que pode ser ajustado ou reduzido, se necessário? Podem ser os critérios de aceitação de um item específico do Product Backlog; a implementação ou o nível de fidelidade de uma funcionalidade específica; ou até mesmo a substituição de Itens do Product Backlog por alternativas que ainda permitam alcançar o Sprint Goal, etc.

Se a Meta do Produto mudar com frequência, isso pode ser um sinal de que algo está errado, possivelmente pela falta de Foco no que realmente importa. Foco é sobre agir com profissionalismo, decidindo o que fazer e o que não fazer.

Produto

O Produto é um artefato. Um Produto pode ser uma experiência holística ou uma plataforma. Também pode ser um serviço — físico, digital ou híbrido — que Entrega valor contínuo aos Stakeholders (incluindo, mas não se limitando a, usuários).

Uma experiência é uma solução específica projetada para atender às necessidades dos Stakeholders, incluindo o usuário, idealmente externo à organização. Fornece uma interação direta que gera valor. Normalmente é focada em resolver um problema ou oportunidade específica — ou um conjunto deles — para os Stakeholders, incluindo, mas não se limitando a, clientes, tomadores de decisão e usuários.

Uma plataforma é um componente arquitetural, infraestrutura fundamental ou conjunto de ferramentas que permite a desenvolvedores criarem Produtos para oferecer uma experiência. Plataformas oferecem uma base sobre a qual múltiplos Produtos podem ser desenvolvidos, com foco em escalabilidade, confiabilidade e flexibilidade para engenheiros — e não em interação direta com o usuário.

O Scrum Team e os Stakeholders precisam ter clareza, o tempo todo, sobre o que é o Produto, quem são os clientes, usuários ou tomadores de decisão, e qual é o tipo de Produto — como um voltado para usuários finais, colaboradores ou Scrum Teams — pois cada tipo possui Stakeholders distintos e diferentes formas de gerar valor. Um Produto é evolutivo e frequentemente tem vida longa. O Produto precisa de um único Product Backlog para aumentar a Transparência e maximizar o valor.

O contexto importa. Mas, como regra geral, para que um Produto crie e mantenha tração, ajuda se o Produto:

• Aborda adequadamente as lacunas de satisfação;
• É valioso, desejável, viável, utilizável, exequível, seguro e protegido;
• Tem o profissionalismo incorporado;
• Possui uma visão de Produto, estratégia de Produto e Meta de Produto claros, envolventes e orientados a métricas de resultado — frequentemente incluindo intenção, justificativa e anti-objetivos;
• Adapta-se e melhora para identificar, representar ou mensurar propriedades emergentes (71); e,
• É extensível e manutenível.

O Produto é a manifestação do porquê fazemos o quê fazemos.

Compromisso: Definition of Outcome Done

A Definition of Outcome Done é um compromisso. Ela descreve as evidências observáveis, em forma de métricas quantitativas ou qualitativas, necessárias para demonstrar os benefícios realizados — frequentemente referidos como validação de valor. Pode se referir ao Produto como um todo ou a uma meta específica. Geralmente, é melhor definir essas métricas antes de iniciar a realização, pois isso evita viés e interpretações equivocadas.

Os resultados e suas interpretações relacionadas orientam adaptações futuras, idealmente confirmando o impacto pretendido nos Stakeholders (incluindo, mas não se limitando, ao impacto nos negócios ou nos usuários) — ou seja, medindo se a saída realmente cumpriu o resultado esperado e gerou valor real. Isso pode estar relacionado a uma meta específica, como uma funcionalidade de maior porte ou várias funcionalidades, e ser validado por meio de telemetria do Produto (o próprio Produto consegue medir seu uso). Alternativamente, pode se aplicar ao Produto como um todo, onde normalmente o foco está no impacto estratégico e na validação da eficácia da estratégia implementada (120–124). Ou uma combinação de ambos.

Prefira evidências diretas a evidências circunstanciais. Por exemplo:

• Resultados de clientes podem se concentrar na Entrega de valor mensurável para os clientes, como aumento da satisfação, redução de custo de longo prazo ou número de demandas (jobs) do cliente atendidas;
• Resultados de usuários podem abordar mudanças específicas no comportamento dos usuários que resolvam problemas e melhorem a experiência, como completar tarefas com mais eficiência ou engajar com novas funcionalidades;
• Resultados de Stakeholders do Produto podem conectar essas mudanças de comportamento às métricas de desempenho do Produto, como tendências em métricas de clientes, tomadores de decisão ou usuários; tempo para entregar o Produto; tempo para aprender; tempo para mudar de direção, etc.;
• Resultados de Stakeholders de negócio, como conformidade regulatória, redução de custos de longo prazo, resultados de negócio, tendências de participação de mercado, satisfação do cliente em todos os Produtos, tempo organizacional para entrega, aprendizado ou mudança de direção;
• Resultados do Scrum Team, como melhoria da capacidade técnica (estado de fluxo psicológico (70), frequência de entregas, ferramentas, habilidades, dívida técnica, dívida de UX ou CX, capacidade), clima/cultura para melhoria líquida e inovação.

Dívida de UX (User eXperience) ou CX (Customer eXperience) é a soma das escolhas de design e implementação — intencionais ou não — que tornam um Produto ou serviço menos usável, prazeroso ou eficaz para usuários ou clientes. Reconhecer, acompanhar e tratar essa dívida é essencial para Entregar Produtos que realmente atendam às necessidades e expectativas dos usuários.

Métricas ao longo do tempo tornam transparentes as tendências do Produto, do mercado e dos Stakeholders (incluindo, mas não se limitando, a clientes e usuários); essas métricas podem ser revisadas a qualquer momento durante a Sprint, incluindo na Sprint Review.

Incremento O Incremento é um artefato. É a integração do trabalho concluído de acordo com o padrão definido na Definition of Output Done. O Incremento é uma saída e um candidato a Produto.

Múltiplos Incrementos podem ser criados dentro de uma Sprint por meio da conclusão de Itens do Product Backlog. Cada Incremento é cuidadosamente verificado, utilizável e integrado com todos os Incrementos anteriores. O Incremento agregado resultante é inspecionado o mais rápido possível, no máximo durante a Sprint Review. O Increment deve ser utilizável e útil para viabilizar feedback sobre os resultados. Um Incremento é central no Scrum, pois permite a validação contínua de valor.

Um candidato a Incremento não se qualifica como Incremento até que atenda ao padrão de qualidade definido na Definition of Output Done. Somente um Incremento pode ser lançado. O Incremento deve ser um marco concreto rumo à Meta do Produto. Incrementos podem ser entregues aos Stakeholders ou entregue antes da Sprint Review. A melhor forma de validar valor é por meio de feedback sobre os resultados.

Compromisso: Definition of Output Done A Definition of Output Done é um compromisso. Ela descreve formalmente os critérios de qualidade que representam a diligência devida para que o Incremento possa ser entregue aos Stakeholders.

A Definition of Output Done normalmente inclui (mas não se limita a) padrões técnicos e qualidades do Produto. O Scrum Team a define caso não seja fornecida pela organização como padrão mínimo. Se houver múltiplas Scrum Teams trabalhando no mesmo Produto, elas compartilham a mesma Definition of Output Done como base comum — podendo aprimorá-la.

O Scrum Team tem o dever de seguir a Definition of Output Done e de melhorá-la continuamente. O Incremento é cumulativo. A Definition of Output Done serve ao bem do Produto e dos seus Stakeholders. Ela representa o padrão geral de qualidade para todo o Incremento, e não o padrão específico de cada item (por exemplo, critérios de aceitação).

Um Incremento entregue possibilita o feedback de resultados para a validação de valor da Definition of Outcome Done.

Product Backlog O Product Backlog é um artefato. Trata-se da lista ordenada e emergente de Product Backlog Items necessários para alcançar a Meta do Produto. O Product Backlog proporciona Transparência (clareza sobre o trabalho) e é a única fonte de trabalho para o Scrum Team na busca pela Meta do Produto. O Product Owner, sempre com o valor em mente, orienta a ordenação (sequenciamento) dos Itens do Product Backlog no Product Backlog. Um Product Backlog menor geralmente proporciona mais Transparência.

Item do Product Backlog Um Item do Product Backlog é um item potencialmente valioso no Product Backlog. Ele não precisa estar em um formato específico. Seu objetivo é lidar com um problema ou oportunidade. Pode incluir Critérios de Aceitação (Acceptance Criteria), que indicam quando o trabalho está concluído — além da Definition of Output Done. Pode-se Entregar exatamente o que foi solicitado e, ainda assim, não atingir resultados suficientes. Por isso, um Item do Product Backlog também pode incluir Critérios de Resultado (Outcome Criteria) claramente definidos, que indicam quando valor suficiente foi entregue — além do que já está descrito na Definition of Outcome Done.

Um Item do Product Backlog é uma unidade de trabalho que descobre ou Entrega valor. Pode evoluir a qualquer momento, mesmo enquanto os Desenvolvedores de Produto trabalham nele. Durante o refinamento, é decomposto em Itens do Product Backlog menores e mais compreensíveis (principalmente pelo Scrum Team) que possam Entregar valor. Eventualmente, um item no Product Backlog pode não estar relacionado à Meta do Produto; se isso ocorrer com frequência, vale investigar se o nível de Foco está adequado. O Scrum Team e os Stakeholders devem manter o foco em resultados, não apenas saídas, equilibrar bem os trade-offs, e evitar que a equipe vire uma “fábrica de funcionalidades” ou “fábrica de descobertas”.

Critérios de Aceitação Os Critérios de Aceitação, se existirem, descrevem quando uma saída de um Item do Product Backlog específico está concluída, além da Definition of Output Done. Nos itens refinados, os Critérios de Aceitação devem fornecer clareza inequívoca sobre o que está sendo solicitado. Eles incluem critérios específicos daquele item, que não estão abrangidos pela Definition of Output Done. Podem ser funcionais ou não funcionais, e podem evoluir a qualquer momento, mesmo durante a execução do trabalho pelos Desenvolvedores de Produto. Critérios de Resultado Os Critérios de Resultado, se existirem, descrevem a intenção do Item do Product Backlog — o porquê por trás do o quê. O cumprimento dos Critérios de Resultado geralmente complementa a Definition of Outcome Done do Product. Podem incluir critérios específicos daquele item, que não estão abrangidos pela Definition of Outcome Done. Se surgirem dúvidas, os Critérios de Resultado servem como direcionamento. Podem estar em formato de narrativa ou métricas — sendo estas preferíveis. Assim como os demais, podem evoluir a qualquer momento, mesmo durante a execução do trabalho pelos Desenvolvedores de Produto.

Refinamento Refinamento é uma atividade. Pode ser formal (um evento adicional) ou informal. É um processo emergente e contínuo que promove clareza e reduz riscos; constrói entendimento e confiança suficientes de que os Itens do Product Backlog selecionados ou futuros estão prontos (ou seja, podem ser concluídos conforme a Definition of Output Done em poucos dias ou menos).

O refinamento envolve quebrar Itens do Product Backlog em partes menores e mais compreensíveis (principalmente para o Scrum Team). Também pode adicionar mais detalhes como descrição, Critérios de Aceitação, Critérios de Resultado, ordem e tamanho. Os atributos podem variar, mas devem ser significativos para o Scrum Team. O refinamento pode incluir pesquisa, incluindo mas não se limitando a validação do problema ou oportunidade, experiência do usuário ou cliente, validação da solução. Os Desenvolvedores de Produto — e somente eles — são responsáveis por dimensionar os Itens do Product Backlog. O Product Owner pode influenciá-los, ajudando a entender e selecionar trade-offs potenciais.

Os participantes geralmente incluem Stakeholders e membros do Scrum Team; não é incomum que Desenvolvedores de Produto colaborem diretamente com Stakeholders. O refinamento é frequentemente apoiado ou facilitado pelo Product Owner. Se os Desenvolvedores de Produto tiverem bom entendimento do Produto, o Product Owner pode se concentrar mais em sua responsabilidade principal de Product Ownership. De modo geral, é uma atividade com olhar para o futuro, que oferece clareza, direção e foco potencial para as próximas Sprints.

Compromisso: Meta do Produto A Meta do Produto é um compromisso. Ela é representada por meio do Product Backlog, que é de responsabilidade do Product Owner. É o objetivo atual, mais estratégico e ambicioso — o “porquê”. Ela fornece direção para o Produto e possibilita Foco para os Desenvolvedores de Produto que estão trabalhando nele. Melhora a Transparência ao oferecer uma direção clara e valiosa para que os Desenvolvedores de Produto avancem, utilizando a Meta do Produto como uma tática orientada ao mesmo “porquê”.

A Meta do Produto é o objetivo de médio prazo para o Scrum Team e os Stakeholders (e Apoiadores). O Scrum Team deve concluir (ou abandonar) uma Meta do Produto antes de assumir a próxima.

A Meta do Produto costuma ser uma afirmação ainda não comprovada sobre valor. Pode ser expressa de várias formas, incluindo um conjunto de hipóteses sobre como fechar ou reduzir lacunas de satisfação. Alcança equilíbrio ao focar em um subconjunto das expectativas e limites da multiplicidade de Stakeholders (incluindo, mas não se limitando a, clientes e usuários). Por meio da Inspeção e Adaptação, é essencial abraçar a incerteza (72), feedback de resultados, efeitos colaterais e outros aprendizados.

E quanto à Visão do Produto?

Muitas organizações trabalham com uma Visão de Produto, que ajuda a visualizar um futuro potencial. O Scrum Team pode usar essa visão como insumo para considerar uma Meta do Produto. Uma Visão de Produto representa um conjunto de resultados desejados valiosos de longo prazo. A Meta do Produto, de médio prazo, geralmente funciona como um passo concreto rumo à visão de longo prazo.

À medida que o Scrum Team e os Stakeholders inspecionam e se adaptam em direção à Meta do Produto, eles precisam estar abertos à ideia de que a Visão de Produto ou a própria Meta do Produto também podem precisar se adaptar. Frequentemente, diversas metas do Produto são alcançadas sequencialmente ao longo do caminho rumo à visão.

O ponto essencial é que uma Visão de Produto é, muitas vezes, uma obra de ficção: nada nela pode ser verdade ainda. Formar hipóteses e executar experimentos orientados nessa direção é essencial — e é exatamente onde o Scrum pode agregar mais valor.

Uma Visão de Produto costuma ser inspiradora, mas também pode ser intimidadora. A Meta do Produto reduz essa sobrecarga, atuando como uma fatia vertical mais tangível da visão ou como um facilitador para sua realização.

Sprint Backlog

O Sprint Backlog é um artefato. Ele é composto pela Meta da Sprint (o porquê da Sprint), pelo conjunto de Itens do Product Backlog selecionados (o quê, também conhecido como previsão) para a Sprint, e frequentemente por um plano acionável para Entregar o Incremento (o como). Ele fornece Transparência (clareza sobre o trabalho) ao longo da Sprint.

O Sprint Backlog é um plano feito por e para os Desenvolvedores de Produto. Ele representa a visão dos Desenvolvedores de Produto sobre o trabalho compreendido necessário para alcançar a Meta da Sprint (o porquê da Sprint). Suponha um cenário subótimo onde a maioria dos itens no Sprint Backlog está constantemente desalinhada com a Meta do Produto. Nesse caso, os valores de Foco e Comprometimento do Scrum não estão sendo respeitados.

Dentro do contexto da Meta da Sprint, os Desenvolvedores de Produto atualizam seu plano — inclusive a previsão — ao longo da Sprint, conforme aprendem mais. O Sprint Backlog deve conter trabalho suficiente para dar início à Sprint, por exemplo, começando com um ou dois Itens do Product Backlog voltados à Meta da Sprint. Os Desenvolvedores de Produto inspecionam seu progresso em direção à Meta da Sprint no Daily Scrum ou até com mais frequência. Eles aprendem a se adaptar e responder à incerteza (72).

Compromisso: Meta da Sprint

A Meta da Sprint é um compromisso criado e pertencente ao Scrum Team. É o objetivo único e unificador da Sprint (o porquê) para os Desenvolvedores de Produto, criado durante a Sprint Planning.
A entrega da Meta da Sprint é um compromisso dos Desenvolvedores de Produto. O Sprint Backlog (incluindo o porquê, o quê e, frequentemente, o como) fornece Foco e flexibilidade em relação ao trabalho que evolui, melhorando assim a Transparência.

A Meta da Sprint incentiva o Scrum Team a trabalhar em conjunto, em vez de iniciativas separadas. Se o trabalho acabar sendo diferente do que os Desenvolvedores de Produto esperavam, eles colaboram com o Product Owner para negociar possibilidades dentro da Sprint, sem afetar a Meta da Sprint. Ninguém diz aos Desenvolvedores de Produto como dimensionar ou realizar seu trabalho.

Os Eventos do Scrum no Pacote de Expansão

O Scrum combina quatro eventos com timebox voltados à Inspeção e Adaptação, dentro de um quinto evento de duração determinada, a Sprint. Esses eventos sustentam os pilares do Scrum: Transparência, Inspeção e Adaptação. As Entregas viabilizam a entrega de valor — idealmente, de forma contínua. Entregas infrequentes levam a feedbacks de resultado atrasados.

Um timebox é uma duração máxima estipulada entre o início e o fim de um evento definido — não deve ser confundido com a obrigação de usar todo esse tempo. O propósito de um timebox no Scrum é incentivar a seleção do trabalho essencial, criando Foco para alcançar os resultados desejados rapidamente. No Scrum, para um determinado Scrum Team, o tamanho da Sprint é consistente, portanto não é considerado um timebox.

Os eventos criam cadência e minimizam a necessidade de outras reuniões fora do Scrum. Idealmente, cada evento ocorre no mesmo horário e local, reduzindo a complexidade (30–35) e promovendo a formação de hábitos. A facilitação habilidosa melhora a efetividade. Eventos mal conduzidos colocam em risco o foco na Meta da Sprint, Meta do Produto, Transparência, Inspeção, Adaptação e nos Valores do Scrum.

Cada evento tem seu propósito próprio e deve envolver trabalho profundo e significativo. Juntos, os eventos do Scrum fornecem uma estrutura de Transparência para inspecionar, adaptar, pausar e refletir. Eles apoiam o pensamento estruturado, o trabalho eficaz e uma carga equilibrada.

A comunicação é essencial para garantir que o Scrum Team e os Apoiadores mantenham o Foco no que realmente importa. Com exceção da Sprint, os eventos podem consumir menos tempo, desde que não se perca coerência.

A Sprint

A Sprint é um evento no qual ideias são transformadas em valor. A Sprint é o evento contêiner. Trata-se de uma iteração com tempo determinado, dentro da qual o trabalho é executado. Ela proporciona Foco e estabilidade. Uma Sprint não deve durar mais do que quatro semanas. Uma nova Sprint começa imediatamente após a conclusão da anterior. Todo o trabalho necessário para alcançar a Meta do Produto acontece dentro de Sprints.

As Sprints são o coração do Scrum, onde o Scrum Team transforma ideias em Incrementos usáveis, úteis e potencialmente valiosos. O Incremento deve ser entregue assim que for praticamente possível, considerando a necessidade de obter feedback de resultados antecipado. A ausência de entrega para algum subconjunto de Stakeholders (incluindo, mas não se limitando a, clientes reais, tomadores de decisão e usuários) pode levar à falta de feedback em tempo hábil. Múltiplos Incrementos podem ser criados dentro de uma Sprint; o Scrum Team deve se empenhar em validar valor por meio de entregas antecipadas e frequentes, quando aplicável.

Durante a Sprint:

• Nenhuma mudança é feita que comprometa a Meta da Sprint;
• O(s) Incremento(s) não devem ter redução de qualidade;
• O Product Backlog é refinado conforme necessário; e,
• À medida que mais é aprendido, o trabalho atual pode ser esclarecido e renegociado com o Product Owner, sem afetar a Meta da Sprint.

As Sprints viabilizam resultados ao assegurar Inspeção e Adaptação do progresso em direção à Meta da Sprint pelo menos a cada quatro semanas. Quando uma Sprint é muito longa, a Meta da Sprint pode se tornar inválida, aumentando a complexidade (30–35) e o risco. Sprints mais curtas geralmente geram mais ciclos de aprendizado e também podem limitar riscos.

Sprints mais curtas normalmente exigem capacidades aprimoradas (ex.: refinamento, corte vertical, domínio técnico, domínio de negócio). O contexto importa, e o Scrum Team deve buscar o equilíbrio adequado.

Diversas práticas complementares existem para avaliar ou prever o progresso, como gráficos de burn-down, burn-up, análises de fluxo, previsões probabilísticas com Monte Carlo, estimativas de grande esforço, conjuntos difusos (110), etc. Embora úteis, essas práticas não substituem a importância do empirismo (67). Em ambientes complexos (30–35), o que já aconteceu pode ser usado para tomadas de decisão com visão de futuro, mas o que acontecerá é incerto.

Você pode pensar em uma Sprint como um mini projeto, com resultado claro, duração determinada e custos compreendidos. No entanto, as diversas atividades de trabalho acontecem em paralelo, e não de forma linear e sequencialmente definida.

Uma Sprint pode ser cancelada se a Meta da Sprint se tornar obsoleta. Apenas o Product Owner tem autoridade para cancelar a Sprint. Sprints mais curtas reduzem a probabilidade de cancelamento.

Sprint Planning

A Sprint Planning é um evento. É o primeiro evento da Sprint, onde o Scrum Team estabelece Foco e cria comprometimento.

Durante a Sprint Planning, a Meta do Produto (o porquê do Product Backlog), mais estratégica, é considerada e fornece direção. A partir disso, os Desenvolvedores de Produto criam o Sprint Backlog, que consiste na Meta da Sprint (o porquê da Sprint), de curto prazo e mais tática, no trabalho inicialmente identificado e no plano para Entrega.

A Sprint Planning aborda os seguintes tópicos:

O porquê da Sprint

O Product Owner propõe ideias sobre como o Produto pode aumentar seu valor e utilidade na Sprint atual. O Scrum Team colabora para definir uma Meta da Sprint que comunique por que a Sprint é valiosa para os Stakeholders em direção à Meta do Produto. A Meta da Sprint deve ser finalizada até o fim da Sprint Planning.

O quê em direção ao porquê

Por meio da colaboração com o Product Owner, os Desenvolvedores de Produto selecionam itens do Product Backlog para incluir na Sprint atual. O Scrum Team pode refinar esses itens, o que aumenta o entendimento e a confiança. Os itens selecionados devem ser executáveis de acordo com o padrão da Definition of Output Done, junto com quaisquer outros itens adicionais.

Selecionar quanto pode ser concluído dentro da Sprint pode ser um desafio. No entanto, quanto mais os Desenvolvedores de Produto souberem sobre seu desempenho passado, fatiamento vertical, capacidade futura e a Definition of Output Done, maior será sua confiança na previsão dos resultados da Sprint.

Scrum Teams bem-sucedidas não se sobrecarregam. Na verdade, elas planejam concluir o trabalho antecipadamente, às vezes usando uma margem de segurança para eventos inesperados (85). Isso ajuda a manter o foco, melhorar a qualidade e satisfazer os Stakeholders ao Entregar valor mais cedo. Sobrecarga crônica ou mudanças bruscas podem gerar estresse negativo excessivo, o que Jeff Sutherland chama de “Surpresa Bayesiana” (“Bayesian surprise”). Essas situações podem interromper o estado de fluxo psicológico (70) da equipe e prejudicar seu desempenho. Comunicação clara, tratamento profissional da emergência (71) e pequenas mudanças regulares ajudam a evitar isso. Por isso, os Scrum Teams devem mirar na Entrega antecipada.

O como do quê

Como o trabalho será feito é de responsabilidade exclusiva dos Desenvolvedores de Produto. Ninguém além deles decide como executar o trabalho. Os Desenvolvedores de Produto selecionam o próprio trabalho — ninguém mais atribui ou empurra itens do Product Backlog para eles, nem mesmo o Product Owner.

A Sprint Planning tem timebox máximo de oito horas para uma Sprint de quatro semanas. O evento costuma ser mais curto para Sprints mais curtas. O contexto importa. Mas, como regra geral, planeje o suficiente para dar início ao trabalho, por exemplo, planeje alguns itens do Product Backlog voltados à Meta da Sprint.

Daily Scrum

A Daily Scrum é um evento. Na Daily Scrum, os Desenvolvedores de Produto colaboram sobre o progresso em direção à Meta da Sprint e atualizam o plano acionável — o Sprint Backlog — até a próxima Daily Scrum. Caso a Meta da Sprint já tenha sido alcançada, os Desenvolvedores de Produto colaboram em progresso significativo em direção à Meta do Produto.

O Daily Scrum proporciona Foco, coesão e senso de urgência, além de fomentar a autogestão (49). Geralmente, apenas os Desenvolvedores de Produto participam. Para simplificar, costuma-se manter o mesmo horário, local e cadência de reunião.

Os Desenvolvedores de Produto podem escolher qualquer estrutura e técnicas que desejarem. A Daily Scrum melhora a comunicação voltada à Meta da Sprint, ajuda a identificar e tratar riscos e impedimentos, promove a tomada de decisões rápidas e, consequentemente, elimina a necessidade de outras reuniões.

A Daily Scrum não é o único momento em que os Desenvolvedores de Produto ajustam seu plano para a Sprint no contexto da Meta da Sprint ou da Meta do Produto. Os Desenvolvedores de Produto costumam se encontrar ao longo do dia para discussões mais detalhadas.

Para viabilizar o fluxo de valor (68,69) e permitir que resultados potenciais ocorram mais cedo, os Desenvolvedores de Produto devem focar em um item ou poucos itens por vez e atingir a Definition of Output Done antes de iniciar novos itens. Eles podem alcançar isso mantendo o foco, reduzindo o número de itens em andamento e priorizando a finalização do trabalho em vez de iniciar novos itens. Os Desenvolvedores de Produto monitoram o trabalho parado, e não pessoas paradas.

A Daily Scrum tem um timebox máximo de quinze minutos por dia, podendo ser mais curto.

Sprint Review

A Sprint Review é um evento. Trata-se de uma sessão de trabalho interativa e colaborativa.
Frequentemente, o Scrum Team compartilha a meta atual do Produto e apresenta a Definition of Output Done e a Definition of Outcome Done aos Stakeholders. O Scrum Team compartilha os resultados do trabalho realizado, os trade-offs feitos e quanto progresso foi alcançado em direção à Meta do Produto (o porquê por trás do trabalho). Quando disponíveis, métricas atuais e atualizadas de progresso em direção à Definition of Outcome Done são compartilhadas e consideradas.

A Sprint Review inspeciona muitos aspectos relacionados ao Produto, como a Meta do Produto, o Product Backlog, a Meta da Sprint, os aprendizados, o Incremento, expectativas e limites dos Stakeholders, feedback de resultados, efeitos colaterais, progresso do Produto, o mercado, bem como aspectos voltados para o futuro, como novas ideias e oportunidades que surgiram, possíveis próximos passos.

Com base no que for aprendido:

• Os participantes percebem, escutam, aprendem e colaboram sobre o que pode ser feito a seguir;
• O Product Backlog (o quê) é adaptado, e possivelmente a Meta do Produto, idealmente com apoio de evidências ou observações, e guiado pela Meta do Produto ou por uma Visão de Produto opcional; e,
• Os participantes adaptam a Definition of Outcome Done do Produto para as próximas Sprints.

É sempre importante considerar os Stakeholders e o que eles valorizam, inclusive Stakeholders inanimados ou não humanos, como a lei.

Itens do Product Backlog incompletos retornam ao Product Backlog para consideração futura e não são apresentados; às vezes, eles são movidos para a próxima Sprint.

A Sprint Review é o penúltimo evento da Sprint e possui timebox máximo de quatro horas para uma Sprint de quatro semanas. Para Sprints mais curtas, o evento costuma ser mais curto.

Sprint Retrospective

A Sprint Retrospective é um evento. Nesse evento, o Scrum Team define como irá melhorar.
Premissas equivocadas também são exploradas — ou seja, pressupostos que levaram a equipe na direção errada. Aspectos positivos, como determinadas tecnologias, processos, padrões etc., também podem ser destacados ou reforçados. Os elementos inspecionados geralmente variam conforme o domínio de trabalho. A reflexão é mais eficaz em um ambiente psicologicamente seguro.

A Sprint Retrospective foca nas mudanças mais úteis para promover melhorias, como por exemplo:

• O Incremento
• Os resultados
• O profissionalismo, como: habilidades, práticas técnicas, ferramentas, capacidade de inovar
• O fluxo de valor validado (68,69), como: métricas de fluxo ponta a ponta, tempo de chegada ao mercado
• A efetividade (o como), como: tecnologias, processos, dependências
• As interações e a dinâmica do Scrum Team, como: colaboração, formas de trabalho
• Os information radiators, como: mural do produto, métricas
• A Definition of Output Done para as próximas Sprints
• Adaptações adicionais à Definition of Outcome Done para as próximas Sprints
• Como alcançar automaticamente as medidas associadas à Definition of Outcome Done
• E outros aspectos

As melhorias com maior impacto devem ser tratadas o quanto antes. O Scrum Team não deve apenas falar sobre melhoria — o Scrum depende de ações de melhoria contínua e significativas. Algumas ações de melhoria exigem ajuda dos Apoiadores, mas isso não significa que o Scrum Team deve deixar de buscar melhoria líquida (como ganhos marginais contínuos).

A Sprint Retrospective conclui a Sprint. Ela possui um timebox máximo de três horas para uma Sprint de quatro semanas. Para Sprints mais curtas, o evento costuma ser mais curto.

Produtos com Múltiplos Scrum Teams

Se um Scrum Team se tornar grande demais, deve-se considerar reorganizá-lo em múltiplos Scrum Teams coesos, todos focados no mesmo Produto. Múltiplos Scrum Teams trabalhando no mesmo Produto devem compartilhar a mesma meta do Produto, o mesmo Product Backlog, o mesmo Product Owner, uma Definition of Outcome Done base e uma Definition of Output Done base.

Tenha cuidado com a suposição equivocada de que mais Scrum Teams resultam em mais valor entregue. Escalone apenas se os benefícios superarem claramente o custo adicional. Antes de escalar, a configuração com um único Scrum Team precisa ser capaz de Entregar um Incremento a cada Sprint com confiabilidade. Mas, se for necessário escalar, use uma abordagem coerente com este documento. Frequentemente, menos equipes geram mais resultados.

Em um contexto com múltiplos Scrum Teams, eles podem reduzir dependências entre si tornando-se mais multifuncionais, por meio de colaboração, polinização-cruzada, transferência de aprendizado e interações intencionais. As habilidades específicas necessárias são geralmente amplas e variam conforme o domínio de trabalho. Nesse contexto, interações intencionais e profissionalismo (incluindo integração contínua) se tornam ainda mais importantes.

Na configuração com um Product Owner e um Scrum Team, o Product Owner pode ser um gerente de produto, diretor de marketing, diretor de tecnologia, etc. Em uma configuração com múltiplos Scrum Teams no mesmo Produto, o ideal ainda é ter apenas um Product Owner, que deve ser um líder do Produto. Para conseguir lidar com várias Scrum Teams no mesmo Produto, esse Product Owner tende a se tornar mais estratégico e delegar problemas e oportunidades a serem explorados pelos Desenvolvedores de Produto — incluindo, por exemplo, aspectos de design de Produto ou gestão de Produto.

O Product Backlog é uma ferramenta para aumentar a Transparência.

De forma geral, quanto menos Product Backlogs por Produto — sejam implícitos (como filtros) ou explícitos — melhor: Menos silos no Produto e maior transparência em todo o Produto; Mais transparência no acompanhamento do progresso global do Produto; Maior clareza sobre o valor do Produto como um todo; Maior probabilidade de um Scrum Team perceber que está trabalhando em itens de baixo valor, sob a perspectiva do Produto; Maior probabilidade de melhoria na realização de valor; e O Product Owner se torna mais estratégico, ao delegar o trabalho transversal aos Desenvolvedores de Produto.

Menos Product Backlogs por Produto melhoram a adaptabilidade (80), mas sem uma propriedade empoderada, um escopo de controle coerente ou contato direto com os Stakeholders relevantes, surgirão lacunas. O Scrum fomenta um ambiente de descobertas casuais (happenstance) e multi-aprendizado (multi-learning). À medida que pessoas e Scrum Teams colaboram, descobertas e insights podem ser compartilhados e aproveitados. Isso dificilmente ocorre em um ambiente onde cada componente tem seu Product Backlog isolado.

Descobertas casuais, no contexto de O Novo Novo Jogo de Desenvolvimento de Produto (The New New Product Development Game (29)), refere-se ao fato de que ideias ou soluções úteis podem surgir por acaso, e não apenas por planejamento rigoroso. Quando Scrum Teams trabalham de forma próxima e compartilham informações, novas abordagens ou respostas podem surgir de eventos inesperados.

Multi-aprendizado significa que os membros da equipe aprendem de várias formas ao mesmo tempo. Eles desenvolvem habilidades e conhecimentos não apenas em suas áreas, mas também em outras, aprendem como indivíduos, como grupo e como parte da organização. Isso torna o time mais flexível e apto a resolver uma ampla gama de problemas rapidamente, pois todos aprendem uns com os outros e com a prática compartilhada.

Encontrar o equilíbrio certo é um dilema. Sempre haverá trade-offs a considerar. No entanto, uma boa heurística é: Quanto menos Product Backlogs (explícitos ou implícitos), melhor — e isso é viabilizado pela multi-aprendizagem e pela transferência organizacional de conhecimento entre Scrum Teams, departamentos e Produtos.

Transferência organizacional de conhecimento, como descrito em O Novo Novo Jogo de Desenvolvimento de Produto (The New New Product Development Game (29)), é o processo em que conhecimentos e aprendizados adquiridos em uma área de desenvolvimento de Produto são compartilhados e aplicados em outras áreas ou divisões da organização.

As organizações são frequentemente estruturadas para facilitar a gestão, e não a obtenção de resultados. Pergunte a si mesmo: quantos Scrum Teams precisam estar envolvidos para que um problema ou oportunidade seja transformado em valor? Quanto menor esse número, melhor.

Libere os times do comando e controle. Prefira a autonomia alinhada. Fomente interações intencionais e com propósito, dentro e entre Scrum Teams autogerenciáveis (49). Crie um ambiente de trabalho com processos mínimos porém suficientes, estrutura leve e limites claros. Equilibre e cuide das expectativas e limites dos Stakeholders. Construa capacidade de mudança e melhoria contínua com direção, não apenas Entrega.

Quando em dúvida, estude o O Novo Novo Jogo de Desenvolvimento de Produto (The New New Product Development Game (29)), abrace o que há de bom no presente, mas abandone ideias antigas de um complexo industrial (30–35) onde apenas os mais corajosos têm autonomia para agir.

Nota Final

A adoção do Scrum por Jeff Sutherland em 1993 na Easel foi inspirada pelos artigos de Christopher Langton (36,37) sobre a teoria de Sistemas Complexos Adaptativos (CAS) (74–77) dos Laboratórios de Los Alamos, que demonstram que sistemas evoluem mais rapidamente na borda do caos.

O Scrum é descrito no Guia do Scrum de 2020 (40). O livro A Simple Guide to Scrum de Tobias Mayer (58) é uma versão abreviada e editada do Guia do Scrum oficial, escrito por Ken Schwaber e Jeff Sutherland. O Scrum Hexis (52) expande o Guia do Scrum de 2020 a partir de uma perspectiva de 2025, mas o Guia do Scrum de 2020 ainda é a referência essencial para o Scrum.

O Scrum é como um espelho. Se a imagem no espelho não é a esperada, o espelho deve ser escondido?

Alcance pelo menos um Incremento por Sprint como hábito antes de adaptar o Scrum. Cada parte do Scrum tem um propósito; compreender o porquê de cada parte é essencial. Considere o contexto. O curto prazo diz respeito à Entrega. O longo prazo está relacionado a mudanças emergentes bem-sucedidas em uma direção e à Entrega sustentável de valor. A adoção bem-sucedida do Scrum depende de encontrar o equilíbrio certo entre o curto e o longo prazo.

Tome cuidado ao copiar abordagens de outras organizações sem também fomentar a cultura delas. A mudança emergente na direção do progresso é a mudança. Essa mudança inclui (mas não se limita a) liderança, fluxos de trabalho, processos e sistemas — incluindo RH, Finanças, Compras e outros. O Scrum faz parte de uma expedição contínua e sem fim de melhoria contínua e evolução em uma direção, e não de um destino final.

Agradecimentos

O Scrum foi inspirado pelo Lean (63), pelo Sistema Toyota de Produção (59–60), pelo artigo da Harvard Business Review “The New New Product Development Game”, de Hirotaka Takeuchi e Ikujiro Nonaka (29), e pelo Empirismo na Dupont (61).

O Scrum foi desenvolvido no início dos anos 1990. Ken Schwaber e Jeff Sutherland apresentaram juntos o Scrum pela primeira vez na conferência OOPSLA em 1995 (62). A primeira versão do Guia do Scrum (40) surgiu em 2009. O Scrum está em constante evolução.

Agradecemos também aos revisores que forneceram feedback às versões anteriores deste material, incluindo, mas não se limitando a: Daryn Basson, Alex Benes, Kurt Bittner, Deb Bhattacharya, Magdalena Firlit, Nichervan Fazel, Peter Fischbach, Michael Forni, Tom Gilb, Martin Hinshelwood, Jesse Houwing, Michael Huynh, Matthew Ijogi, Marc Kaufmann, Tom Mellor, Christian Neverdal, Stas Pavlov, Ian Sharp, Alisa Stolze, Mark Summers e Nader Talai.

Scrum Expandido em Uma Página

O Scrum é descrito no Guia do Scrum de 2020 (40). O Scrum é um framework leve para lidar com trabalhos complexos (30–35), especialmente na descoberta, desenvolvimento, Entrega e realização de valor de Produtos. O Scrum baseia-se no controle empírico de processos (decisões informadas por evidências) e no pensamento Lean (redução de desperdícios e foco no fluxo de valor) (63). O Scrum é propositalmente incompleto, guiando interações em vez de prescrever receitas detalhadas.

Por Que Usar Scrum?
O Scrum permite que o Scrum Team identifique, represente ou meça a emergência (71), abrace a incerteza, responda a mudanças, entregue e valide valor frequentemente, e melhore continuamente. O Scrum promove colaboração, responsabilidade e decisões baseadas em evidências, favorecendo os melhores resultados possíveis em ambientes em rápida mudança. Scrum Teams autogerenciáveis, organizados em torno do valor, são essenciais para resolver problemas criativos e aproveitar oportunidades; Scrum Teams não autogerenciáveis dificultam a capacidade de lidar com a complexidade (30–35). Scrum Teams autogerenciáveis não devem ser confundidos com autogerenciamento individual.

Elementos do Scrum

1. Teoria do Scrum: Baseada em três pilares:

• Transparência – Tornar o trabalho e o valor visíveis para Inspeção.
• Inspeção – Avaliar regularmente o progresso e os resultados para Adaptação.
• Adaptação – Ajustar planos com base em percepções e feedbacks.

2. Valores do Scrum:

• Foco, Abertura, Coragem, Compromisso e Respeito viabilizam o trabalho em equipe eficaz e sustentam a confiança.

3. Papéis / Accountabilities:

• Scrum Team – Um time pequeno, autogerenciável, multifuncional e com diversidade cognitiva composto por:
  • Product Owner – Maximiza o valor de longo prazo, engaja Stakeholders e gerencia o Product Backlog.
  • Scrum Master – Guia a adoção do Scrum, remove impedimentos e promove a melhoria contínua.
  • Desenvolvedores de Produto – Entregam Incrementos a cada Sprint por meio de suas capacidades multifuncionais.
• Stakeholder – Entidade, indivíduo ou grupo interessado, afetado ou com impacto sobre entradas, atividades e resultados, com interesse direto ou indireto dentro ou fora da organização, seus Produtos ou serviços.
  • Apoiador, um tipo de Stakeholder – Promove o clima e o ambiente, participando conforme solicitado.
  • IA – Como ferramenta ou possível Desenvolvedor de Produto, mas ainda não é completamente confiável.

4. Eventos e Atividades do Scrum

• O Scrum opera em Sprints (iterações de duração determinada de até quatro semanas) com quatro eventos com tempo fixo (time-boxed):
• Planejamento da Sprint – Define a Meta da Sprint e planeja o trabalho.
• Daily Scrum – Desenvolvedores de Produto se alinham diariamente sobre o progresso em direção à Meta da Sprint ou à Meta do Produto.
• Revisão da Sprint – Inspeciona o Incremento, o valor e o mercado, e adapta o Product Backlog.
• Retrospectiva da Sprint – Reflete e melhora o Scrum Team.
• Refinamento – Esclarece o trabalho selecionado ou futuro, formalmente (como evento opcional) ou informalmente.

5. Artefatos e Compromissos do Scrum

• Produto & Definition of Outcome Done – Produto e resultados valiosos que fornecem evidência de benefícios realizados.
• Incremento & Definition of Output Done – Um candidato a atualização potencialmente valiosa e liberável do Produto.
• Product Backlog & Meta do Produto – Lista ordenada (sequenciada) de trabalhos para alcançar um objetivo estratégico de médio prazo.
• Sprint Backlog & Meta da Sprint – Itens do Product Backlog selecionados e um plano para a Sprint, objetivo de curto prazo.

Registro da Expansão

Adições

• Seção sobre IA
• Seções sobre Scrum Team autogerenciável, Cadência e Profissionalismo
• Seção sobre Emergência, aberta à ideia de que riscos ou variações em relação às expectativas não necessariamente diminuem com o tempo
• Seção sobre Complexidade (30–35) – O caso para o uso do Scrum
• Seções sobre Liderança e Pensamento Sistêmico
• Seções sobre Pensamento de Produto e Descoberta
• Seções sobre Princípios Fundamentais, Pessoas e Mudança
• Seção sobre Produtos com Vários Scrum Teams
• Papel de Stakeholder (incluindo clientes, tomadores de decisão e usuários); Apoiador como um tipo de Stakeholder
• Seções sobre Refinamento e Item do Product Backlog
• Opcional: Visão do Produto, Critérios de Aceitação, Critérios de Resultado
• Definition of Outcome Done, com ênfase adicional na adaptação informada por evidências de resultado
• Definições de Stakeholder, valor, feedback de resultado, entregas, resultados, risco, impedimento e líder
• Análises de fluxo, previsões probabilísticas com Monte Carlo, estimativas em nível elevado, conjuntos fuzzy (todos opcionais)
• Scrum Expandido em uma página
• Necessidade de tornar fluxos de trabalho, designs, processos, sistemas e ambiente de trabalho coerentes com a emergência
• “Ser Product Owner exige fortes habilidades de gestão de Produto e conhecimento do domínio… Um Product Owner que não esteja disposto, pronto ou apto a desenvolver essas habilidades deve deixar o papel de Product Owner.”
• Um Desenvolvedor de Produto que não esteja disposto, pronto ou apto a agir com profissionalismo deve deixar o papel.
• Um Scrum Master que não esteja disposto, pronto ou apto a ser um agente de mudança deve deixar o papel.
• Apêndices: Explicação do tipo Cynefin® – não oficial e não autorizada, Estratégia Emergente, Empresa Adaptativa (80), Executivo ou Membro do Conselho Adaptativo

Sugestões

• Esclarecimento e modificação de responsabilidades ao “abraçar a incerteza” (73)
• De “Scrum é imutável ou simples” para “Scrum está evoluindo”; em alguns casos, suavização da linguagem de “deve” para “deveria”
• Accountability do Product Owner reformulada como papel de Product Owner com accountability; foco na maximização de valor de longo prazo
• Accountability dos Desenvolvedores reformulada como papel de Desenvolvedor de Produto com accountability
• Accountability do Scrum Master reformulada como papel de Scrum Master com accountability; Scrum Master é uma pessoa, não uma IA
• Desenvolvedores de Produto podem ser humanos ou IA, ou assistidos por IA; deve haver pelo menos um humano; mais humanos contribuem para diversidade cognitiva e melhor tratamento da complexidade
• O Scrum Team (não mais apenas os Desenvolvedores) compromete-se com a Meta da Sprint; é importante que o Product Owner esteja focado
• Sprint Backlog voltado à Meta da Sprint ou Meta do Produto, não apenas à Meta da Sprint
• Definição de Produto, menção à estratégia de Produto, roadmaps, modelos de Produto, abordagens orientadas a metas
• Ênfase em aprendizado, feedback de resultado, efeitos colaterais, resultados acima de saídas
• Para preservar o fluxo de valor, itens incompletos do Product Backlog não precisam necessariamente retornar ao Product Backlog
• “Definition of Done” renomeada para “Definition of Output Done”
• Ênfase no ciclo de vida completo do Produto, ciclo de vida completo da funcionalidade e na realização de valor
• Tópicos 1 a 3 do Sprint Planning renomeados para Por Quê, O Quê e Como; Sprint de até 4 semanas (em vez de “até 1 mês”)
• Inclusão de possível revisão adicional do Incremento e dos resultados em ambiente psicologicamente mais seguro durante a Sprint Retrospective
• Maior ênfase de que o Incremento está sempre Pronto; portanto, “Incremento Pronto” é redundante
• Explícito que a Meta do Produto pode ser adaptável (dentro de limites razoáveis)
• De suposição otimista de Entrega de valor para um Foco intencional na realização de valor
• Ênfase em qualidade embutida, clareza, decisões baseadas em dados, interações intencionais, emergência (71), resultados acima de saídas, pausas e reflexões, realização de valor, compreensão do problema ou oportunidade, promoção de ambiente favorável à adoção coerente do Scrum e melhoria contínua com direção
• Redução da ênfase em organizações genéricas, ligando a mudança aos papéis
• Observância mais intencional dos Valores do Scrum, considerando o contexto

Apêndice

Seção 2: Trecho do MORE executive SUCCESS
Título: Trecho do MORE executive SUCCESS
Autor: John Coleman
Fonte: (6)
Licença/Direitos Autorais: CC BY-NC-ND 4.0 , © 2017-2025 Orderly Disruption Limited
Nota: Esta seção está incluída em sua forma original e inalterada, com permissão, sob os termos da licença CC BY-NC-ND 4.0 . Nenhuma alteração foi feita.

A Empresa Adaptativa

É difícil para uma empresa ser adaptativa (80) sem um clima onde palavras e ações estejam alinhadas. Foram estudados mais de oitenta modelos de engajamento. Entre eles, estavam frameworks de escalabilidade ou desescalabilidade, e modelos operacionais de Produto, que podem ser úteis para Produtos com múltiplos Scrum Teams. Os modelos variam entre exagerar e não fazer o suficiente para ajudar a organização de Produto a se tornar mais adaptativa. Não existe uma verdade universal ou uma “zona ideal” livre de contexto.

Dos modelos de engajamento estudados, há diversos concorrentes notáveis, incluindo, mas não se limitando a, Beyond Budgeting, Humanocracy e Sociocracy, que, dependendo do contexto, devem ser explorados. Considere combiná-los entre si e com outras abordagens.

Beyond Budgeting

Beyond Budgeting (15–28, 90–98, 103) é uma filosofia de gestão que rejeita o orçamento anual tradicional e rígido em favor de uma abordagem descentralizada e adaptativa para controle organizacional e gestão de desempenho. É baseada em 12 princípios orientadores — seis focados em liderança e seis em processos de gestão — que promovem a tomada de decisão descentralizada, a transparência, a autonomia das equipes e um forte alinhamento com o valor entregue ao cliente.

Em vez de metas fixas e planos anuais detalhados, Beyond Budgeting incentiva a definição dinâmica de objetivos, o planejamento contínuo e a alocação de recursos com base em necessidades em tempo real, promovendo adaptabilidade e capacidade de resposta em um ambiente de negócios em rápida mudança. Essa abordagem visa empoderar as equipes, estimular a inovação e garantir que as organizações estejam mais preparadas para lidar com a incerteza (72) e a complexidade (30–35). Beyond Budgeting é um nome ruim (pressupõe falsamente que trata apenas de Finanças) e um nome bom ao mesmo tempo (pois de fato vai além do orçamento).

Humanocracy

Humanocracy (2), conforme definida por Gary Hamel, é um modelo de gestão que substitui hierarquias rígidas e controle centralizado por sistemas que maximizam a contribuição e criatividade de cada pessoa. Em uma humanocracy, as organizações existem para servir e empoderar as pessoas, e não apenas tratá-las como recursos para atingir metas corporativas.

Ela se baseia em princípios como propriedade distribuída, meritocracia, abertura, experimentação e senso de comunidade, promovendo autonomia e inovação. A autoridade se baseia na competência, e as decisões são descentralizadas para quem está mais próximo do trabalho. Humanocracy prioriza a confiança, o engajamento e a liberação do potencial humano em vez da conformidade e do controle, visando construir ambientes de trabalho resilientes e inovadores, onde os colaboradores impulsionam mudanças significativas.

Embora modelos como o Rendanheyi da Haier (56, 101) compartilhem os valores de descentralização e empoderamento, humanocracy é uma filosofia mais ampla, centrada na substituição da burocracia por princípios voltados às pessoas, desbloqueando a capacidade e o valor coletivo.

Sociocracy

Sociocracy (1, 11–14) é um sistema de governança que organiza pessoas em círculos autogerenciáveis (49) e toma decisões por consentimento, e não por maioria de votos. Desenvolvida por Gerard Endenburg (81) nos Países Baixos na década de 1970, ela garante que todos os afetados por uma decisão tenham voz, com propostas avançando a menos que haja uma objeção fundamentada. Guiada pelo princípio de “bom o suficiente por agora, seguro o suficiente para tentar”, sociocracy distribui autoridade, promove transparência, responsabilidade e melhoria contínua, além de fomentar colaboração e senso de pertencimento. Seus princípios influenciaram modelos como Holacracy e equipes autogerenciáveis.

A variante mais consolidada é o Método da Organização Sociocrática por Círculos (Sociocratic Circle-Organization Method – SCM), o método original e formalizado. O SCM utiliza círculos semi-autônomos, ligação dupla (onde duas pessoas participam de dois círculos diretamente relacionados para conectá-los), tomada de decisão por consentimento e eleições abertas para papéis. Essa estrutura mantém tanto a eficiência organizacional quanto a equivalência entre membros, e tem um histórico bem documentado em empresas, cooperativas e escolas nos Países Baixos.

Embora variantes mais recentes como a Sociocracy 3.0 (S3) ofereçam mais flexibilidade, o SCM continua sendo a forma mais historicamente validada e amplamente documentada de sociocracy.

The Adaptive Executive or Board Member

MORE Executive SUCCESS identifica diversas oportunidades para executivos e membros do conselho:

• Adquirir conhecimento sobre os stakeholders (incluindo o cliente) e suas necessidades e limites, o trabalho, como o trabalho funciona, os desperdícios, os antipadrões, o espaço do problema, as oportunidades, as evidências de que o valor pode ser colhido, comportamentos e hábitos
• Promover um clima de desempenho humano e possibilitar um planejamento sucessório que o proteja e o aprimore
• Desenvolver capacidade de resposta e fluxo (68,69) ao longo das redes de valor
• Nutrir a emergência (71) e a adaptabilidade (80) em uma direção com clareza
• Engajar pessoas, incluindo clientes e colegas
• Promover um planejamento sucessório eficaz e oportuno

Há abundante orientação para quem está na base estrutural da organização, no meio e nas laterais, sobre como melhorar a adaptabilidade (80). O nível executivo, no entanto, é mal servido com orientações sobre efetividade humana oportuna, interações com clientes e “como o trabalho funciona”. Há a falsa percepção de que agentes de mudança contratados preencherão essa lacuna sozinhos, o que é irrealista, pois a organização é quem detém a mudança.

A efetividade humana oportuna deve permear toda a estrutura corporativa para gerar seus inúmeros benefícios. Mesmo organizações que “tiveram sucesso na adoção da mudança” enfrentam riscos. Pessoas saem, outras perspectivas ganham espaço, e modismos corporativos podem desmantelar os ganhos em adaptabilidade. Pode surgir um caos negativo.

Muitos atores e modelos de engajamento afirmam apoiar a adaptabilidade executiva, o que é excelente, pois diferentes contextos organizacionais exigem abordagens distintas. Mas, com todos os recursos disponíveis, o panorama geral da adaptabilidade executiva pouco mudou nos últimos 25+ anos.

Seja utilizando táticas, estratégias, métodos e frameworks ou nenhum deles, as organizações devem primeiro adotar o ethos que fundamenta a ambidestria, a efetividade humana, a adaptabilidade e a oportunidade no topo. Caso contrário, executivos e membros do conselho continuarão supervisionando “teatros de mudança” e um mosaico incompleto de bolsões oportunos, humanos e eficazes dentro das organizações.

Shining a Light on Executive Behavior

A postura ou as ações de executivos e membros do conselho influenciam mais o novo comportamento dos outros do que qualquer palavra ou diretiva que emitam. No entanto, seria ideal revisar as perguntas feitas para melhorar a ambidestria, a efetividade humana, a adaptabilidade e a oportunidade.

Ambidestria, efetividade humana, adaptabilidade e oportunidade exigem a extinção eventual de comportamentos executivos incoerentes. Exemplos de comportamentos mais úteis incluem: aceitar falhas, buscar informações antes de julgar, oferecer oportunidades para experimentar algo novo e aprender, tornar aceitável não saber algo, e ajudar as pessoas a manterem o foco. Existem algumas opções notáveis para lidar com o comportamento executivo.

Immunity To Change®

Lisa Laskow Lahey e Robert Kegan (fundadores da The Developmental Edge) criaram uma abordagem de mudança conhecida como Imunidade à Mudança® (3,4). Muitas vezes, as pessoas sabem o que fazer, mas não o fazem por causa de compromissos internos conflitantes. Metaforicamente, têm “um pé no acelerador e um pé no freio”.

Imunidade à Mudança® é uma estrutura para definir esses “compromissos ocultos” e “suposições limitantes” que impedem as pessoas de mudar e alcançar seus objetivos. A teoria e o mapa da Imunidade à Mudança® ajudaram inúmeros profissionais e organizações a descobrir e superar os compromissos que bloqueavam seu crescimento profissional e organizacional.

Liderança Baseada em Intenção®

Liderança Baseada em Intenção® (IBL) (7, 8, 9) é uma linguagem utilizada por equipes de alto desempenho que substitui a linguagem programada da era industrial. A IBL enfatiza o conceito de intenção tanto por parte dos líderes quanto da equipe. É baseada nos livros Turn the Ship Around e Leadership is Language, de L. David Marquet.

Uma das crenças centrais é que liderança não é apenas para alguns poucos no topo. Em organizações altamente eficazes, existem líderes em todos os níveis. L. David Marquet moldou a liderança que desenvolveu no submarino nuclear USS Santa Fe em um sistema chamado Liderança Baseada em Intenção para que organizações apliquem e promovam o pensamento e a liderança em todos os níveis.

A Liderança Baseada em Intenção ajuda líderes a construir organizações onde as pessoas dão o seu melhor porque têm senso de autonomia, ativam sua motivação intrínseca, sentem-se ouvidas e têm impulso por excelência. Sentem altos níveis de propriedade e controle, envolvendo suas emoções e raciocínio. Obtêm recompensas psicológicas ao ver os frutos de suas decisões e trabalhos. Há um viés para a ação, e as equipes tornam-se mais ágeis e resilientes, pois a criação e propagação de erros são reduzidas.

A prática de declarar intenções permite que as equipes tomem decisões de forma distribuída enquanto mantêm a unidade de esforço. O site Intent-Based Leadership International (IBLI) oferece consultoria, mentoria, cursos online e livros para líderes.

Seção 3: Explicação Tipo Cynefin Framework (não oficial e não autorizada)
Título: Explicação Tipo Cynefin Framework (não oficial e não autorizada)
Fonte: Link para o Cynefin wiki original , [Link para esta adaptação]
Licença: Creative Commons Atribuição-CompartilhaIgual 4.0 Internacional ( CC BY-SA 4.0 ). © 2017–2025 Cynefin.io.
Aviso legal: Nenhuma garantia é fornecida. Use por sua conta e risco.
Esta seção é oferecida sob a licença Creative Commons Atribuição-CompartilhaIgual 4.0 Internacional.
Ao utilizar esta Explicação Tipo Cynefin Framework (não oficial e não autorizada), você concorda com os termos da licença CC BY-SA 4.0 .

Cynefin®

Cynefin® (30-35) oferece uma bússola para a tomada de decisão em liderança. Foi popularizado pelo artigo da Harvard Business Review “A Leader’s Framework for Decision Making”, de Dave Snowden e Mary Boone, em 2007, e novamente em “Managing complexity (and chaos) in a crisis – a field guide for decision makers inspired by the Cynefin framework”, também conhecido como o “Guia de Campo da UE”. Sua premissa é que se deve agir de forma diferente dependendo da dinâmica do espaço. Frequentemente, é excessivamente simplificado. Um dado problema pode existir em todos os domínios simultaneamente, cada qual com diferentes aspectos.

Mudança de fase refere-se a uma transição frequentemente abrupta entre domínios, especialmente do ordenado para o caótico, desencadeada quando as restrições de um sistema (regras, hábitos, limites e feedback) estão desalinhadas ou colapsam. Ela marca uma mudança fundamental no comportamento do sistema, onde métodos anteriores de controle ou compreensão deixam de funcionar.

Nem todos os aspectos do desenvolvimento de Produto são complexos. O Scrum Team, para uma determinada situação, pode precisar considerar uma variedade de mudanças de fase entre:

• Ordenado: Ideia-chave: Estabilidade, rotina, boas práticas, especialização

  • A especialização é suficiente e causa e efeito são previsíveis ou compreensíveis
  • Respostas possíveis: aplicar boas práticas, seguir regras, usar análise especializada, realizar pesquisa individual
  • Metáforas: cubo de gelo rígido ou pouco congelado, clima agradável, xadrez ou sudoku
  • Exemplo na natureza: Estufa moderna com controle climático – crescimento previsível, controlado e planejado
  • Exemplo de Produto: Resolver um problema técnico complexo consultando especialistas e analisando logs

• Complexo (30-35), onde a especialização é valiosa, mas não suficiente. Só é possível entender por que algo aconteceu depois do fato. Ideia-chave: emergência, experimentos seguros para falhar

  • Respostas possíveis:
    • Estimular aprendizagem e adaptação
    • Tentar vários experimentos pequenos, paralelos e seguros para falhar
    • Estimular o pensamento novo por meio de diversidade cognitiva e colaboração
    • Adaptar soluções de outros contextos, se puderem ajudar
    • Testar palpites inteligentes ou intuições para ver o que funciona
  • Tudo isso seguindo diretrizes úteis que encorajam o surgimento de bons resultados
  • Metáforas: água fluindo, clima chuvoso, ou pôquer
  • Exemplo na natureza: moita espinhosa – tudo entrelaçado, conexões imprevisíveis
  • Exemplo de Produto: Experimentar diferentes funcionalidades com base em feedback de usuários, ex.: A/B testing de novas ideias de Produto

• Caótico:

  • Negativo – Ideia-chave: Crise destrutiva, colapso, ação urgente
    • Respostas possíveis: agir imediatamente para restaurar a ordem, priorizar a segurança, fazer algo rapidamente sem piorar a situação
    • Metáforas: gelo estilhaçando ou explosão descontrolada, gás tóxico, tornado, terremoto, incêndio florestal ou tumulto em estádio
    • Exemplo na natureza: desastre natural (ex.: tsunami) – súbito, destrutivo e imprevisível
    • Exemplo de Produto: Responder a uma violação crítica de segurança isolando sistemas e aplicando correções emergenciais
  • Positivo – Ideia-chave: Disrupção geradora, inovação rápida
    • Respostas possíveis: provocar disrupção intencional, estimular criatividade, canalizar energia, ex.: hackathon, incubadora, “Sexta-feira da Inovação”
    • Metáforas: explosão controlada (motor a vapor), fogos de artifício ou fogueira de festival
    • Exemplo na natureza: incêndio florestal limpando vegetação antiga para novos crescimentos – renovação do ecossistema
    • Exemplo de Produto: Mudar rapidamente o Produto durante uma disrupção de mercado para aproveitar novas oportunidades (ex.: lançar uma funcionalidade em resposta a um movimento de concorrente)

Liminaridade é o estado “entre”, como um limiar. As mudanças de fase menos abruptas ocorrem nos liminais:

• No liminal entre complexo e ordenado, é o ponto doce padrão do Scrum:

  • Ordenado–Complexo:

    • Da análise especializada para a exploração adaptativa
    • Respostas possíveis: relaxar algumas regras, introduzir experimentação, preparar para emergência
    • Metáforas: cubo de gelo derretendo, tempo nublado, trocar xadrez por pôquer
    • Exemplo na natureza: degelo sazonal – gelo rígido cedendo a riachos e novos crescimentos
    • Exemplo de Produto: Quando um processo rotineiro deixa de funcionar, incentivar o time a experimentar diferentes abordagens

  • Complexo–Ordenado:

    • Respostas possíveis: transformar descobertas criativas em rotinas especializadas; estabilizar a inovação; observar e codificar padrões de sucesso; transição para padronização
    • Metáforas: lama (entre gelo e água), névoa dissipando após chuva, trocar pôquer por xadrez
    • Exemplo na natureza: delta de rio formando canais – de fluxos imprevisíveis a estáveis
    • Exemplo de Produto: Transformar uma funcionalidade experimental bem-sucedida em um processo documentado e repetível

• No liminal entre complexo e caótico:

  • Complexo–Caótico (positivo):

    • Quando é necessário relaxar restrições para criar espaço e tempo para inovação
    • Respostas possíveis: afrouxar restrições, estimular experimentação, buscar ideias inovadoras
    • Metáforas: água fervendo (na beira do vapor), tempestade elétrica, improviso teatral ou jam session de jazz
    • Exemplo na natureza: vulcão criando nova terra – transformação criativa na beira do caos
    • Exemplo de Produto: Hackathon de alto risco para gerar ideias disruptivas

  • Complexo–Caótico (negativo):

    • Ideia-chave: Mergulho destrutivo na crise
    • Respostas possíveis: restabelecer rapidamente as restrições, estabilizar a situação, evitar colapso adicional
    • Metáforas: panela de pressão explodindo, tornado súbito ou enchente relâmpago, peças de jogo jogadas com raiva, tabuleiro virado
    • Exemplo na natureza: deslizamento de terra súbito – perda de estrutura, transição destrutiva
    • Exemplo de Produto: Confusão após lançamento de Produto malsucedido, necessidade urgente de retomar o controle

  • Caótico–Complexo: Saída do caótico – reagrupamento

    • Respostas possíveis: identificar ordem emergente, começar a explorar, estimular colaboração e reconhecimento de padrões
    • Metáforas: vapor condensando em água, calmaria após furacão, reinício de jogo esportivo após tempestade
    • Exemplo na natureza: espécies pioneiras colonizando após incêndio – novo crescimento após distúrbio
    • Exemplo de Produto: Após uma crise, reagrupamento do time para experimentar novas formas de trabalho ou direções de Produto

• Aporia (liminal paradoxal): sentar com o paradoxo em busca de nova percepção, talvez após perceber que a situação não era o que parecia

  • Respostas possíveis: sustentar a ambiguidade, estimular reflexão, permitir que nova compreensão emerja
  • Metáforas: ponto triplo (sólido, líquido e gasoso coexistem), estar no olho do furacão, resolver um enigma
  • Exemplo na natureza: estuário onde rio, mar e terra se encontram – todos os estados e possibilidades coexistem
  • Exemplo de Produto: O time está preso entre estratégias ou visões conflitantes e deve pausar brevemente para refletir e se realinhar

• Fase pouco discutida devido ao seu nível de dificuldade: liminal Caótico–Ordenado

  • Respostas possíveis: impor restrições fortes, restabelecer regras e estrutura
  • Metáforas: gelo se recongelando rapidamente, onda de frio após tempestade, árbitro firme após o caos
  • Exemplo na natureza: represa construída após enchente – um rio selvagem contido e controlado
  • Exemplo de Produto:
    • Após uma grande falha ou crise de Produto, uma equipe de crise multifuncional estabiliza rapidamente a situação com regras mínimas claras e protocolos temporários
    • Após o perigo imediato, essas regras são refinadas iterativamente até se tornarem processos sustentáveis e equilibrados, evitando correções exageradas ou burocracia excessiva

Uma mudança de fase particularmente súbita e negativa, ou seja, um liminal Ordenado–Caótico:

• Respostas possíveis: reconhecer fragilidade e excesso de confiança, agir rápido para restaurar limites e segurança
• Metáforas: gelo se partindo em estilhaços, tempestade de granizo violenta e repentina, regras do jogo subitamente ignoradas
• Exemplo na natureza: lago congelado rachando na primavera – superfície estável se rompe de repente
• Exemplo de Produto: Um processo de Produto estável quebra repentinamente por causa de um evento inesperado (ex.: grande interrupção no sistema)

[Seção 4: Estratégia Emergente
Autor: Roger L. Martin, Tom Gilb
Fonte: (41–48)
Direitos Autorais: Todos os direitos reservados. Adaptado

Estratégia Emergente

A estratégia não está limitada à escala; se ela existir, deve ser claramente articulada nos níveis corporativo, da unidade de negócio ou do Produto, mantendo-se coerente e integrada entre esses níveis. Crucialmente, a estratégia deve distinguir entre fins (resultados quantificados e valorizados pelos Stakeholders) e meios (iniciativas ou atividades).

Inspirando-se e adaptando o trabalho de Roger L. Martin (41) e Tom Gilb (43–48), a estratégia trata de fazer escolhas integradas e explícitas — decidir o que buscar (e o que não buscar) a partir de uma aspiração vencedora bem definida e mensurável, e não apenas de uma missão ou visão genérica. Uma estratégia eficaz responde:

• Onde vamos atuar?
• Como vamos vencer de forma ética (57) e sustentável, equilibrando múltiplas expectativas e limites?
• Quais capacidades e sistemas precisam estar em funcionamento?
• O que mais precisa ser verdade para que essa estratégia funcione?

Para situações em que a expertise sozinha é suficiente (ou quase suficiente), a fim de garantir que a estratégia seja iterativa, executável e focada em valor:

• Quantifique e gerencie iterativamente o valor para os Stakeholders, múltiplos impactos ou efeitos colaterais, riscos e trade-offs:
  • Identifique todos os Stakeholders críticos (incluindo, mas não se limitando a clientes) e defina seus objetivos de valor em termos mensuráveis (ex.: “reduzir o tempo de onboarding de novos usuários de 5–10 para 2–4 dias”).
  • Quantifique explicitamente os trade-offs e restrições, e revise essas informações à medida que surgirem novos dados.
  • Use o pensamento integrativo para resolver tensões de forma criativa.
• Co-crie e priorize colaborativamente:
  • Desenvolva a estratégia combinando insights top-down e bottom-up, e colaboração lateral.
  • Utilize workshops estruturados e ciclos de feedback para promover alinhamento e adaptabilidade, e repriorize continuamente o trabalho ainda não iniciado.
• Entregue valor incrementalmente e meça os resultados:
  • Desdobre iterativamente aspirações estratégicas em incrementos pequenos, priorizados e mensuráveis.
  • Entregue valor em ciclos curtos (ex.: Sprints ou semanas), medindo os resultados reais e efeitos colaterais em relação aos objetivos originais.
  • Use revisões regulares para ajustar-se com base no feedback do mundo real.
• Permita a emergência:
  • Permita que a estratégia evolua em resposta a novos dados e feedback dos Stakeholders (incluindo, mas não se limitando a usuários), dentro de um arcabouço de objetivos claros e quantificados, tendências mensuráveis e reavaliações regulares de riscos e benefícios.
  • Realize correções de rota de forma rápida e transparente à medida que a realidade se revela.
• Garanta que a estratégia e sua implantação estejam orientadas a resultados e foco (decidindo o que fazer e o que não fazer). Distinguir entre:
  • Estratégia: incluindo intenção, justificativa, objetivos e anti-objetivos (o “o que” e o “por quê”)
  • Implantação da estratégia: operacionalização da estratégia, sequenciamento iterativo ou decomposição de escolhas integradas, geralmente em pequenos blocos orientados a resultados
  • Itens do Product Backlog orientados a resultados e com foco (blocos menores: o “para quem”)
  • Listas de atividades ou iniciativas (o “o que faremos” ou “como faremos”)
• Evite confundir uma coleção de projetos com uma estratégia coerente e orientada por valor.

Para situações em que a expertise é valiosa mas insuficiente, a causa e efeito só fazem sentido em retrospectiva, e é necessário abraçar a incerteza, o Scrum Team e os Stakeholders devem:

• Abraçar a complexidade do trabalho emergente e menos estruturado, com foco em uma direção de viagem.
• Reconhecer que planos detalhados e de longo prazo são ineficazes. Em vez disso, devem criar condições para que padrões úteis e inovações surjam das interações do sistema.
• Em vez de testar uma ideia de cada vez ou repetir o que funcionou antes, considerar a execução de vários pequenos experimentos paralelos, seguros para falhar, e aprender com o que emergir.
• Promover um clima de exploração criativa, inovação e evolução a partir do presente. Criar processos e ambientes que permitam a conexão de ideias novas, aprendizados, intuições informadas e trocas de experiências — em vez de impor uniformidade ou KPIs rígidos.
• As opções de resposta incluem, mas não se limitam a:
  • Mapear o que já é conhecido e compreender o potencial evolutivo do sistema antes de tentar mudanças
  • Estimular a auto-organização
  • Conduzir experimentos seguros para falhar — pequenos, paralelos, com falhas suportáveis e informativas
  • Buscar novos pensamentos
  • Tentar soluções pensadas para outros problemas na situação atual
  • Testar intuições informadas
  • Observar o que emerge, amplificando os padrões bem-sucedidos e enfraquecendo ou interrompendo os que não funcionam
  • Reutilizar soluções comprovadas para problemas recorrentes
  • Fazer sense-making continuamente
  • Realizar captura narrativa

Metáfora: O papel das lideranças é preparar e gerenciar ativamente o solo, os limites e as condições (o “substrato”) para favorecer o crescimento de plantas saudáveis (soluções emergentes). Isso inclui, metaforicamente, capinar, podar e moldar o ambiente, e não apenas esperar passivamente pelos resultados.

Geralmente, recompensas baseadas em motivação extrínseca devem ser evitadas, devido ao “efeito da cobra” (104), exceto quando coerentes com o Beyond Budgeting. Da mesma forma, o desempenho individual ou da equipe deve ser desvinculado dos resultados, pois: os resultados podem ter sido alcançados, mas como eles foram entregues? Com quais efeitos colaterais? Que impacto isso teve na moral da equipe?

Ainda assim:

• Há divergência na literatura revisada por pares (105–108) e em um artigo fundamental não revisado por pares (109) sobre se a quantificação das expectativas, limites ou objetivos dos Stakeholders é útil ou prejudicial, e se ela reduz a motivação intrínseca.
• Considere o contexto. Reflita também se a quantificação apoia a autonomia e o propósito, ou impõe restrições controladoras.
• Por ora, este documento prefere errar pelo lado da clareza e do entendimento compartilhado de uma ideia, quantificando as expectativas dos Stakeholders, os limites e a direção de viagem — apoiando-se em narrativas bem contadas e precisas (mais histórias como esta, menos histórias como aquela).

Uma Estratégia Emergente é sustentada por um roteiro emergente orientado a resultados, que pode ir desde a Meta da Sprint até a Visão do Produto e além. A Implantação de Estratégia Emergente (120–123) não deve ser confundida com a Estratégia Emergente em si. Modelos de mudança vetorial (30–35, 54), Modelos Operacionais de Produto (113–119), modelos de scaling e descaling (134–147) e modelos emergentes orientados a objetivos (120–133) podem ser altamente benéficos para a implantação da estratégia emergente. Priorize modelos coerentes com mudança vetorial — isto é, direção de viagem ao invés de metas fixas.

Implantar uma estratégia emergente significa permitir que planos e ações se desenvolvam naturalmente à medida que o Scrum Team e os Stakeholders respondem a mudanças do mundo real. Em vez de seguir um caminho fixo, eles prestam atenção ao que está acontecendo ao redor e ajustam a rota conforme necessário. Com o tempo, os passos dados formam um padrão que se torna a estratégia real — mesmo que diferente do que foi originalmente planejado.

Attribution for the Scrum Guide Expansion Pack Collection

Esta coleção foi escrita e compilada por Ralph Jocham, John Coleman e Jeff Sutherland. Cada seção está atribuída individualmente acima e mantém sua licença original. A coleção como um todo tem finalidade informativa; por favor, respeite os termos de licença de cada seção

References

1. Rau, T. (2022) Sociocracy - Basic Concepts and principles, Sociocracy For All. At: https://www.sociocracyforall.org/sociocracy/ (Accessed: April 5, 2023).
2. Hamel, G. and Zanini, M. (2023) Humanocracy. At: https://www.humanocracy.com/ (Accessed: April 5, 2023).
3. Kegan, R. and Laskow Lahey, L. (2019) An everyone culture, The Developmental Edge. At: https://developmentaledge.com/an-everyone-culture/ (Accessed: April 4, 2023).
4. Laskow Lahey, L. and Kegan, R. (2023) News & thinking, The Developmental Edge. At: https://developmentaledge.com/newsthinking/#methodologies (Accessed: April 3, 2023).
5. Moore, G.A., 1991. Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers. New York: Harper Business.
6. Coleman, J., (2025) MORE executive SUCCESS. Unpublished.
7. Marquet, L. D. (2013) Turn the Ship Around! A True Story of Turning Followers into Leaders. Portfolio.
8. Marquet, L.D. (2021) Leadership is language: The hidden power of what you say and what you don’t. Nakskov, Denmark: Nota.
9. Marquet, L. D. (2021) Based Leadership® International with L. David Marquet - IBLI. At: https://davidmarquet.com/ (Accessed: April 5, 2023).
10. Rau, T.J. and Koch-Gonzalez, J. (2018) Many voices one song: Shared power with sociocracy. Amherst, MA: Sociocracy for All.
11. Buck, J. & Endenburg, G. (2012) The creative forces of self-organization. Sociocratic Center.
12. Buck, J. & Villines, S. (2017) We the people: Consenting to a deeper democracy. 2nd edn. Sociocracy.info Press.
13. Endenburg, G. (1998) Sociocracy: The organization of decision-making. Delft: Eburon Publishers.
14. Priest, J. & Bockelbrink, B. (2018) Sociocracy 3.0 – The practical guide. Available at: https://sociocracy30.org/ (Accessed: 17 May 2025).
15. Bogsnes, B. (2023) This is beyond budgeting: A guide to more adaptive and human organizations. Hoboken, NJ: John Wiley & Sons, Inc.
16. Bogsnes, B. (2023) Beyond budgeting at 25 - bbrt.org , Beyond Budgeting Round Table. At: https://bbrt.org/wp-content/uploads/bb-white-paper_a.pdf (Accessed: April 7, 2023).
17. Olesen, A. (2016) Beyond budgeting: Principle 1 - purpose, YouTube. At: https://youtu.be/_9ZW2NjyFxE (Accessed: April 7, 2023).
18. Larsson, D. (2016) Beyond budgeting: Principle 2 - values, YouTube. At: https://youtu.be/pl1BPrITbm4 (Accessed: April 7, 2023).
19. Player, S. (2016) Beyond budgeting: Principle 3 - transparency, YouTube. At: https://youtu.be/Mb7K8App2vw (Accessed: April 7, 2023).
20. Röösli, F. (2016) Beyond budgeting: Principle 4 - Organization, YouTube. At: https://youtu.be/i8HIgc8OZYM (Accessed: April 7, 2023).
21. Larsson, D. (2016) Beyond budgeting: Principle 5 - autonomy, YouTube. At: https://youtu.be/ipnjHtXYi-g (Accessed: April 7, 2023).
22. Player, S. (2016) Beyond budgeting: Principle 6 - customers, YouTube. At: https://youtu.be/_6fut4R_wVw (Accessed: April 7, 2023).
23. Bogsnes, B. (2016) Beyond budgeting: Principle 7 - rhythm, YouTube. At: https://youtu.be/rb_NsnPNIQQ (Accessed: April 7, 2023).
24. Röösli, F. (2016) Beyond budgeting: Principle 8 - targets, YouTube. At: https://youtu.be/up3mp7jN6XU (Accessed: April 7, 2023).
25. Player, S. (2016) Beyond budgeting: Principle 9 - plans and forecasts, YouTube. At: https://youtu.be/OWM7FUuXejI (Accessed: April 7, 2023).
26. Olesen, A. (2016) Beyond budgeting: Principle 10 - resource allocation, YouTube. At: https://youtu.be/mPCYHmvi_b8 (Accessed: April 7, 2023).
27. Bogsnes, B. (2016) Beyond budgeting: Principle 11 - performance evaluation, YouTube. At: https://youtu.be/RfPVtG2B27E (Accessed: April 7, 2023).
28. Röösli, F. (2016) Beyond budgeting: Principle 12 - rewards, YouTube. At: https://youtu.be/ETU5TzNYiC0 (Accessed: April 7, 2023).
29. Takeuchi, H. and Nonaka, I. (2014) The new new product development game, Harvard Business Review. At: https://hbr.org/1986/01/the-new-new-product-development-game (Accessed: 21 January 2024).
30. Cynefin.io , V. (2022) Cynefin wiki, Cynefin.io . Cynefin.io . At: https://cynefin.io/ (Accessed: April 4, 2023).
31. Rancati, A. and Snowden, D. (2021) Managing complexity (and chaos) in a crisis - a field guide for decision makers inspired by the Cynefin framework. Luxembourg, Belgium: Publications Office of the European Union.
32. Snowden, D. et al. (2022) Cynefin® weaving sense-making into the fabric of our world. 2nd edn. Edited by R. Greenberg and B. Bertsch. Singapore, Singapore: Cognitive Edge - The Cynefin Co.
33. Snowden, D. (2023) Cynefin St David’s 2023 1 of 2, Cynefin Co. https://thecynefin.co/cynefin-st-davids-2023-1-of-2/ (Accessed: April 20, 2023).
34. Snowden, D. (2023) Managing for emergence through abduction, The Cynefin Co. At: https://thecynefin.co/managing-for-emergence/ (Accessed: June 24, 2023).
35. Snowden, D. and Smith, N. (2023) Leadership discussion: Dave and Natalie - the Cynefin co, YouTube. At: https://youtu.be/WcPZ8ybDF0w (Accessed: April 7, 2023).
36. Langton, C.G. (ed.) (1989) Artificial Life: Proceedings of an Interdisciplinary Workshop on the Synthesis and Simulation of Living Systems, Los Alamos, New Mexico, September 1987. Santa Fe Institute Studies in the Sciences of Complexity, vol. VI. Redwood City, CA: Addison-Wesley.
37. Langton, C.G. (1989) ‘Life at the edge of chaos’, in Langton, C.G. (ed.) Artificial Life: Proceedings of an Interdisciplinary Workshop on the Synthesis and Simulation of Living Systems. Santa Fe In stitute Studies in the Sciences of Complexity, vol. VI. Redwood City, CA: Addison-Wesley, pp. 41–91.
38. Wolfram, S. (2002) A new kind of science. Champaign, IL: Wolfram Media.
39. Alexander, C. (1979) The timeless way of building. New York: Oxford University Press.
40. Schwaber, K. & Sutherland, J. (2020) The Scrum Guide: The definitive guide to Scrum: The rules of the game. Available at: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf (Accessed: 17 May 2025)
41. Martin, R.L. (2022) A new way to think your guide to Superior Management Effectiveness. Boston, MA, MA, USA: Harvard Business Review Press.
42. Gilb, T. & Graham, D. (1993) Software Inspection. Harlow: Addison-Wesley.
43. Gilb, T. (1988) ‘Deeper perspectives on evolutionary delivery, in Principles of Software Engineering Management. Wokingham: Addison-Wesley, pp. [chapter 15]. Also available at: https://bit.ly/TomGilbEvo .
44. Gilb, Tom & Maier, Mark. (2005). Managing Priorities: A Key to Systematic Decision Making. INCOSE International Symposium. 15. 10.1002/j.2334-5837.2005.tb00782.x. Also available at: https://bit.ly/TomGilbPriorities .
45. Gilb, T. (1988) ‘Deeper perspectives on evolutionary delivery’, in Principles of Software Engineering Management. Wokingham: Addison-Wesley, pp. [chapter 15].
46. Gilb, T. (2005) Competitive Engineering: A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. Oxford: Elsevier Butterworth-Heinemann. Also available at: https://bit.ly/TomGilbCompEng .
47. Gilb, T. (2009) ‘Agile specification quality control: Shifting emphasis from cleanup to sampling defects’, Testing Experience, March. Available at: https://www.researchgate.net/publication/294196272_Agile_specification_quality_control [Accessed: 17 May 2025].
48. Gilb, T. & Gilb, K. (1989) ‘The McDonnell-Douglas case study of SQC and engineering improvement: Case DAC Inspection 1988–89’. Available at: https://bit.ly/TomGilbMcDonnell-Douglas [Accessed: 17 May 2025].
49. LeSS.works (n.d.) Self-managing teams. Available at: https://less.works/less/management/self-managing-teams (Accessed: 17 May 2025).
50. Gothelf, J. & Seiden, J. (2021) Lean UX: Designing great products with agile teams. 3rd edn. Sebastopol, CA: O’Reilly Media
51. Torres, T. (2021) Continuous discovery habits: Discover products that create customer value and business value. North Charleston, SC: Product Talk
52. Scrum.org (2025) Scrum Hexis. Available at: https://thecynefin.co/product/hexi-scrumorg/?srsltid=AfmBOorcohLYeVy0qBsQFI6mK_bZtJA_uGC6hPL2BdptiTwNmMwpKTQv (Accessed: 17 May 2025).
53. Sutherland, J., Coplien, J.O., Heasman, L., den Hollander, M., Ramos, C. and The Scrum Patterns Group (2019) A Scrum Book: The Spirit of the Game. Raleigh, NC: Pragmatic Press.
    Members of The Scrum Patterns Group: Vervloed, E., Harrison, N., Harada, K., Yoder, J., Kim, J., O’Callaghan, A., Beedle, M., Bjørnvig, G., Friis, D., Reijonen, V., Benefield, G., Østergaard, J., Eloranta, V.-P., Leonard, E. & Aguiar, A.
54. Snowden, D. (2025) ‘Estuarine mapping first edition’, The Cynefin Co, 22 April. Available at: https://thecynefin.co/estuarine-mapping/ (Accessed: 8 June 2025)
55. Ackoff, R.L. (1999) Ackoff’s Best: His Classic Writings on Management. New York: John Wiley & Sons.
56. Fischer, B., Minnaar, J., Moehrle, M., & Cornuel, E. (2020) RenDanHeYi: Pioneering the Quantum Organisation. EFMD Global Focus, Special Supplement. Available at: https://bit.ly/RenDanHeYi [Accessed 27 May 2025]
57. Blackburn, S. (2003) Ethics: A Very Short Introduction. Oxford: Oxford University Press.
58. Mayer, T. (2025) A Simple Guide to Scrum. [Online]. Available at: https://scrum.academy/guide/ (Accessed: 17 May 2025)
59. Ohno, T. (1988) Toyota Production System: Beyond Large-Scale Production. Portland, OR: Productivity Press.
60. Toyota Motor Corporation (2024) Toyota Production System. Available at: https://global.toyota/en/company/vision-and-philosophy/production-system/index.html (Accessed: 17 May 2025).
61. Hounshell, D.A. & Smith, J.K. (1988) Science and Corporate Strategy: DuPont R&D, 1902–1980. Cambridge: Cambridge University Press.
62. Schwaber, K. and Sutherland, J. (1995) ‘SCRUM Development Process’, OOPSLA Business Object Design and Implementation Workshop. Austin, Texas, October 1995. Available at: http://jeffsutherland.org/oopsla/schwapub.pdf (Accessed: 17 May 2025).
63. Womack, J.P. and Jones, D.T. (1996) Lean Thinking: Banish Waste and Create Wealth in Your Corporation. New York: Simon & Schuster.
64. Thurlow, N., Turner, J.R. and Podder, A. (2020) The Flow System: The Evolution of Agile and Lean Thinking in an Age of Complexity. Flow Consortium. Available at: https://flowguides.org/Flow_Guide.pdf (Accessed: 17 May 2025).
65. Felderer, M. and Travassos, G.H. (2020) ‘The Evolution of Empirical Methods in Software Engineering’. Available at: https://arxiv.org/pdf/1912.11512.pdf (Accessed: 17 May 2025).
66. Creative Wisdom (n.d.) ‘Abduction, Deduction and Induction’. Available at: https://www.creative-wisdom.com/teaching/WBI/abduction5.pdf (Accessed: 17 May 2025).
67. Campbell, J. (2025) ‘Empiricism’, EBSCO Research Starters. Available at: https://www.ebsco.com/research-starters/religion-and-philosophy/empiricism (Accessed: 17 May 2025)
68. Kanban Guides (2025) Available at: https://kanbanguides.org (Accessed: 17 May 2025)
69. Scrum.org et al. (2021) The Kanban Guide for Scrum Teams. Available at: https://www.scrum.org/resources/kanban-guide-scrum-teams (Accessed: 17 May 2025)
70. Csíkszentmihályi, M. (1990) Flow: The Psychology of Optimal Experience. New York: Harper & Row
71. Templeton Foundation (2023) ‘What Is Emergence?’ John Templeton Foundation. Available at: https://www.templeton.org/news/what-is-emergence (Accessed: 17 May 2025).
72. van der Bles, A.M., van der Linden, S., Freeman, A.L.J. and Spiegelhalter, D.J. (2019) ‘Communicating uncertainty about facts, numbers and science’, Royal Society Open Science, 6(5), 181870. Available at: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6549952/ (Accessed: 17 May 2025).
73. Morieux, Y. (2015) How too many rules at work keep you from getting things done: Yves Morieux: Ted Talks, YouTube. At: https://youtu.be/t NoFstCmQ (April 3, 2023).
74. Holland, J.H. (1992) Complex Adaptive Systems. Daedalus, 121(1), pp. 17–30. Available at: https://www.jstor.org/stable/20025416 (Accessed: 17 May 2025).
75. Axelrod, R. and Cohen, M.D. (2000) Harnessing Complexity: Organizational Implications of a Scientific Frontier. New York: Free Press.
76. Juarrero, A. (1999) Dynamics in Action: Intentional Behavior as a Complex System. Cambridge, MA: MIT Press.
77. Snowden, D.J. and Boone, M.E. (2007) ‘A leader’s framework for decision making’, Harvard Business Review, 85(11), pp. 68–76. Available at: https://hbr.org/2007/11/a-leaders-framework-for-decision-making (Accessed: 17 May 2025)
78. Dictionary Marketing (2024) ‘B2B2B’. Available at: https://dictionarymarketing.com/definition/b2b2b/ (Accessed: 17 May 2025).
79. NetSuite (2023) ‘What Is Business to Business to Consumer (B2B2C)?’ Available at: https://www.netsuite.com/portal/resource/articles/ecommerce/b2b2c.shtml (Accessed: 17 May 2025).
80. LeSS (n.d.) ‘Why LeSS? Achieving adaptiveness’. Available at: https://less.works/less/framework/why-less (Accessed: 17 May 2025).
81. Sociocracy For All (n.d.) ‘Gerard Endenburg: founder of Sociocratic Circle Method and pioneer of self-management’. Available at: https://www.sociocracyforall.org/gerard-endenburg-founder-of-sociocratic-circle-method-and-pioneer-of-self-management/ (Accessed: 18 May 2025).
82. Patton, J. and Economy, P. (2014) User Story Mapping: Discover the Whole Story, Build the Right Product. Sebastopol, CA: O’Reilly Media.
83. Kotter, J.P., 1996. Leading Change. Boston: Harvard Business School Press.
84. ‘Genchi Genbutsu’ (2024) Wikipedia. Available at: https://en.wikipedia.org/wiki/Genchi_Genbutsu (Accessed: 18 May 2025).
85. ScrumPlop, n.d. Illigitimus Non Interruptis. The Scrum Book: The Spirit of the Game. Available at: https://sites.google.com/a/scrumplop.org/published-patterns/product-organization-pattern-language/illegitimus-non-interruptus [Accessed: 18 May 2025].
86. Cagan, M., 2018. Inspired: How to Create Tech Products Customers Love. 2nd ed. Hoboken, NJ: Wiley.
87. Cagan, M. & Jones, C., 2020. Empowered: Ordinary People, Extraordinary Products. Hoboken, NJ: Wiley.
88. Cagan, M., 2024. Transformed: Moving to the Product Operating Model. Hoboken, NJ: Wiley.
89. Schwaber, K. (2023) ‘Scrum Guide’, Ken Schwaber’s Blog, 25 September. Available at: https://kenschwaber.wordpress.com/2023/09/25/scrum-guide/ (Accessed: 20 May 2025).
90. Future Ready: How to Master Business Forecasting
    Morlidge, S. & Player, S., 2010. Future Ready: How to Master Business Forecasting. Chichester: John Wiley & Sons.
91. The Little Book of Beyond Budgeting
    Morlidge, S., 2024. The Little Book of Beyond Budgeting: A New Management Model for Organisations (Second Edition) [Beyond Books Press]
92. The Little (Illustrated) Book of Operational Forecasting
    Morlidge, S., 2019. The Little (Illustrated) Book of Operational Forecasting. [Troubador].
93. Present Sense
    Morlidge, S., 2019. Present Sense. [Troubador].
94. Zen and the Art of Organising Work
    Morlidge, S., 2021. Zen and the Art of Organising Work. [Troubador].
95. Cost Matters
    Morlidge, S., 2023. Cost Matters. [Beyond Books Press].
96. Beyond Budgeting i praktiken Fahlén, K., 2016. Beyond Budgeting i praktiken. Stockholm: Liber.
97. Fahlén, K., 2018. Dynamic Management Strategy: A guide to management innovation and competitive advantage. Gothenburg: BAS
98. Bogsnes, B., 2016. Implementing Beyond Budgeting: Unlocking the Performance Potential. 2nd ed. Chichester: John Wiley & Sons.
99. Boyd, J.R. (1995–1996) The Essence of Winning and Losing. Unpublished briefing slides. Note: Boyd’s OODA was primarily disseminated through military briefings and unpublished manuscripts. His final conceptualization appears in The Essence of Winning and Losing, which emphasizes nonlinear decision-making and adaptation in complex environments.
100. Turner, J.R., Thurlow, N. and Rivera, B. (2019) The Flow System Guide. Available at: https://flowguides.org/Flow_Guide.pdf (Accessed: 24 May 2025). Summary: This guide integrates Boyd’s OODA with complexity theory and agile practices, framing it as a dynamic, non-linear decision-making process for organizational flow.
101. Williamson, P.J. & Yin, E. (2018) ‘Management Innovation Made in China: Haier’s Rendanheyi’, California Management Review, 61(1), pp. 71-93.
102. Richards, C. (2004) Certain to Win: The Strategy of John Boyd, Applied to Business. Bloomington, IN: Xlibris
103. Becker, S et al (co-author) The Viable Map Workbook 2023 [Beyond Books Press]
104. Frey, B.S. and Jegen, R. (2001) ‘Motivation crowding theory’, Journal of Economic Surveys, 15(5), pp. 589–611.
105. Cameron, J., Banko, K.M. and Pierce, W.D. (2001) ‘Pervasive negative effects of rewards on intrinsic motivation: The myth continues’, The Behavior Analyst, 24(1), pp. 1–44.
106. Deci, E.L., Koestner, R. and Ryan, R.M. (1999) ‘A meta-analytic review of experiments examining the effects of extrinsic rewards on intrinsic motivation’, Psychological Bulletin, 125(6), pp. 627–668.
107. Ryan, R.M. and Deci, E.L. (2000) ‘Intrinsic and extrinsic motivations: Classic definitions and new directions’, Contemporary Educational Psychology, 25(1), pp. 54–67.
108. Sandel, M.J. (2012) What money can’t buy: The moral limits of markets. London: Allen Lane.
109. Kohn, A. (1993) ‘Why incentive plans cannot work’, Harvard Business Review, 71(5), pp. 54–63.
110. Fuzzy Business: How to be roughly right rather than precisely wrong (unpublished).
111. Lewis, R. (2023) An operating model for business agility: Agile for managers of the digital age. Independently published.
112. less.works (n.d.) Technical Excellence. Available at: https://less.works/less/technical-excellence (Accessed: 7 June 2025)
113. Cagan, M. (2024) Transformed: Moving to the Product Operating Model. Hoboken, NJ: Wiley.
114. Cagan, M. (2025) ‘The Product Operating Model’, Silicon Valley Product Group, 17 March. Available at: https://www.svpg.com/the-product-operating-model/ (Accessed: 8 June 2025).
115. Cagan, M. (n.d.) ‘The Product Operating Model: An Introduction’, Silicon Valley Product Group. Available at: https://www.svpg.com/the-product-operating-model-an-introduction/ (Accessed: 8 June 2025)
116. Scrum.org (2025) ‘The Agile Product Operating Model’, Scrum.org, 1 May. Available at: https://www.scrum.org/resources/agile-product-operating-model (Accessed: 8 June 2025).
117. Scrum.org (2025) ‘Agile Product Operating Model State of Play - Part 1 - Fundamentals’, Scrum.org, 12 May. Available at: https://www.scrum.org/resources/blog/agile-product-operating-model-state-play-part-1-fundamentals (Accessed: 8 June 2025).
118. Scrum.org (2024) ‘Project to Product and the Agile Product Operating Model’, Scrum.org, 7 November. Available at: https://www.scrum.org/resources/blog/project-product-and-agile-product-operating-model (Accessed: 8 June 2025).
119. Scrum.org (2024) Moving to an Agile Product Operating Model [PDF]. Available at: https://www.scrum.org/resources/moving-agile-product-operating-model-evidence-based-approach-delivering-products-digital-age or https://bit.ly/SDOAPOM . (Accessed: 8 June 2025)
120. Scotland, K. (2023) Why strategy deployment? Here are three great reasons, AvailAgility. At: https://availagility.co.uk/2023/02/16/why-strategy-deployment-here-are-three-great-reasons/ (Accessed: April 3, 2023).
121. Scotland, K. (2019) Deploying strategies as choices, AvailAgility. At: https://availagility.co.uk/2019/02/08/deploying-strategies-as-choices/ (Accessed: April 3, 2023).
122. Scotland, K. (2017) Strategy deployment and playing to win, AvailAgility. At: https://availagility.co.uk/2017/07/14/strategy-deployment-and-playing-to-win/ (Accessed: April 3, 2023).
123. Scotland, K. (2017) A strategy deployment cadence, AvailAgility. At: https://availagility.co.uk/2017/09/06/a-strategy-deployment-cadence/ (Accessed: April 3, 2023).
124. Scotland, K. (2022) The ultimate X-matrix for your agile transformation is here, AvailAgility. At: https://availagility.co.uk/2022/11/03/the-ultimate-x-matrix-for-youragile-transformation-is-here/ (Accessed: April 5, 2023).
125. Krebs, J. (2023) Agile kata pro, Agile Kata Pro. At: https://agilekata.pro/ (Accessed: April 4, 2023).
126. Doerr, J. (2023) OKRs 101, What Matters. At: https://www.whatmatters.com/get-started/ (Accessed: April 4, 2023).
127. Wodtke, C. (2021) Radical focus achieving your most important goals with objectives and key results–. Palo Alto, CA: Cucina Media.
128. Gothelf, J. & Seiden, J. (2024) Who Does What By How Much?: A Practical Guide to Customer-Centric OKRs. New York: Sense & Respond Press.
129. Appelo, J. (2023) Sometimes, you *don’t* want focus, unFIX. At: https://unfix.com/blog/sometimes-you-dont-want-focus (Accessed: 14 January 2024).
130. Appelo, J. (2023) Bets and objectives, unFIX. At: https://unfix.com/bets-and-objectives (Accessed: 14 January 2024).
131. McChesney, C. (2023) The 4 disciplines of execution (new), FranklinCovey. At: https://www.franklincovey.com/the-4-disciplines/ (Accessed: April 4, 2023).
132. Scrum.org (2024) Evidence-Based Management (EBM) Framework, Scrum.org. Available at: https://www.scrum.org/resources/evidence-based-management . (Accessed: 8 June 2025).
133. Burrows, M. (2023) Home: Agendashift™, Agendashift. At: https://www.agendashift.com/ (Accessed: April 4, 2023).
134. Kniberg, H. and Ivarsson, A. (2012) Scaling at Spotify, Crisp. At: https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf (Accessed: April 5, 2023).
135. Ambler, S.W. and Lines, M. (2023) Disciplined Agile® Toolkit - Project Management Institute, PMI. At: https://www.pmi.org/disciplined-agile/ (Accessed: April 5, 2023).
136. Leffingwell, D. and Knaster, R. (2023) Safe 6.0 framework, Scaled Agile Framework. At: https://www.scaledagileframework.com/ (Accessed: April 5, 2023).
137. Sutherland, J. (2021) Scrum@Scale - the scaling framework created by dr. Jeff Sutherland, Scrum@Scale Framework. At: https://www.scrumatscale.com/ (Accessed: April 5, 2023).
138. Skelton, M. and Pais, M. (2023) Team topologies, Team Topologies. At: https://teamtopologies.com/ (Accessed: April 5, 2023).
139. Appelo, J. (2023) Versatile Organization Design, unFIX. At: https://unfix.com/ (Accessed: April 5, 2023).
140. Merel, P. (2023) Xscale Alliance, XSCALE Alliance. At: https://xscalealliance.org/#manifesto (Accessed: April 5, 2023).
141. Schwaber, K. et al. (2021) Online nexus guide, Scrum.org. At: https://www.scrum.org/resources/online-nexus-guide (Accessed: April 5, 2023).
142. Quartel, R. et al. (2024) FaST guide, Fluid Scaling Technology. At: https://www.fastagile.io/ (Accessed: December 6, 2023).
143. Ramos, C. and Pavlichenko, I. (2023) Creating agile organizations, Creating Agile Organizations. At: https://creatingagileorganizations.com/ (Accessed: April 15, 2023).
144. Larman, C. & Vodde, B. (2025) LeSS (Large-Scale Scrum) Framework. Available at: https://less.works/less/framework (Accessed: 8 June 2025)
145. Flight Levels GmbH (2025) Flight Levels Framework. Available at: https://www.flightlevels.io/what-is-flight-levels/ (Accessed: 8 June 2025).
146. Krivitsky, A. and Flemm, R. (2022) Org topologies, Org Topologies. At: https://www.orgtopologies.com/ (Accessed: April 4, 2023).
147. Singh, P. (2023) Scaling Simplified: A Practitioner’s Guide to Scaling Flow. Florida: Self-published. Available at: https://leanpub.com/scalingsimplified (Accessed: 8 June 2025)
148. Davies, Dan. (2025) The Unaccountability Machine: Why Big Systems Make Terrible Decisions—and How the World Lost Its Mind. London: Profile Books Ltd. (Paperback edition).
149. Stripe (2025) ‘Sir Jony Ive and Patrick Collison Fireside Chat | Stripe Sessions 2025’, YouTube video, 8 May. Available at: https://youtu.be/wLb9g_8r-mE?si=1rEJxU0sxixvblQ3&t=1390 (Accessed: 8 June 2025)