Stop Admiring the Problem: Why Your Team's Rigor is Actually Procrastination
Is your team building "shrines" to their problems? Learn why analysis is often procrastination in a suit and how to use the "Line of Code Test" to force action and stop the delay.
Analysis feels like diligence, but it's often just a shield against being wrong. Here is how to break the loop.
Your team isn't being thorough. They’re using analysis as a sophisticated form of procrastination, a way to avoid the vulnerability of being wrong. I know. I’ve let my teams do it for years.
The story of my meeting with Ray Arell at Agile Open Northwest in March 2026 is one where a simple session title brought a specific brand of stagnation into focus. He proposed the topic "Don't fall in love with the problem." It hit me immediately. We spend years in the trenches trying to build delivery engines. We shorten feedback loops. We automate pipelines. We try to kill the friction between an idea and a customer interaction.
Instead, we accidentally build complex shrines to our problems.
Y'all know the feeling of sitting in these meetings. The conversation is intense. The people debating the architecture are brilliant. The edges of the problem get sharper, more defined, and endlessly documented in Jira. And absolutely nothing moves. The analysis itself becomes the work.
This is a delivery crisis wearing a suit. It looks like thoughtfulness and sounds like rigor, but it’s just a systemic failure to act. We’re all guilty. I’ve spent months of my life in windowless Zoom calls polishing problems that didn't matter.
The Illusion of Diligence
I see this flavor of stagnation on nearly every team I coach. It manifests in predictable, destructive ways.
Teams re-litigate the same architectural trade-offs every sprint. A decision gets made on Tuesday, but by Thursday morning, someone introduces a hypothetical edge case. The decision gets unmade. The debate restarts. The board remains static.
Demand for more data becomes a shield against making low-stakes, reversible decisions. Teams treat a 1% outlier as ironclad proof that the other 99% cannot be addressed.
Writing exhaustive documentation for ghosts is the ultimate distraction. I once watched a team spend three days mapping out error handling for a third-party API that the business hadn't even purchased. We operate under the delusion that gathering more data is a safe, cost-free activity.
It is not.
I’ve built these shrines myself. Back in '22, I let a team debate a database schema for three weeks because we were "anticipating scale." We obsessed over shards and latency for a product that had zero users. The outcome? They were wrong anyway. We never hit the traffic levels that would have made that schema relevant. I watched three weeks of salary evaporate while we argued.
This is the same dynamic I've seen where people prioritize the appearance of activity over the reality of outcomes. The longer this goes unaddressed, the more it calcifies. It stops looking like a bottleneck and starts looking like just "how things are done here."
Don Reinertsen's research on the Cost of Delay shows that human intuition underestimates the economic impact of delayed action by a factor of 50 to 1. We think waiting a week to be absolutely sure costs nothing. We are catastrophically wrong.
Consider Maersk Line. When they ran the numbers on their Cost of Delay, they discovered that features sitting in queues—waiting for analysis, waiting for certainty—were bleeding $200,000 a week. Even if you’re a 10-person shop, that one-week delay is still a burn you can't afford.
The cost isn't just financial. I’ve watched this indecision trigger employee churn—sometimes up to 20%. Your top performers do not leave because the work is hard. They leave because they lose trust in a system that refuses to move. They get tired of watching good ideas die in committee.
The Cynefin Reality Check
We often misunderstand the nature of the work. Dave Snowden's Cynefin framework explains why our rigor fails so spectacularly.
We treat software development like a complicated problem. We act as if we are building a car engine. In a complicated domain, cause and effect are linked. If you have enough expert analysis, you can deduce the right answer before you turn a single wrench.
Software is complex. It is an ecosystem of unknown unknowns. The conditions shift constantly.
In a complex system, analysis without action is a hallucination. You’re guessing. You’re navel-gazing. You’re trying to solve a puzzle where the pieces move every time you look at them. The system only reveals itself when you interact with it. You can only probe, sense, and respond. You have to run a safe-to-fail experiment.
I’m not talking about flight control software or heart monitors. If you're in MedTech or Fintech, the rigor is the product. I’m talking about the 90% of features where the risk of being wrong is lower than the cost of being late. Refinement is only useful up to the exact moment you can design that experiment. Every minute spent debating past that point is pure waste.
Watch for the "complexity shield." When teams use edge cases to argue that action is premature, separate the genuine risks from the ones serving a different purpose. Some concerns are real. Others are just a socially acceptable way to avoid trying something that might fail.
Look at the indispensable expert on your team. Their constant busyness often functions as a bottleneck. The team organizes itself around their expertise, demanding their blessing before any code gets written. If that expert wins the lottery tomorrow, the team stops. That isn't rigor. That is a single point of failure masking a fear of delegation.
The Line of Code Test
Problem admiration hides in plain sight. As a Scrum Master or Agile Coach, your job is to spot the camouflage and break the loop.
When a refinement discussion starts circling the drain, you need a circuit breaker. Use the "line of code test."
Interrupt the debate and ask: "Can anyone name the specific piece of code, configuration, or process step that would change first?"
If they can name it, the conversation stops and the work starts.
If they cannot name it, they do not understand the problem as well as they think. More talking won't fix that gap. They need to run a probe.
I’ve heard this described as measuring miles with a micrometer. It is impressive precision applied where it doesn't matter. If the margin of error does not change your immediate next step, stop measuring.
Go to your physical or digital board right now. Create a column called "Admiring." When a work item stalls in endless debate, physically move it there. These are your rotting bananas. Something shifts in the room when the pattern is named. The team starts to self-regulate because the behavior is no longer hiding inside a respectable status like "In Analysis."
Set a strict limit on your waiting columns. When the limit is hit, the team cannot pull new work until a blockage is resolved. Make the stagnation impossible to ignore.
Give them something bad to react to. Bring a rough draft, a skeleton solution, or a deliberately incomplete approach to the next session. It is psychologically easier for humans to improve a flawed idea than to create a perfect one from nothing. The blank page is the enemy.
Finally, address the rotting inventory. Look at your defect graveyard. Everyone has a backlog with hundreds of untouched issues that nobody will work and nobody will close.
Staring at that list is just a way of feeling responsible without being effective. If a defect is genuinely critical, it will resurface. If it isn't, delete it. Declare bankruptcy on the stale backlog and start clean.
The Monday Dare
Remind your team of one fundamental truth: your next release is not your last release. Shipping something imperfect that you can improve beats waiting for something flawless that never arrives.
I do not care what framework you use. I care about what you tolerate.
Try this Monday: Before your next Daily Scrum, go look at your board. Check your last several retrospective action items. Find the aging impediments that have been sitting unresolved for five or more iterations.
Pick one. Walk up to your team.
Ask them directly: "Are we solving this, or are we living with it?"
Stop admiring the problem. Start breaking the loop.
Continue Your Journey
Build, Don't Generate: A strategic framework for shifting your team's mindset away from endless analysis and back toward intentional software architecture.
Practitioner Toolkit: Access tools, templates, and patterns to help you govern your team's workflow and break the cycle of stagnation.