Image The demo works. The feature does exactly what the slide said it would. Someone says "nice." A couple of people do the little typing-clap in the chat. "Any questions?" A pause, the good kind, the kind that means we're done. "Great, thanks everyone." And the review is over. Notice what didn't happen.
Image The demo works. The feature does exactly what the slide said it would. Someone says "nice." A couple of people do the little typing-clap in the chat. "Any questions?" A pause, the good kind, the kind that means we're done. "Great, thanks everyone." And the review is over. Notice what didn't happen.
Notice what didn't happen. Nobody looked at the thing that's three weeks behind. Nobody mentioned the integration that's holding together with tape. The risk everyone's privately worried about didn't come up, because this wasn't the room for it. Something was shown. Nothing was inspected.
That's the quiet swap at the heart of most reviews. Showing replaced inspecting, and nobody noticed, because showing feels productive and looks like progress. You leave the meeting a little reassured, which is exactly the problem: the meeting that's supposed to surface the real state of the work has become the meeting most engineered to hide it.
Here's the distinction the calendar invite blurs. Showing is presenting the parts you chose, in the light you chose, to people you'd rather impress than alarm. Inspecting is holding the whole thing up to the light, including the parts you'd never put on screen, and asking what's actually true.
A review that only shows the wins is a highlight reel. It's the most watchable meeting of the Sprint and the least honest one.
And this isn't a Scrum problem. Call it a Sprint Review, a demo, a showcase, a stage-gate, a monthly steering update. Every way of working has a moment where the team is meant to look squarely at the real state of the work. The name changes. The theatre is the same.
In context
- Topic: Proyectos, PMO y Riesgos — Gestión de proyectos, oficinas de proyecto y riesgo del portafolio.
- Source: Scrum.org
- Published: 13/10/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Por que importa
Em gestão de projetos, quase tudo o que se discute como problema técnico é na verdade um problema de expectativas mal negociadas no começo. Escopo, prazo e custo foram acordados num momento em que ninguém tinha informação suficiente, e depois ninguém quis reabrir a conversa.
Meu filtro é a qualidade do relatório de status. Se todos os projetos estão em verde, o sistema de informação não serve: em qualquer portfólio real há iniciativas com problema, e uma organização saudável as mostra a tempo em vez de descobri-las no comitê de encerramento.
O que costuma dar errado
O erro clássico é tratar a gestão de riscos como entregável da fase de planejamento. Monta-se a matriz, aprova-se, arquiva-se. Ninguém a reabre até o encerramento, quando serve para documentar que o risco estava previsto — que é exatamente o contrário de gerenciá-lo.
O que observar
- Como foi estimado e quão perto estiveram as estimativas anteriores da mesma organização.
- Quem é o patrocinador e com que frequência real aparece — não no organograma, na agenda.
- Se o relatório de status mostra projetos em vermelho: um portfólio todo verde é um portfólio sem informação.
Como leio esta publicação
Se isto chegasse à minha mesa, a primeira coisa que eu pediria não é o avanço percentual: é a lista de decisões pendentes com nome e data. O percentual dá para maquiar; uma decisão travada há três semanas com um responsável identificado não dá para discutir, e explica o atraso muito melhor.
A notícia original está publicada em outro idioma; o trecho é citado como o veículo o entrega e o comentário é escrito em português.
Comentários
Ainda não há comentários. O primeiro pode ser o seu.
Está vivendo isso na sua equipe?
Abra o chat e me conte como estão lidando com isso. Tenho interesse em comparar notas.
