I used to think I was an Agile consultant. More and more, I'm realising I'm actually a transparency specialist who occasionally talks about sprints.

Two weeks into what should have been a routine agile coaching engagement, I found myself standing in front of a whiteboard covered in sticky notes, looking at six squads all trying to chop down the same tree. The organisation had all the right language - squads, tribes, product owners. They'd called me in to "help improve their agile delivery" and "uplift team maturity."

But something wasn't right. I was about to launch into another maturity assessment when I caught myself.

"Look," I said to my executive sponsor, "we need to get our hands on some real work here. Let's run a workshop and take on the biggest, most difficult project. I'll run it through my visualisation and transparency process. We'll put it all up on the wall, recut the work, and redo the roadmap. That'll give us understanding of just how long this is going to take."

That workshop was the start of a hunch that's grown into a core part of my business - and what I now do on every single engagement, whether it's in the contract or not.

Why I Always Turn The Lights On First

Here's what I've learned: it's often the exception when I walk into an organisation that's invited me to "help them be more agile" and discover that's actually what they need. What they really need - what they desperately need - is to see what the hell is going on in their own system.

In that workshop, we got representatives from all the teams in the room and put everything on the board. The reaction was immediate: "Can we plan like this all the time from now on?" The real challenge became visible - cross-team dependencies where everyone was bumping into each other, all chopping down the same tree. Making it transparent helped everyone see and sequence the work, then co-create a joint plan. When we estimated it, we could ask for more funds.

They didn't need more agile practices. They needed visibility into their actual work.

Ken Schwaber and Jeff Sutherland didn't just make up the three pillars of empiricism when they created Scrum - they borrowed from actual process control engineering. The Scrum Guide explicitly states that "transparency enables inspection. Inspection without transparency is misleading and wasteful." It's a sequential dependency, not a nice-to-have.

Here's what I've learned: organisations think they want the agility part (faster delivery, better products, happier customers) without doing the transparency part first. They want to skip straight to being adaptive without first making their system visible.

We're trying to fix car engines in complete darkness.

What Really Happens When You Can Finally See

This pattern keeps repeating. I was recently working with a vendor in a large complex organisation where both the CEO of the vendor company and my executive came to me separately saying, "We can't see what's going on." The vendor was worried they weren't delivering value, and the customer was convinced they'd never get what they'd paid for. It had escalated to the point where they were about to go to court seeking damages.

I did the same thing - mapped all the work, put it on the wall, figured out what needed to be done. The missing piece became visible immediately: the vendor was being sneaky about the capacity they were allocating. They had no standing capacity allocated to the roadmap of work, which meant there was no way to know how fast they'd burn through the backlog or when they'd have delivery confidence.

The brutal transparency of seeing all the work against actual available capacity solved the problem. No court case needed.

Once transparency is established, something shifts. Teams start asking different questions:

• "Why do we have so much work-in-progress?"

• "Who decided these were the priorities?"

• "What's actually delivering value here?"

They begin to inspect their newly visible system. And then - only then - can they adapt. The practices that emerge depend entirely on what they discover about their context and constraints.

The Research Validates What I See Every Day

I'm not just making this up based on my war stories. Multiple data sources paint the same picture:

Our own research across 219 global organisations in the 2024 Global Work Management Tooling Report shows that when organisations evaluate tooling requirements, the top ask is for visibility. Only 39.2% of organisations have a documented tooling strategy, and 92% prioritise internal visibility - yet most are missing crucial external feedback loops that drive real value.

McKinsey research shows that 70% of large-scale transformations fail, with "not having alignment on aspiration and value" as a primary cause - which is fundamentally a transparency problem. When BCG dug deeper into 11,500+ employees across 40+ companies, they found that only 12% of employees in failed transformations report structured knowledge sharing, compared to 93% in successful ones.

The State of Agile Report consistently shows that 59% of organisations cite increased collaboration as the #1 benefit from agile, with 21% specifically citing increased visibility as a top-five benefit. But when you look deeper, 63% of organisations have visibility into the agile pipeline, while less than half report complete visibility into development and delivery.

Academic research covering 42 industrial cases found that "visibility and transparency" represents one of three major challenge areas in agile transformations. A systematic literature review published in the Journal of Software: Evolution and Process identified that transparency challenges are "strongly identified" across failed transformation attempts.

The pattern is clear: Organisations that establish transparency first succeed. Those that don't struggle.

Why I Do This Whether You Ask For It Or Not

I get called by large, established enterprises who are navigating complex transformations. Banks, insurance companies, government agencies - organisations with deep expertise in their domains who are working to adapt their delivery models. And here's what I've learned: many people in these organisations genuinely believe things are working fine. The reports look good. The meetings happen. The budgets get approved.

But the research tells a different story. BCG's research shows digital natives achieve 2.5x higher returns than the S&P 1200, while the State of Agile Report reveals small companies report 52% satisfaction with enterprise agile effectiveness versus only 43% for large companies. The performance gap is real, and it's getting wider.

That's why I always do the transparency work first, even when it's not in scope. Even when clients don't ask for it. Even when I'm not being paid for it.

Because I've learned that everything else we might do to improve business agility - whether it's changing operating models, improving delivery approaches, or redesigning work systems - starts with understanding the current reality.

As Mike Cohn notes, "transparency is often referred to as one of the three pillars of agile" and should be practiced as "total transparency" within teams. This isn't just theory - transparency is the foundation that makes adaptation possible.

Toyota's entire Production System, as documented by James Womack and Daniel Jones in their MIT research, is built on the principle of making problems visible before you can solve them. Their Gemba walks, Andon systems, and visual management aren't just nice-to-haves - they're the foundation that makes continuous improvement possible.

You can't fix what you can't see.

My Professional Standard

So here's what I've learned: I'm an agile consultant who helps organisations build their capability to adapt and respond to change. But I've discovered that transparency work always comes first. Sometimes the solutions that emerge look like familiar approaches. Sometimes they're completely bespoke to the organisation's context and constraints.

What they always have in common is that they're based on a clear understanding of the current reality, because you can't make good decisions with bad information.

That's why I always start with transparency work. It's become my professional standard. Before we talk about sprints or standups or retrospectives, we need to turn the lights on and see what's actually happening.

Make the work visible. Make the problems visible. Make the disconnects between strategy and execution visible.

It's going to be challenging. The complexity has built up over time, layer upon layer. People have accepted invisible, wasteful ways of doing things because they feel powerless to create change in what seems like a frozen system. Unscrambling that egg of complexity isn't easy, but it's the only way forward.

But transparency is transformative. There's an old saying that once you truly see something that's been unconsciously influencing your perspective, it loses its power over you. You can finally choose what to do instead of just acting habitually.

That's exactly what happens when we make work systems visible. Once you can see the system, you can change the system. And that's when real agility becomes possible.

Everything else is just guessing.