Many agile techniques such as Kaizen, Sashimi or Kanban correspond to terms and principles found in asian culture. A less known principle is:
“Do not develop an attachment to any one weapon or any one school of fighting”
– Miyamoto Musashi
In the context of agile it means that one should change the process if it helps to achieve the goals. This is something most developers would agree to as processes are often seen as impediments.
The same applies to technology. Translated to the technical world it reads: Do not stick to your favourite technology if there is something better suited to meet the project or customer needs. This is something many developers would not immediately agree to. Developers usually love sticking to their JEE, Spring, .NET, SOAP, REST, [any other technology] with which they grew up. They often argue that learning a new technology is time consuming and therefore hardly possible to change.
I think that is wrong. Provided a developer has a sound background, he or she can become productive in a new technology within a short time. I’ve seen developers switching from JEE to .NET and vice versa without problems. This is possible because technology always evolves. Most new frameworks and programming languages do not reinvent the wheel. The are always based on similar common principles which remain valid and stable over time. It is more a matter of mindset that keeps people trapped in their technology comfort zone.
Is that a problem?
Sometimes yes, especially when paired with Groupthink, it hinders innovation and production efficiency.
How can this prevented?
1. Make sure you have people with long standing experience in different technology domains in your team. People who worked with multiple technologies are usually more willing to reflect technology decisions and align them to the requirements of the business.
2. Don’t start a project with a strong technology committment. Let the team decide which technology is best suited to solve the business problem. Of course in conformance with the corporate standards.
3. Ensure that the team has the freedom to decide which tools they want to use.
Having the option to change weapons (processes, tools, frameworks, etc.) if needed, improves the likeliness of successful project delivery.