Have you encountered issues of intellectual property in your organisation’s Agile journey?

I agree that combining practices from different disciplines is not the issue by itself. Most organizations naturally adapt methods over time depending on their context and challenges.
What I’ve seen become problematic is when scaling introduces so much structure, reporting, and standardization that teams lose flexibility in practice.
Sometimes the language still sounds Agile, but the environment starts feeling much more control-driven than adaptive.

Yes, I have seen this tension emerge in Agile transformations, especially when organizations scale quickly and adopt practices from Lean, Lean Six Sigma, Project Management, quality management, or flow-based approaches.

In my view, the issue is not that Agile incorporates ideas from other disciplines. Management knowledge has always evolved through adaptation, integration, and recombination.

The ethical concern begins when those practices are presented as “new Agile” without enough transparency about:
• Where they originated,
• Why they are being adopted,
• What problem they are intended to solve,
• What trade-offs they introduce.

This is especially important in a competitive certification and framework market, where language, branding, and originality claims can easily shape perception.

I also think we need to distinguish carefully between Lean, Lean Six Sigma, traditional management approaches, and Agile. They have different origins and purposes, even if they later influenced one another significantly.

Standardization is not inherently anti-Agile. Some structure can support coordination, learning, quality, and flow at scale.

The real risk begins when structure stops enabling adaptation and starts constraining it.

At that point, the issue is no longer only intellectual property. It becomes a question of transparency, trust, authenticity, and organizational integrity.

An important and valuable discussion for the profession.

Stelian ROMAN I agree that practical experience matters enormously.

Coaching teams, managing products, dealing with delivery pressure, trade-offs, conflict, prioritization, and organizational reality cannot be learned only through short certification paths.

At the same time, I would be careful not to reduce the issue to a simple distinction between certificates and experience.

I have also seen highly experienced professionals apply Agile mechanically, without a deeper understanding of systems thinking, product dynamics, flow, organizational behavior, or adaptive leadership.

The deeper issue may be that Agile coaching scaled commercially faster than the profession developed the operational maturity and conceptual depth required to sustain that growth.

When frameworks become products, certifications become market signals, and scaling becomes the priority, there is a natural risk of simplification, rebranding, and loss of conceptual integrity.

In practice, good coaching usually requires a combination of:

• Practical experience,

• Contextual judgment,

• Understanding of management and product systems,

• Facilitation capability,

• Intellectual honesty about the origins, strengths, and limits of the practices being used.

That combination is much harder to certify than a framework alone.