Don’t Hide the Work, Show it

I was a few weeks into coaching a Scrum Master when I watched her team almost throw away one of the best opportunities they had all sprint. We walked into the Sprint Review, the project sponsor was on the call, and the meeting opened with: “Alright, we got a lot of work done this sprint. We don’t really have anything to present, but wanted to see if anyone has any questions.” I felt my stomach drop a little. They had done real work. Good work. And they were about to let it stay invisible. 

Here’s what I’ve noticed after years of coaching teams through moments like this: the work people are most nervous to show is usually the work most worth showing. 

The Hesitation Isn’t About the Work

It’s rarely about quality. The team I was coaching had architectural diagrams, real documentation, and a working build in a non-production environment. What they didn’t have was the confidence that any of it counted as “done enough” to put in front of an executive sponsor. 

That hesitation comes from somewhere honest. Most of us were trained, somewhere along the way, that you only show finished things. Polished things. Things with no rough edges. So when the work is genuinely in progress, the instinct is to apologize for it or hide it entirely, even when hiding it costs everyone the chance to get real feedback while it’s still cheap to act on. 

Safety Has to Be Said Out Loud, Not Assumed

In the moment, I jumped in. I told the team I knew how hard they’d worked over the past two weeks, and I wanted to clarify the actual intent of the meeting: it’s safe to show unfinished or non-working software here. I asked if we could pull up the architecture diagrams and walk the sponsor through what had been built so far. 

This is the part that’s easy to miss: psychological safety in a meeting like a Sprint Review doesn’t show up on its own just because someone says “feel free to share.” Someone has to actively name what’s allowed, in the moment, before the team will trust it. One team member pulled up a flow chart in Lucid. Twenty minutes later, we had genuinely useful dialogue with the stakeholders and the sponsor, the kind that only happens when people feel safe enough to show something not yet finished. 

Visibility Builds the Trust That Funds the Next Sprint

Once the ice was broken, momentum did the rest. I asked if there was anything else worth showing, and one of the developers asked, almost cautiously, “We have some demo work in a non-production environment. Is it okay to show that?” I said sure. We spent another twenty minutes looking at actual working software. 

By the end, the executive sponsor thanked the team, genuinely, for the insight into what had been accomplished. He left with a clear picture of where things stood and the ability to give real direction on what might need to change. None of that happens in a meeting that opens with “we don’t really have anything to present.” Patrick Lencioni’s The Five Dysfunctions of a Team makes the case that trust is the foundation everything else gets built on, and trust isn’t built by hiding the rough draft. It’s built by sharing it. 

The Real Lesson Isn’t About Sprint Reviews

It’s tempting to read this as a Scrum ceremony story. It’s not, not really. The actual lesson is bigger: the moments we’re most tempted to minimize, apologize for, or skip entirely are often the exact moments our stakeholders, our leaders, our teams most need to see. Every team has value, but that value stays invisible if nobody’s willing to put it on the table while it’s still a work in progress. 

The next time you catch yourself or your team saying “we don’t really have anything to show,” stop and ask what’s actually true. You almost certainly have something. The only question is whether you’re willing to let people see it before it’s perfect. 

If you want a practical place to start: this week, find one piece of unfinished work you’ve been sitting on, whether it’s a draft, a half-built process, or an idea you haven’t pitched yet, and show it to one person whose opinion you trust. Not because it’s ready. Because feedback now is worth more than polish later.