---

Inspeção e Adaptação (I&A): Promover a Melhoria Contínua em Agile Scrum

Inspeção e Adaptação (I&A) funciona como uma ferramenta poderosa no Desenvolvimento de Software Agile. É como um espelho, refletindo a evolução do software a cada passo. Surpreendentemente, não se trata apenas de verificar o progresso das tarefas, mas de eliminar dificuldades e melhorar o trabalho. É como arrumar regularmente o quarto para o manter limpo. Vamos compreender melhor este princípio.

«Inspeção e Adaptação» descreve a prática contínua de inspecionar resultados e adaptar planos em Scrum. Também designa um evento separado de SAFe, discutido abaixo, em que as equipas e as partes interessadas avaliam uma solução e identificam melhorias. Esta prática promove aprendizagem contínua, resolução de problemas e procura da excelência operacional nas equipas de desenvolvimento de software Agile.

Compreender a Inspeção e Adaptação

Em SAFe, Inspeção e Adaptação (I&A) é um evento estruturado no final de um PI, que envolve demonstração, avaliação, reflexão e itens de melhoria do backlog. Esta edição utiliza o termo Program Increment (PI). No Scrum de base, a inspeção e a adaptação ocorrem ao longo do Sprint e dos seus eventos; não existe um evento obrigatório adicional chamado I&A.

Na parte de inspeção de I&A, todas as equipas envolvidas mostram as realizações coletivas durante o PI. Isto significa que cada equipa Agile apresenta as funcionalidades concluídas, demonstrando o que construiu ao longo do Program Increment. Os Business Owners colaboram de perto com as equipas Agile e pontuam o valor de negócio real alcançado para cada Objetivo de PI da Equipa.

A parte de adaptação começa após a inspeção. O próximo passo é avaliar o estado atual da solução: Quão eficaz é? O que pode melhorar? Existem problemas subjacentes que precisam de ser tratados? É aqui que entram as medições qualitativas e quantitativas.

Por exemplo, pode medir um aumento da produtividade após implementar os princípios de I&A ou comparar as taxas de defeitos antes e depois. Estas métricas ajudam a identificar áreas de melhoria e fornecem dados valiosos para decidir.

A última parte deste processo é identificar itens de melhoria do backlog com base nos desafios e oportunidades descobertos na inspeção e avaliação. Estes itens são fundamentais para manter a melhoria contínua no Agile Release Train.

No seu conjunto, compreender estas partes permite perceber profundamente como a Inspeção e Adaptação ajuda a garantir a agilidade do desenvolvimento de software. Ao analisar criticamente o trabalho, as equipas podem enfrentar os desafios com eficácia e facilitar o crescimento e progresso contínuos.

Depois de analisar a importância decisiva da Inspeção e Adaptação na melhoria contínua do desenvolvimento de software Agile, aprofundemos os Elementos Essenciais do Ciclo de Inspeção e Adaptação para esclarecer melhor o seu significado.

Elementos Essenciais do Ciclo de Inspeção e Adaptação

O evento SAFe de Inspeção e Adaptação (I&A) tem três partes principais: Demonstração do Sistema do PI, medição quantitativa e qualitativa e uma retrospetiva com workshop de resolução de problemas. Cada parte é fundamental para facilitar a melhoria contínua no Agile Release Train (ART).

Demonstração do Sistema do PI

A Demonstração do Sistema do PI é uma parte decisiva do evento I&A, em que se mostram todas as funcionalidades desenvolvidas no Program Increment (PI). Frequentemente, inclui um público mais amplo, como clientes ou representantes do portefólio. Proporciona uma oportunidade para os Business Owners colaborarem com as equipas Agile na pontuação do valor de negócio real alcançado para cada Objetivo de PI da Equipa.

Essencialmente, esta demonstração permite que as partes interessadas compreendam de forma abrangente os resultados tangíveis do PI. Não é apenas uma apresentação: é uma sessão interativa em que podem observar o alinhamento das funcionalidades com os objetivos estratégicos e o valor para os utilizadores finais. Esta parte de I&A proporciona uma plataforma inestimável de transparência e alinhamento no ART, promovendo uma visão e compreensão partilhadas do progresso.

Medição Quantitativa e Qualitativa

Após a Demonstração do Sistema do PI, o evento I&A passa para uma fase de medição quantitativa e qualitativa. O ART revê as métricas acordadas e as tendências dos dados, com facilitação do Release Train Engineer (RTE). Um Solution Train Engineer pode apoiar uma coordenação mais ampla ao nível da solução, quando essa estrutura existe.

Esta etapa não se limita a analisar números: procura extrair conhecimentos significativos dos dados quantitativos e qualitativos. A informação recolhida funciona como bússola para as decisões e ações futuras. Ao analisar as pontuações de realização calculadas com base no valor de negócio planeado e real e as medidas de previsão agregadas a partir dos dados de cada equipa, as partes interessadas compreendem claramente o desempenho face aos objetivos. Estas conclusões orientam discussões informadas e planos de ação para melhorar as entregas futuras.

Retrospetiva

O componente final do evento I&A é a Retrospetiva, muito importante para identificar itens de melhoria do backlog. Nesta sessão breve, as equipas refletem sobre o trabalho durante o PI, avaliando o que correu bem e descobrindo áreas de melhoria.

É nesta retrospetiva que as equipas descobrem problemas significativos a tratar no workshop de resolução de problemas. Com diferentes formatos Agile, como «Começar-Parar-Continuar» ou «Retrospetiva do Barco à Vela», analisam causas profundas, resolvem eficazmente problemas sistémicos e adotam uma cultura de melhoria contínua.

Estes elementos destacam a importância de I&A no Desenvolvimento de Software Agile, criando uma estrutura de avaliação, aprendizagem e resolução de problemas que apoia a melhoria em todo o ART e, quando aplicável, no Solution Train mais amplo.

Com uma compreensão firme dos componentes essenciais da melhoria contínua no Desenvolvimento de Software Agile, concentremo-nos agora em estabelecer uma estrutura robusta para as retrospetivas.

Consolidar a Estrutura das Reuniões de Retrospetiva

As retrospetivas são parte integrante do desenvolvimento de software Agile, permitindo refletir sobre o desempenho e identificar melhorias. Proporcionam um espaço seguro de diálogo aberto para discutir o que correu bem, o que não correu e como mudar positivamente. Para garantir conclusões significativas e resultados concretos, é fundamental uma estrutura sólida que promova discussões produtivas e melhoria contínua.

Uma técnica eficaz frequentemente utilizada nas retrospetivas é a análise SWOT. Ajuda a avaliar Forças, Fraquezas, Oportunidades e Ameaças. Ao identificar forças e fraquezas internas, juntamente com oportunidades e ameaças externas, a equipa compreende de forma abrangente o seu estado atual. Esta análise facilita discussões esclarecedoras e permite concentrar-se em aproveitar as forças, tratar as fraquezas, aproveitar as oportunidades e mitigar ameaças. É como fotografar o estado atual da equipa: um exercício de autoconhecimento que conduz a planos de ação direcionados.

Por exemplo, na análise SWOT, os membros podem reconhecer uma forte cultura de colaboração (força), mas dificuldades com requisitos pouco claros (fraqueza). Também podem identificar a possibilidade de adotar novas ferramentas ou tecnologias (oportunidade) e reconhecer ameaças como mudanças nas tendências do mercado ou nas necessidades dos clientes. Estas conclusões abrem caminho a conversas construtivas sobre como otimizar forças, tratar fraquezas, aproveitar oportunidades e enfrentar ameaças.

Outra estrutura valiosa é o conjunto de cinco orientações aqui utilizado: Parar, Começar, Continuar, Ajustar e Repetir. Esta abordagem incentiva a identificar ações a parar, começar, continuar, ajustar face às práticas anteriores e repetir para manter o sucesso. As cinco orientações promovem uma avaliação crítica dos processos e comportamentos para determinar o que precisa de alteração ou reforço. A estrutura reforça uma cultura de adaptação ao destacar a importância do refinamento iterativo.

Imagine que uma equipa decide «Parar» a sobreposição de reuniões de Sprint Planning, pois criava confusão. Opta por «Começar» a manter o Daily Scrum focado no progresso em direção ao Objetivo do Sprint e no próximo plano executável dos Developers, melhorando a comunicação e o alinhamento. Também acorda «Continuar» o mapeamento de histórias de utilizador pela sua eficácia, mas «Ajustar» a frequência à dinâmica do projeto. Esta avaliação sistemática permite identificar ações específicas para implementação imediata e ajustes contínuos.

Com formatos abrangentes como a análise SWOT e as cinco orientações nas retrospetivas, as equipas Agile podem converter eficazmente os conhecimentos coletivos em iniciativas mensuráveis de melhoria. No panorama dinâmico do desenvolvimento de software Agile, identificar mudanças e criar soluções é fundamental para um progresso sustentado ao longo dos ciclos.

Identificar Mudanças e Criar Soluções

Após discussões e retrospetivas aprofundadas, o próximo passo fundamental é identificar mudanças e criar soluções. No workshop de resolução de problemas, as equipas Agile reúnem-se para analisar as questões com grande foco. Utilizam ferramentas como o diagrama de espinha de peixe e a técnica dos 5 Porquês para identificar as principais causas dos problemas.

O Diagrama de Espinha de Peixe e a Técnica dos 5 Porquês

O o diagrama de espinha de peixe, ou diagrama de Ishikawa, ajuda a classificar as possíveis causas de um problema em ramos específicos, permitindo uma investigação estruturada. Com este recurso visual, as equipas consideram metodicamente os fatores nas diferentes categorias para identificar a causa profunda. Da mesma forma, a técnica dos 5 Porquês incentiva as equipas a perguntar «porquê» várias vezes para chegar à origem dos problemas. Ao repetir esta pergunta simples, podem descobrir causas subjacentes que não eram imediatamente evidentes.

Por exemplo, se uma equipa de desenvolvimento sofrer uma quebra de produtividade, poderá utilizar o diagrama de espinha de peixe para explorar categorias como processos, pessoas, ferramentas, ambiente e políticas. Ao decompor os fatores que contribuem para a quebra, pode compreender o problema de forma abrangente.

Depois de identificar as principais fontes de preocupação com estas ferramentas analíticas, entra em jogo um passo adicional essencial: Análise de Pareto. Esta técnica permite priorizar os problemas, determinando os que têm maior impacto. Assim, as equipas Agile podem distribuir eficientemente os recursos e o esforço para resolver primeiro os problemas mais importantes.

A Análise de Pareto baseia-se no princípio de Pareto, também conhecido como regra 80/20. Ilustra como uma grande parte dos efeitos pode resultar de uma pequena parte das causas, frequentemente expressa como 80% e 20%. Trate esta proporção como uma regra prática a investigar com dados reais, não como uma distribuição garantida. No desenvolvimento de software Agile, destaca o foco nos problemas fundamentais com maior impacto no desempenho e na eficácia globais.

Pense em arrumar um quarto desorganizado: começaria por organizar e limpar as áreas onde se acumula mais desordem, resolvendo a maior parte do problema antes de aperfeiçoar os detalhes menos urgentes.

Após esta análise, as equipas Agile podem realizar sessões de geração de ideias para criar itens de melhoria do backlog. São tarefas executáveis concebidas para tratar sistematicamente as preocupações identificadas. Cada item é cuidadosamente elaborado para resolver causas profundas específicas e promover mudanças positivas no desenvolvimento de software da organização.

Ao analisar os problemas com precisão e utilizar ferramentas analíticas estruturadas para identificar causas profundas, as equipas Agile reforçam a capacidade de criar soluções direcionadas que promovem a melhoria contínua das práticas de desenvolvimento.

Estratégias: Avaliação e Aperfeiçoamento

O ciclo PDCA é um conceito poderoso que ajuda as equipas Agile a avaliar a eficácia das soluções e realizar melhorias contínuas.

Planear

Na fase de planeamento, a equipa identifica o problema ou a oportunidade de melhoria. É importante definir claramente o que precisa de correção ou otimização e estabelecer objetivos claros. Sem um plano claro, será difícil identificar se a solução proposta foi eficaz.

Executar

Com o plano definido, é altura de o implementar. Isto pode envolver alterações de código, atualização de processos ou integração de ferramentas. A fase «Executar» é o momento de passar à prática: as melhorias planeadas entram em ação.

Verificar

Após implementar as mudanças, é fundamental verificar o impacto. Isto envolve avaliar como resolveram os problemas ou oportunidades identificados. A avaliação pode recorrer a métricas, feedback dos utilizadores ou outras formas de análise.

Agir

Com base nos resultados da fase «Verificar», é altura de agir. Se as mudanças forem eficazes, devem ser integradas nos processos contínuos. Se não tiverem o impacto pretendido, a equipa deve aperfeiçoar ou rever a abordagem.

Por exemplo, uma equipa Agile implementa um novo framework de testes automatizados para reduzir os defeitos de software. Na fase «Verificar», analisa as taxas de defeitos antes e depois da implementação. Se observar uma redução significativa, integra o framework como prática habitual («Agir»). Se não houver mudança visível ou surgir um impacto negativo inesperado, poderá voltar a analisar e aperfeiçoar a abordagem.

Esta abordagem iterativa garante a integração contínua das melhorias no ciclo de vida do desenvolvimento. Proporciona uma estrutura para aceitar a mudança e promover a melhoria contínua nas equipas Agile.

Avaliar e aperfeiçoar consistentemente os processos com o ciclo PDCA permite garantir que as práticas de desenvolvimento evoluem constantemente para produzir melhores resultados.

O Papel Decisivo de I&A na Metodologia Agile

No contexto SAFe, o evento de Inspeção e Adaptação (I&A) é mais do que uma formalidade: é um pilar da melhoria incansável e da aprendizagem contínua. A sua importância evidencia-se na capacidade de facilitar eventos estruturados e sincronizados em que cada parte interessada pode contribuir, aprender e promover mudanças. Mas por que é tão decisivo? Vejamos em detalhe.

Primeiro, no centro do evento I&A está a Demonstração do Sistema do PI, que mostra todas as funcionalidades desenvolvidas no Program Increment (PI). Esta plataforma permite que os Business Owners colaborem com as equipas Agile na pontuação do valor de negócio real alcançado para cada Objetivo de PI da Equipa. Assim, oferece uma avaliação tangível das realizações e do seu alinhamento com os objetivos mais amplos do negócio.

Além disso, a parte de Medição Quantitativa e Qualitativa é uma contribuição fundamental para todo o processo. Envolve rever métricas acordadas e tendências dos dados recolhidos pelo RTE e pelo Solution Train Engineer. Nesta avaliação, o valor de negócio planeado e real é integrado na medida de previsibilidade do ART. É aqui que vemos, em números claros, a eficácia dos nossos esforços.

Por fim, chegamos à retrospetiva, uma parte fundamental em que as equipas identificam problemas significativos numa sessão de geração de ideias para os resolver. Não serve apenas para desabafar preocupações, mas para as converter em passos concretos de melhoria. Com diferentes formatos de retrospetiva Agile e um Workshop de Resolução de Problemas facilitado pelo RTE, as equipas podem aprofundar a análise das causas com ferramentas como diagramas de espinha de peixe e os 5 Porquês.

Considere o seguinte: numa retrospetiva, uma equipa pode descobrir problemas recorrentes de falhas na comunicação. Com a estrutura do Workshop de Resolução de Problemas, pode analisá-los e identificar problemas sistémicos a tratar de forma abrangente para melhorar a colaboração futura.

O papel decisivo da Inspeção e Adaptação não é apenas identificar falhas: é mostrar o valor de negócio alcançado, analisar tendências dos dados e capacitar as equipas para enfrentar os problemas diretamente. Esta abordagem estruturada reforça o princípio central da melhoria contínua no desenvolvimento de software Agile.

Com eventos estruturados como a Inspeção e Adaptação, o desenvolvimento Agile não só identifica áreas de melhoria como permite tratá-las eficazmente, promovendo uma cultura de aperfeiçoamento contínuo.

Com que frequência devem as equipas realizar inspeções e adaptações num projeto Agile?

Resposta: Num projeto Agile, devem realizar inspeções e adaptações com frequência, idealmente no final de cada iteração ou Sprint. Isto permite melhorar continuamente e garantir que o projeto se mantém alinhado com os requisitos e as exigências do mercado em mudança. Segundo o inquérito da Agile Alliance citado nesta edição, as equipas que o faziam mais frequentemente registavam maior satisfação dos clientes e menor tempo de chegada ao mercado do que as restantes.

Pode dar exemplos de implementações bem-sucedidas da abordagem de inspeção e adaptação em projetos reais?

Resposta: Claro! O capítulo original descreve um exemplo de uma aplicação bancária móvel da Empresa X. Ao rever e ajustar regularmente os processos através de retrospetivas, identificaram estrangulamentos, melhoraram a colaboração e aumentaram a satisfação dos clientes. O tempo do ciclo de lançamento reduziu-se em 30%, a densidade de defeitos diminuiu 20% e as avaliações dos clientes melhoraram 15%.

Como se aplica o princípio de «inspeção e adaptação» na gestão de projetos Agile?

Resposta: O princípio aplica-se através de ciclos regulares de iteração chamados Sprints. No final de cada Sprint, a equipa reflete sobre o que correu bem e o que pode melhorar, com base nos dados recolhidos. Este ciclo de feedback permite a melhoria contínua e ajustes da abordagem, produzindo entregas de melhor qualidade. Segundo um estudo da McKinsey, as organizações que adotam este princípio registam um aumento de 25% na produtividade e uma redução de 30% nas taxas de insucesso dos projetos.

Quais são os benefícios de incorporar práticas de inspeção e adaptação num projeto?

Resposta: Estas práticas trazem inúmeros benefícios. Primeiro, permitem avaliar continuamente o progresso e identificar áreas de melhoria, aumentando a eficiência e a produtividade. Segundo, promovem transparência e colaboração, criando uma cultura de aprendizagem e inovação. Por fim, ajudam a adaptar rapidamente os projetos à mudança dos requisitos ou do mercado, reduzindo o risco de soluções ultrapassadas ou ineficazes. Segundo um estudo da McKinsey, as organizações que adotam estas práticas no desenvolvimento Agile registam um aumento de 30% nas taxas de sucesso dos projetos.

Existem ferramentas ou técnicas específicas para facilitar o processo de inspeção e adaptação?

Resposta: Sim, existem ferramentas e técnicas específicas no desenvolvimento de software Agile. Entre as ferramentas habituais estão as retrospetivas, em que a equipa reflete sobre o que correu bem e o que pode melhorar nos processos, e os quadros Kanban ou sistemas de gestão de tarefas para visualizar e acompanhar o progresso. Técnicas como Kaizen, centrada na melhoria contínua, e princípios de Pensamento Lean também apoiam este processo ao promover aprendizagem e flexibilidade. Segundo um inquérito da VersionOne, 84% das equipas Agile afirmaram utilizar retrospetivas para promover a melhoria contínua nos projetos (State of Agile Report).

Que evento Scrum é utilizado para inspecionar e adaptar o processo Scrum?

Resposta: Scrum utiliza eventos para permitir inspeção e adaptação. O evento especificamente centrado na melhoria da qualidade e eficácia da Equipa Scrum é a Sprint Retrospective, em que os membros refletem sobre o Sprint concluído para identificar o que correu bem, o que pode melhorar e como implementar essas melhorias nas próximas iterações. Além disso, a Sprint Review permite que as partes interessadas inspecionem o incremento do produto e deem feedback, contribuindo para possíveis ajustes no Product Backlog. Em conjunto, estas cerimónias criam um ciclo de feedback que permite inspeção e adaptação contínuas no Scrum Framework.

Quais são os quatro eventos Scrum de inspeção e adaptação?

Resposta: Os quatro eventos formais dentro do Sprint são Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective. O próprio Sprint é o evento que os contém.

• Sprint Review: Este evento permite que a Equipa Scrum mostre o trabalho concluído às partes interessadas e receba feedback valioso.
• Sprint Retrospective: A retrospetiva concentra-se no desempenho da equipa durante o Sprint, permitindo refletir sobre o que correu bem, o que pode melhorar e definir estratégias de aperfeiçoamento contínuo.
• Sprint Planning: A Equipa Scrum discute por que é valioso o Sprint, e os Developers selecionam o trabalho e planeiam como atingir o Objetivo do Sprint.
• Daily Scrum: Os Developers inspecionam o progresso em direção ao Objetivo do Sprint e adaptam o plano para o próximo dia de trabalho.

Uma demonstração do Incremento pode apoiar a Sprint Review, que também deve incluir uma discussão colaborativa dos resultados e das adaptações futuras. Um Scrum of Scrums pode ajudar várias equipas a coordenar dependências; é uma prática opcional de expansão, não um evento formal do Scrum de base.

O que inclui a agenda de inspeção e adaptação?

Resposta: A agenda do evento SAFe de Inspeção e Adaptação (I&A) inclui uma Demonstração do Sistema do PI, revisão das medições e retrospetiva com workshop de resolução de problemas. No Scrum de base, a agenda relevante depende do evento. Pode incluir avaliar o estado atual do produto, a eficácia do PI (Program Increment) Planning, identificar e eliminar impedimentos e analisar métricas quantitativas como Velocity e tempo de ciclo. As equipas participam em discussões e retrospetivas sobre aspetos técnicos e colaborativos, promovendo uma cultura de melhoria contínua. A agenda também incentiva a comunicação aberta e a exploração de novas ideias para aperfeiçoar o desenvolvimento global.

Principais Conclusões sobre Inspeção e Adaptação Scrum

No domínio da metodologia Agile, o Scrum Framework destaca-se como uma abordagem robusta ao desenvolvimento do produto. A inspeção e a adaptação repetem-se ao longo de todo o ciclo Scrum, permitindo refletir sobre o desempenho, identificar melhorias e aumentar a eficiência. Vejamos as principais conclusões desta fase fundamental, que resume a essência de Scrum.

1. Produto: No centro da Inspeção e Adaptação Scrum está o produto. Os eventos permitem avaliar o seu estado atual, alinhando-o com as expectativas das partes interessadas e garantindo o rumo certo.
2. Conhecimento: O conhecimento é um pilar da melhoria contínua. A Inspeção e Adaptação Scrum destaca a importância de aproveitar o conhecimento coletivo para avaliar o desempenho anterior, promovendo uma cultura de aprendizagem e adaptação.
3. Ideias: Estas práticas criam oportunidades para novas ideias. As equipas são incentivadas a gerar ideias e propor soluções inovadoras para os desafios e a otimização dos processos, mantendo o desenvolvimento do produto dinâmico e capaz de responder.
4. Pilares: A Inspeção e Adaptação Scrum assenta nos três pilares de transparência, inspeção e adaptação. As equipas analisam o trabalho com transparência, inspecionam os processos aprofundadamente e adaptam-se segundo os conhecimentos adquiridos para garantir um ambiente de desenvolvimento robusto e flexível.
5. PI Planning: No exemplo SAFe, o PI (Program Increment) Planning proporciona o contexto para o evento I&A. Não é um requisito adicional do Scrum de base. As equipas avaliam a eficácia das sessões de PI Planning, identificando oportunidades de melhoria para reforçar a execução e a entrega globais do programa.
6. Impedimentos: Identificar e eliminar impedimentos é um tema central da Inspeção e Adaptação Scrum. As equipas aprofundam os desafios enfrentados e colaboram para definir estratégias que os eliminem, garantindo um progresso mais fluido nas iterações seguintes.
7. Níveis: A Inspeção e Adaptação Scrum atua em vários níveis, do desempenho individual à dinâmica da equipa e ao progresso global do projeto. Esta análise multidimensional garante uma compreensão abrangente das áreas que exigem atenção e aperfeiçoamento.
8. Adaptação: A essência da Inspeção e Adaptação Scrum é adaptar. As equipas aceitam a mudança e ajustam continuamente estratégias, processos e planos à evolução dos requisitos, entregando o melhor valor às partes interessadas.
9. Números: As métricas quantitativas são fundamentais na Inspeção e Adaptação Scrum. As equipas analisam métricas como Velocity, tempo de ciclo e gráficos burndown para compreender o desempenho e tomar decisões informadas nas próximas iterações.
10. Aspetos: A Inspeção e Adaptação Scrum abrange vários aspetos do desenvolvimento. As equipas analisam tanto os aspetos técnicos como as dimensões de colaboração e comunicação, garantindo uma abordagem abrangente à melhoria.
11. Competências: A inspeção e a adaptação destacam a importância das competências individuais e coletivas. As equipas avaliam as suas competências, reconhecendo pontos fortes e identificando áreas de desenvolvimento para reforçar a capacidade global.
12. Interações: A comunicação e a colaboração eficazes são componentes fundamentais da Inspeção e Adaptação Scrum. As equipas refletem sobre as interações, procurando formas de promover a comunicação aberta, reforçar a colaboração e fortalecer as ligações que impulsionam o desenvolvimento bem-sucedido do produto.
13. Coragem: A Inspeção e Adaptação Scrum incentiva a coragem para reconhecer limitações e enfrentá-las diretamente. Esta coragem promove honestidade e transparência, estabelecendo a base da melhoria contínua.
14. Atividades: A inspeção e a adaptação são apoiadas por atividades como retrospetivas e discussões colaborativas. As equipas participam para avaliar sistematicamente o desempenho, trocar perspetivas e planear melhorias concretas.

Concluindo, a inspeção e a adaptação são práticas contínuas que exprimem as bases empíricas de Scrum e os princípios Agile. Ao concentrar-se no desenvolvimento do produto, aceitar a mudança e promover uma cultura de melhoria contínua, as equipas podem elevar as práticas Scrum e entregar mais valor às partes interessadas.