When Best Practices Become Worst Practices

How do context-dependent practices become universal rules?

Practices become universal rules through a 3-step process: a successful organization publishes what worked for them, an industry ecosystem (conferences, consultants, certifications) strips the context, and other organizations adopt the practice without the conditions that made it work.

I studied the adoption of daily standup meetings across 8 engineering organizations. The practice originated in the Scrum framework, designed for co-located teams of 5-9 people working on a shared product in 2-week iterations. Of the 8 organizations I observed, only 2 matched those original conditions. The other 6 had distributed teams, team sizes of 12-20, mixed project portfolios, or continuous delivery cycles. In all 6 mismatched organizations, the daily standup consumed more time than the coordination it provided was worth. Engineers reported spending an average of 14 minutes per day listening to updates irrelevant to their work.

The practice had been canonized. “Everyone does daily standups” became a belief, disconnected from the conditions under which standups produce value. The organizations that questioned the practice felt heretical. The ones that adopted it uncritically felt professional.

What are the warning signs that a practice does not fit your context?

The 3 warning signs are: the practice solves a problem you do not have, the practice requires preconditions you cannot meet, or the practice produces compliance rather than outcomes.

At a 300-person organization, I observed the adoption of OKRs (Objectives and Key Results) because “Google uses them.” Google has 180,000 employees, a portfolio of hundreds of products, and a strategic planning infrastructure that has evolved over 25 years. The 300-person organization had 2 products and a planning process that consisted of a quarterly conversation between the CEO and 4 VPs. OKRs added 3 weeks of planning overhead per quarter to produce documents that the CEO and VPs ignored in favor of their quarterly conversation. The practice solved a coordination problem that the 300-person organization did not have.

I have written about a related pattern in the OKR trap: the framework itself is not the problem. The uncritical adoption is. Practices are tools, not religions. A hammer is an excellent tool when you have nails. Adopting it because carpenters use it does not help if you are painting a wall.

How do you evaluate whether a practice fits your organization?

Evaluate fit by asking 4 questions: what problem does this practice solve, do we have that problem, do we meet the preconditions, and can we measure whether it is working within 90 days?

• Problem identification: Name the specific problem the practice addresses. “Improved communication” is not specific. “Engineers on Team A do not know what Team B is working on, causing integration conflicts averaging 6 hours per sprint” is specific. If you cannot name the specific problem, you are adopting a solution without a problem.
• Precondition audit: List the conditions under which this practice was designed to work. Team size, colocation, iteration cadence, organizational structure. Compare to your actual conditions. A mismatch in any precondition is a reason for adaptation, not adoption.
• 90-day measurement: Define a measurable outcome before adoption. If the practice does not produce the outcome within 90 days, stop. Not “revisit.” Stop. The sunk cost of 90 days of adoption is already significant. Extending a failing practice because you invested in it is the organizational equivalent of sunk cost fallacy.
• Adaptation over adoption: Take the principle, not the implementation. If daily standups solve a coordination problem but your team is distributed across 4 time zones, the principle (daily coordination) can be implemented as an async daily update rather than a synchronous meeting. Adopting the implementation (a 15-minute synchronous meeting) ignores the constraint that makes it impractical.

What do organizations lose when they follow practices uncritically?

They lose the ability to design processes that fit their specific constraints, outsourcing their organizational thinking to frameworks that were never designed for their context.

The deepest cost is cognitive. Organizations that adopt practices uncritically stop thinking about process design. They consume rather than create. Every team needs to develop the skill of designing its own processes from first principles, borrowing from established frameworks where appropriate but always adapting to local conditions. This is the same principle I described in the agile midlife crisis: the frameworks that were meant to liberate teams from rigid process became rigid processes themselves.

The organizations that perform best are not the ones that follow the most practices. They are the ones that follow the fewest, the right ones, designed or adapted for their specific context. Every unnecessary practice is process debt accumulating silently.