Why software delivery keeps failing for reasons everyone can see but nobody names
I have sat in hundreds of delivery reviews over the past two decades. Retrospectives, quarterly planning sessions, post-mortems, leadership offsites. The problems on the whiteboard change. The faces around the table change. The tools, the frameworks, the vocabulary — all of it changes.
The problems do not.
Same missed commitments. Same coordination failures. Same gap between what gets built and what the business actually needed. Same exhausted teams who tried harder this quarter than last quarter and still ended up in the same place.
For a long time, I assumed the answer was better practices. Better frameworks. More disciplined execution. I spent years helping organizations adopt Agile, Lean, SAFe, DevOps. Some of it helped. Most of it helped temporarily. And then, reliably, the same problems came back wearing slightly different names.
It took me longer than I would like to admit to understand what was actually happening.
The problem was never the practices. The problem was what the practices were operating inside.
What a constraint actually is
In software delivery, we talk about blockers. We talk about dependencies. We talk about impediments and risks and technical debt. We almost never talk about constraints.
A constraint is not the same as a blocker. A blocker is something in the way of a specific piece of work. You remove it and the work moves forward. A constraint is something in the structure of the system itself — a boundary condition that shapes how every piece of work behaves, regardless of how skilled the team is or how good the process is.
Funding cycles that force annual commitments on work that needs to be validated quarterly. Incentive structures that reward Product for shipping roadmap items and reward Engineering for system stability simultaneously, on the same team, in the same sprint. Regulatory requirements that constrain architecture decisions three layers removed from where any delivery conversation is happening. Shared services that set their own priorities independent of the commitments made by the teams depending on them.
These are not blockers. You cannot remove them in a standup. They are features of the organizational environment. Some of them deliberate, some of them inherited, some of them invisible until something breaks.
And here is the thing that took me years to fully accept: most of the recurring delivery problems I have ever seen were not caused by teams failing. They were caused by teams succeeding doing exactly what the system rewarded them to do inside constraints that made the outcomes the organization wanted nearly impossible.
Why constraints are the most underplayed dimension of software delivery
If constraints are this fundamental, why does almost no delivery methodology talk about them honestly?
I think there are three reasons.
The first is that frameworks need to be sellable. A methodology that says "some of your problems cannot be fixed without changing how your executives are evaluated" is a hard room to sell to. A methodology that says "adopt these practices and your teams will improve" is a much easier conversation. The comfortable story wins the training budget. The honest story gets quietly ignored.
The second reason is that naming constraints is politically uncomfortable. Most real constraints in large organizations are not technical. They are human. They live in the incentive structures that senior leaders designed, the funding models that finance approved, the governance processes that compliance built. Naming a constraint honestly often means saying out loud that a powerful person's decision is producing a predictable bad outcome. That is not a conversation most coaches or consultants are willing to initiate, and it is not a conversation most organizations reward people for having.
The third reason is that our vocabulary is wrong. We have the language of problems — symptoms, root causes, blockers, impediments. We do not have a shared language for the difference between a constraint you can eliminate, a constraint you can work around, and a constraint you have to accept and design within. Without that vocabulary, every constraint gets treated the same way: as a problem to be fixed, usually by the team closest to it, usually without the authority to fix it.
The consequence of not naming them
When constraints go unnamed, they do not disappear. They just get blamed on something visible.
The team that consistently misses cross-team deadlines gets labeled as a communication problem. The product that consistently misses the mark gets labeled as a requirements problem. The organization that consistently fails to sustain improvements gets labeled as a culture problem.
None of those labels are wrong, exactly. But none of them are the real cause. They are the symptom the constraint produces. And because the symptom is what gets addressed with more process, more tracking, more accountability, the constraint continues to operate underneath, generating the next version of the same problem on schedule.
I have seen organizations run four retrospectives on the same problem. I have seen them commission consultants to diagnose the same failure twice. I have seen talented, motivated engineers quit because they were held accountable for outcomes produced by a system design they had no power to change.
The cost of unnamed constraints is not just delivery performance. It is the credibility of every improvement effort you launch. It is the engagement of the people who can see the real problem but have learned that naming it is not safe. It is the compounding organizational debt of problems that never get resolved because they never get correctly identified.
What changes when you name them
I want to be honest about what constraint awareness does and does not do.
It does not make constraints disappear. Some of the most damaging constraints in large enterprises — funding model rigidity, regulatory architecture requirements, misaligned executive incentives cannot be resolved quickly. Naming them does not change that.
What naming them does is change what kind of conversation is possible.
Instead of "why did this team miss the deadline again," the conversation becomes "what constraint is producing this outcome and what category does it fall into." Instead of "we need more accountability," the conversation becomes "the team is accountable for an outcome they do not control — what would have to change for that to be different."
Those are leadership conversations. They are harder than process conversations. They require someone in the room with enough authority and enough honesty to say: the system we built is producing this result. Not the team. The system.
In my experience, that conversation had at the right moment, with the right people, grounded in a real and current example is more valuable than any framework rollout or coaching program I have ever been part of.
That is why at Entrowise, we believe the most important coaching moment is not in a workshop. It is in the room where a real constraint is producing a real problem, right now, and a leader is willing to name what is actually happening.
We call that Just-in-Time Coaching. And it starts with the constraint.