Allow me to start this post quoting the first principle of the Agile Manifesto: “[We value more] Individual and interactions over processes and tools“. The aim of this postulate was to benefit human exchange and improve communication between workers rather than adhere to protocol and bureaucracy. However, I’ve found lately a new meaning if we apply this teaching to the process of adopting new technologies.
You may have heard of “innovators” and “early adopters” in the context of embracing change. These terms are applied to the first two groups that accept a new tool on their process and the amount of social media involved makes it look like some type of “techie award”. Adoption is not – and should not – be a race. Some business’ benefit migration more than others and the important message is to embrace this evolution, and make it your own.
Thus, rushing the change of your tools is something potentially damaging. Adopting software that does not meet your structure is toxic. And changing for the sake of removing the “legacy” tag is doomed to fail. A transition is an organic process, not a magical transmutation. Is more than a management decision, and forcing employees to assume the use of a tool that does not fit their needs will only make things for the worse.
As well, new instruments should be used for what they are, not for what you need them to be. It may be okay to bend the defined limits of a new technology to fully fit in your company culture, but if the software needs heavy customization, or private components to integrate to your existing stack… Well, maybe it’s not the tool for you.
That said, maybe you truly are in the path of a correct technological adoption, and this components or twists are just a necessary evil that will disappear in the long run. That is okay, although it will still be harmful for your department. Make sure that everyone related to this trend movement is up to date, and work towards smoothing out those sticking points in the critical procedures of your mission.
So, if new tools are necessary, just take it easy and don’t perform a half-assed transformation, unless you want to bring the old issues to the new processes.