In my experience, if you put two good developers in a room, you are going to have disagreement. That’s why you hired them in the first place so things are challenged. If it doesn’t lead to some resolution, then you have a problem.
I know this is an old topic. But, today I was watching some training videos and came across some suggestions in the area that really apply in a very practical way.
The goal is to come to a final conclusion using something other than opinions, personality, technical papers, war stories, when these kinds of facts are not available. I watch the definition of a four stage process.
- Carve out a low risk area where you can try more than one option, if no option currently exists. Maintain zones that disallow any implementation that is being compared, so current coding methods may continue. This can isolate the method under study to be performed by a limited set of individuals without impacting the whole team.
- Make sure you have fast easy builds. If your new technology slows down the build process too much, you are going to struggle with adoption at a later time. People won’t want to use the new technology if it impacts their work performance too much.
- Offer an escape hatch. Make it so that any work performed in the new technology can be removed should a decision be made not to go forward. Have a built in agreement date when the escape plan will be implemented if it fails to meet expectations. Your escape plan may be as simple as a version control reversion, or even simply dropping a branch created for this test.
- Use positive peer pressure when you have positive results. Share your experience, without a lot of me words. Share how it benefits “us”. Let other developers build up interest in the technology by hearing positive things from you and your colleagues.
This implementation plan was picked up from a presentation by Steve Ogbibene. Thanks for putting this together in a really simple plan, Steve.
Cheers,
Ben