A new engineer joins a Scrum team in week two. During sprint planning, the team runs estimation poker. She watches, participates, and then asks a straightforward question: Why do we do this?
The answers come slowly. Someone says it helps with planning. She asks how. Someone says it surfaces different perspectives. She asks whether it had ever actually changed a plan. Silence. Then the facilitator says the sentence that closes every conversation like this one: "It's just part of how Scrum works." Meeting moves on. Practice continues.
That moment is not a Scrum problem or an estimation problem. It is a thinking problem. And it is happening on your team right now, probably around something you have not noticed yet, because you stopped noticing it months ago.
Frameworks earn their place. When a team is new or a situation is genuinely complex, a structured framework reduces cognitive load, prevents obvious mistakes, and gives everyone a shared vocabulary. That is legitimate and valuable. The problem is what happens next.
Over time, the framework stops being a scaffold and starts being load-bearing wall. Teams confuse doing the ceremony with achieving the outcome. The daily standup that was supposed to surface blockers becomes a status report nobody acts on. The retrospective that was supposed to drive change becomes a Thursday ritual where the same three complaints cycle through. The planning session that was supposed to align effort with value becomes a negotiation over story points that everyone knows are fictional anyway.
This is not cynicism about frameworks. It is an observation about how human teams interact with systems over time: we optimize for compliance with the system, not for the purpose behind it. The framework becomes the answer to every process question, which means it also becomes the end of every process question.
These two things feel similar from the inside and look identical from the outside. Here is how to tell them apart:
| Process Maturity | Process Dependency |
|---|---|
| Team can explain why each practice exists | Team cites the framework as the explanation |
| Practices are adjusted when context changes | Practices run unchanged regardless of context |
| New members' questions improve the process | New members' questions are socialized away |
| The team owns the process | The process owns the team |
The critical diagnostic is how your team responds to the new hire who asks why. If the honest answer is "we'll explain the framework to you and then it will make sense," you are probably in dependency territory. If the answer is "here is the outcome we are trying to reach and here is why this practice has been the most reliable path to it," you have maturity.
Before you schedule a ritual audit, acknowledge the real cost of what frameworks provide. Questioning every practice all the time is exhausting, destabilizing, and expensive. Teams that relitigate their entire process every sprint do not ship. There is a genuine reason experienced teams stop questioning certain things: cognitive bandwidth is finite, and stability has value.
The goal is not permanent skepticism. It is periodic, deliberate review rather than permanent, unexamined compliance. The distinction matters because it determines what you actually do on Monday morning.
There is also a political trade-off. Questioning a practice that has organizational buy-in, that your PMO mandated, or that a senior stakeholder championed is not a neutral act. Sometimes the right answer is to run an imperfect ritual for legitimate political reasons while being honest with your team about why. That is a choice, not a failure, as long as you are making it consciously.
Once a quarter, pick one team practice that nobody questions. Not the hardest one, not the most politically charged one — just one. Run it through these four questions:
You do not need a formal process for this. Fifteen minutes at the end of a retrospective is enough. The point is not to kill rituals. The point is to force the team to articulate why each one earns its slot on the calendar.
You will get one of three outcomes from this exercise:
The meta-skill you are building here is the habit of treating your process as a hypothesis rather than a given. Frameworks are not wrong. They encode a huge amount of hard-won wisdom about how teams typically fail. But typically is not always, and your team's specific context, maturity, domain, and stakeholders are not typical. They are specific. Your process should reflect that specificity.
Return to that engineer in week two. Her question was not naive — it was the clearest signal your process review system can produce. Someone without the habituation to your rituals looked at one and could not see the value. That is data.
Build a deliberate practice of capturing new-hire questions about process during their first thirty days. Not to answer them immediately, but to log them. Those questions are pointing at exactly the places where your team has mistaken familiarity for wisdom. They are not problems to be socialized away. They are the starting point for the next quarterly audit.
Experienced PMs earn their reputation by knowing what good looks like. Part of what good looks like is a team that can answer why we do what we do without pointing at a framework guide. Frameworks should earn their place continuously. Your job is to make sure they do.
Based on: Your Framework Has Been Doing Your Thinking. That's the Problem.
PM Master generates a Charter, WBS, Risk Register and 20+ PMBOK® 8 documents from your notes.
Try it free →