Two companies introduce Agile. Both send employees to the same training courses, both hire experienced coaches, both invest significant resources. One year later: one company delivers faster, responds more flexibly to market changes, and has more motivated teams. The other has new meeting formats, new job titles, new boards on the walls—but nothing has really changed.
The difference is not the budget. It is how each approached the best practice. One company copied the method. The other decoded the logic behind it.
Successful leaders do not copy best practices. They break them down analytically and build something of their own from them. That is the difference between copy-paste and reverse engineering.
A division head I supported had had exactly this experience. His company had introduced Scrum, with all the ceremonies: sprints, standups, retrospectives. After six months, the meetings were established, but the results had not improved. His diagnosis: “We copied the packaging, but we did not understand the content.” He was right. In the standups, the team read out to-do lists without any real coordination taking place. The sprints ended with unfinished outcomes because decision cycles in the company took four weeks, not two.
When engineers analyze a competitor’s product, they do not copy the shape. They take it apart, understand the design principles, identify the design decisions, and use those insights to build something optimized for their requirements.
Copy-paste asks: “What did Company X do?” Reverse engineering asks: “Why did it work, and what does that mean for us?” The difference sounds subtle, but it is fundamental. Copy-paste adopts the visible solution. Reverse engineering understands the invisible problem and the principles that led to the solution.
The path there consists of four steps.
Every best practice is an answer to a specific problem. Before you adopt the answer, you must understand the question.
Agile emerged in the 1990s because software projects regularly failed. Teams worked for years on products that were already outdated by the time they were delivered. The problem was the long time between requirement and feedback. If clients only saw what was built after two years, it was too late for corrections. So the problem was: feedback cycles that are too long lead to products that miss the mark.
The first question you need to ask yourself: Do we have the same problem? Or do we have a different problem for which we are looking for a solution? Sometimes the problem is not “feedback cycles that are too long,” but “unclear responsibilities” or “lack of prioritization”. Agile does not solve these problems.
Context is just as important. Agile emerged in small software teams with high autonomy, direct client contact, low cost of errors (software can be changed), strong technical competence among team members, and clear delivery units (software can be broken down into working increments). These conditions do not exist everywhere. In a company with a strong hierarchy, autonomy is lacking. In regulated industries, the cost of errors is high. In complex production environments, there are no clear increments. The second question: Which of these conditions are met for us? Which are not? What does that mean for transferability?
Behind every practice is a principle—a fundamental insight that is valid regardless of context. The principle is transferable, even if the practice is not.
| Practice (context-dependent) | Principle (transferable) |
|---|---|
| Two-week sprints | Short feedback cycles reduce the risk of working past what is needed. |
| Daily standups | Regular synchronization prevents problems from escalating. |
| Retrospectives | Systematic reflection enables continuous improvement. |
| Cross-functional teams | Fewer handoffs mean less friction. |
These principles also apply outside software development. Short feedback cycles are just as valuable in mechanical engineering as they are in IT, but they look different there. Harvard professor Clayton Christensen described this thinking as “Jobs to be Done”: do not understand the product, but the job it gets done. A best practice is a product. The principle is the job.
The third question: What principle is behind the practice? Is this principle relevant to our situation? If you cannot formulate the principle in one sentence without naming the practice, you have not analyzed deeply enough.
Only now does it become concrete. You lead a department in a regulated industry. Two-week sprints are unrealistic; your projects have regulatory dependencies, long approval cycles, and complex stakeholder landscapes. But the principle—short feedback cycles—is still relevant.
Your adaptation could be: milestone validations instead of sprint reviews—regular checkpoints with executives before projects go too far in the wrong direction. Pilot-phase checks where you show and validate concepts, prototypes, or partial analyses early. Structured correction points where you can adjust direction, rather than only at the end of the project.
This is not “Agile light.” It is an independent approach based on the same principle, but one that works for your context.
The difference between companies that benefit from best practices and those that fail because of them is not luck. It is the ability to understand solutions instead of copying them.
Reverse engineering is more demanding than copy-paste. It requires analysis, reflection, and experimentation. It takes longer before you can start. But it has three decisive advantages.
It works. An adapted solution fits your organization. It meets less resistance because it takes your reality into account—not the reality of some technology startup.
It builds capability. Those who reverse-engineer best practices understand the mechanisms behind them. This capability is transferable. Next time, it will be faster.
It creates ownership. A solution you develop yourself belongs to you. Your teams helped shape it. That creates commitment, not compliance.
Before you adopt the next best practice, answer these questions.
If you get stuck on question three, you have not analyzed deeply enough.
Best practices are valuable—but not as blueprints. Their value lies in the documented problem-solving knowledge they contain. Unlocking that knowledge requires analysis, not copying.
The next best practice someone recommends to you is an answer. Make sure you know the question before you adopt it.
Tomorrow, take a method or practice that has been introduced in your organization. Ask yourself: What problem was it supposed to solve? Is that still our problem? And does the solution work in our context? If the answer to any of these questions is no, you have found your starting point.
Resistance is information – When best practices fail, resistance within the organization is often the first signal.
The art of saying no – If you cannot say no, you do not have a strategy of your own.
Proven tools and models for self-application are available under Solutions.
If you want to take these thoughts further for your company, a no-obligation initial conversation is worthwhile.
