Let me start by describing a fairly common situation. You have a ten-year-old product that has been successful in the marketplace, but new technologies are introducing competitors. There is a need to respond. You have a seasoned team that knows the domain well and is very capable in the existing technologies. Do you retrain your existing team, or do you find a new team with experience in the new technology?
This is a common issue, whether agile or not, so some of my answers will apply to any methodology. At the same time, agile does introduce some unique considerations, and I will try to focus on those in particular. The answer to the question "retrain or replace?" also changes depending upon whether you are using full-time employees versus contractors, but not as much as you might think.
One last caveat before I dive in: my recommendations are purely based on my personal experience and applying agile principles and not based on any empirical studies. I have close to 40 years in IT as a developer, development manager, program manager, director and consultant, so I have quite a bit of experience from which to draw.
One of the primary principles in agile is the use of self-organizing teams, who are trusted to get the work done. In this model, we bring the work to the team—we don’t form new teams for every new project. This principle is based on understanding the value a high-performing team brings to any endeavor. High-performing team members know each other’s strengths and weaknesses. They’ve learned how to navigate technology challenges together. They take pride in being able to do whatever it takes to get a job done. They have a camaraderie and esprit de corps that contributes to their effectiveness. The whole is greater than the sum of the parts.
This principle would lead you to go down the retraining path. Let me add to this my own experience. In my previous life as a developer, I moved from Cobol to C to Visual Basic, from mainframe to client server to web, from sequential tapes to hierarchical DBs to SQL, from paper cards to 80 character CRVs to Oracle FORMs to visual studio. I’ve worked with telephone banking, automated tellers, expert systems, CAD tools, etc. I've done all of this in a little over fifteen years. I have seen many other developers make the adjustments, as well.
I’ve also seen people who are not able to move from technology to technology. They are quite good where they are, but they need a lot of help learning new things. I have also seen people learn a new technology, but not the best practices. Though they get up to speed quickly, they soon find themselves going down a path that will not support what they need to do and must do significant refactoring to correct their direction.
So, my first approach will be to retrain. Most teams will have a mixture of the people I described above. That is one of the benefits of a team approach. Those who are adept at learning new technologies are the ones who mentor the others on the team. Working side-by-side and using pair programming techniques are the best ways to learn new skills. Depending upon the risk involved in the new technology, I may look to add a guide or “sherpa”(a person who already has experience with the new technology) to my team. Not a replacement, but an addition. Obviously, you must have a budget that will support this addition. I view it as temporary (perhaps a couple months), so the impact should be minimal.
In my experience, a good worker is worth the cost of retraining. There is much more than just sound technical skills that makes for a good worker—there's their communication skills, their work ethic, their leadership skills, their listening and team-player skills. When I have a person with a track record of these skills, I feel it is far less risky to train them on new technologies than to hire a person with whom I have minimal or no history.
What about contractors? Isn’t one of the reasons you use contractors to make it easier to swap out people with old skill sets for those with new? This is especially the rationale for using less expensive offshore partners. They often have a pool of thousands of developers and make these kinds of exchanges regularly. I will grant that this changes the equation somewhat, but I will go back to all the points I have already made. The reasons for replacing a person or team need to be very compelling.
Ultimately, the question that must be asked is this: will the speed to market increase by replacing, or by retraining? Will I be able to find the replacement people, on-board them into our environment, train them on my existing platform, form them into a new team, and have that team get through storming to performing faster than I could get my existing team proficient in the new technology?
In this whole conversation, I’m assuming the existing team consists of good workers. It is an entirely different conversation (and I have a separate post that deals with non-performing individuals in an agile enterprise). What has been your experience? How do you decide whether to retrain or replace?
