One of a development’s department most critical endeavours is Change Management. Even in a technological environment, people tend to use those tools and methodologies that they are more comfortable with. Stepping into the unknown throws your workers off-balance, affects their confidence and increases the chance that something might go wrong somewhere.
Switching paradigms brings most often the biggest issue. It’s not just about a change of tools, but a transition of thinking models: suddenly, the old way of doing doesn’t cut it anymore. There will be a strong learning curve while your teams learn what works, and what does not. And chances are high that they’ll be going back to their code then and again, refactoring what was considered a “closed feature” since their lack of awareness regarding the new culture might have brought an increase of technical debt.
It’s important to allow your people to adjust and learn to do things consistently better. A strong foundation will reduce unforeseen consequences in the future. If you are using an agile approach such as scrum, consider halving your velocity for a few sprints. Yes, that much! This will allow room for tampering, experimenting, investigating and fixing mistakes. A “sprint zero” of sorts is highly encouraged. Something as simple as a freeform week to test new stuff will do wonders with the outcome of your migration.
Take things slowly. If there are several teams or projects, work on your transfer one step at a time. Turning the department upside down with innovation could bring things to a halt, which we obviously do not want. Instead, turn your workers into “ambassadors” of change. A team that has successfully undergone their change process can support the rest of their coworkers. A meetup or knowledge transfer space smoothens the bumps in the road, as some other colleague might have run into the same issue that is blocking a team’s effort. If they work together, they are building a strong sense of community, and actively creating business culture.
After the whole ordeal is behind, your duty is not yet done. Now it’s the time for feedback gathering. You should be able to get some KPIs, or retrieve hard data that backs up what these improvements were trying to accomplish. Are things back on track? What are the rougher spots? Are further actions or refinements to be taken care of? These are the questions that you should find answers for.
If things are not going as expected, you should ask yourself: what to do if things do not get better? There is no easy answer to this question, but your own workers will help you figure it out. Listen to their feedback to find the missing pieces in your puzzle, and prepare a new plan to tackle those issues. Change management does not happen overnight, nor it ever truly ends!
Also published on Medium.