Ninety percent information is always great. But I don't think I've ever actually had that much information before starting a project — even if I thought I did at the time. This is the entire concept of agile: just get in there and do it. Start moving, learn as you go, and adjust course based on what you discover.
It's always hard to argue with someone saying that we need to plan properly or else risk wasting resources on a bad path. That sounds reasonable. But when what you're developing is meant to deliver real value, spending weeks or months in steering committee meetings, design workshops, and stakeholder alignment sessions comes at a cost. You're allowing lots of people a voice, but at the expense of forward momentum.
The Agile Paradox in Corporate Environments
Everyone loves to talk about agile. But in corporate environments, it often feels like the culture of consensus, gatekeeping, and milestones is anathema to a truly agile process — even when the work is organised into two-week sprints.
You can have daily standups, sprint planning, and retrospectives. You can use Jira and track velocity. But if every decision requires three levels of approval, if architecture review boards meet monthly, if stakeholders need to sign off before any code is written — you're not agile. You're waterfall with better marketing.
True agility isn't about the ceremonies. It's about the ability to move, learn, and adapt quickly. And that requires a culture that tolerates uncertainty, accepts that some efforts won't pan out, and trusts teams to make decisions close to the work.
Momentum as Strategy
When I see a project getting stuck in the planning phase, I try to make sure the developers know the direction we're moving in so they can start scaffolding and prototyping a solution, even if we are doing it in a bit of a gray area. That way, they aren't starting from day one when the project actually kicks off.
The key is framing. I make sure to position these early efforts as learning opportunities that should be seen as exploratory rather than production code. I stay in close contact, looking to understand what they're learning. Being able to feed that progress back to committees doing design work provides valuable context that abstract discussions simply can't match.
This isn't about going rogue or undermining the planning process. It's about recognising that doing and planning aren't mutually exclusive — and that sometimes the fastest way to answer a design question is to build something.
Recognising Analysis Paralysis
There are warning signs that a planning process has crossed from "gathering information" into "avoiding a decision."
When meetings start relitigating decisions that seemed commonly agreed, that's a red flag. When debates turn to specific implementation details that likely won't be resolved until we actually start working on the solution anyway, that's another. At that point, more meetings won't produce better answers — only more meetings.
The Prototype That Broke the Deadlock
I once participated in an 18-person design workshop that met twice a week for nearly three months. The end-to-end design had been created. Stakeholders were brought onboard. Then it was thrown out and a whole new design was made. Stakeholders were brought onboard with that one too. Then people started trying to change the direction again.
I took one developer and one of the most critical subject matter experts aside. We spent two days creating a prototype of the tool as it was designed at that moment, and brought it back to the committee.
"Okay," I said. "What is your feedback on this tool?"
Almost immediately, everything changed. Feedback that had been about hypotheticals became concrete direction. Actual gaps in the design were surfaced — gaps that hadn't been mentioned in three months of debate. And suddenly we were weeks from having the tool built and ready for its first round of user acceptance testing.
The High-Fidelity Paradox
In learning about product design, I was taught that it's important to use tools that provide people with a "low-fidelity" prototype so they feel open to providing feedback. Rough sketches invite critique; polished designs make people hesitant to suggest changes.
But no one ever mentioned the opposite: sometimes a high-fidelity prototype is exactly what you need to build consensus and move a project forward.
When a group has been debating abstractions for too long, showing them something real — something that looks like it could ship — changes the conversation entirely. It's harder to argue about theoretical approaches when you're looking at a working tool. The prototype becomes a forcing function for decision-making.
Communicating Uncertainty to Stakeholders
Stakeholders often want definitive answers. They want to know exactly how something will work before they commit resources to it. The temptation is to project false confidence.
I've found it's better to be straightforward: "I don't know exactly how this is going to work, but I know what we're trying to achieve. Let us get to work and come back with some solutions for you."
This approach requires trust. But it also builds trust. When you deliver on that promise — when you come back with something tangible — you establish a pattern. Stakeholders learn that "we'll figure it out" isn't a dodge; it's how good work actually gets done.
The Cost of Waiting for Certainty
Perfect information is a mirage. The more you chase it, the further away it seems. Meanwhile, competitors ship, markets shift, and the window for your solution narrows.
The best leaders I've worked with understand that action produces information. You learn more from two days of prototyping than from three months of design workshops. Not because the workshops are worthless, but because doing reveals what talking conceals.
Get moving. Build something. Bring it back to the room. You'll be surprised how quickly hypotheticals become decisions when people can see what they're actually choosing.