How can I deal with a developer who isn't on board with a new PM and programming framework?

Question

I'm currently implementing Scrum and a switch to Ruby on Rails within my organization. We have a team of six developers, only two of whom have experience in Ruby on Rails. Two of the other developers are getting the hang of Rails relatively fast, but the third is reluctant, constantly complaining about Rails, and how she dislikes the framework.

I have provided moral coaching, as well as several resources for them to pass the Rails curve as fast as possible, but I just can't seem to get this person on board by committing to our Sprint goals and work tools (i.e. Rails). Once she gets frustrated by something she goes into a mental block that ticks off the rest of the team (me included, although I handle the events in a calm manner). I think its more of a tantrum or fit rather than an actual technical issue in terms of learning the framework.

Any ideas or feedback that might help me be a better manager, and hopefully get this person on board?

Answer 1

The best way I've found to help a whole team or an individual team member get on board with a new project/technology/skill/necessaryevil is "subversion". (note the tongue-in-cheek quotes)

A person who is heavily against a certain technology (in this case) is clearly feeling isolated or ignored or that their status in the group is being undermined. So your job as a PM is always going to involve managing the personalities of your team, and this is no exception.

People want to feel that their position is secure, their input and opinions are valued, their voice is heard. So you're going to have to analyze why this person is feeling the way they are.

• Because they've never liked change of any kind? If so, then her grumbling is just a "normal" part of everyday life for this person (which makes them happy by the way, nothing really wrong with that).
• Because they recommended Python-based server-side scripting and RoR was chosen instead, i.e. their opinion/input was not taken? If so, then she's feeling ignored and undervalued and it's going to take some ego massaging on your part to help her get over it.
• Maybe hers is a philosophical objection to the way the Rails framework was implemented, and "she would have done it differently". What framework philosophy does she support and why? If it's this situation, then she likely needs to feel that her technical guidance is valued and being applied to this transition. (In other words her position and status have been attacked.)

So once you have the underlying cause figured out (and the descriptions above are only some of them and probably WAY too simplified), then as PM you must re-validate her position in the group by giving her work that eases her mind. So...

• Not liking change of any kind? Then choose to hear her comments as "entertainment" -- absolutely NOT laughing at her, but using good natured humor and support in encouraging her "attitudes". (more easily said than done of course)
• Her recommendation wasn't chosen? Then forestall her complaints by giving her a challenge to solve using Rails that would more or less force her to study the RoR framework and positively leverage the framework to get the job done.
• It's a philosophical objection? It sounds like your project is way past the stage that a change away from Rails is possible, the commitment to Rails has already been made. If she is technically competent, she may have valid points (and she should be respectfully treated that her points are valid anyway). So ask her how to overcome these "shortcomings" in Rails and how any potential solutions she has can add value to your project as it is.

All of these solutions are simplistic of course, but hopefully give you an idea of how to get your whole team and the one dissenting developer to "buy in" to the new Rails framework. Make them own it. Address their objections by asking for their solution within the framework (i.e. tossing out Rails is not the answer). If you can get the developer focused on the details of overcoming their own objections, you get the buy-in you need and a more peaceful team.

Answer 2

TL;DR

Since I've only heard your side of things, I'm unwilling to assume the problem is the individual you're talking about. While I agree that there is a problem, the problem is one that involves people, processes, and change management. It will require you to acknowledge this before the problem can be resolved to anyone's satisfaction.

Most likely, you will need to make some changes to the composition of your team. That is not an indictment of the team member; it's simply that effective change management sometimes requires changes in personnel.

If you ask this question on a different Q&A site like Workplace SE you may get a different answer. From a project management perspective, though, and especially from an agile perspective, you have not implemented organizational change properly.

Introduce Organizational Change Properly

In programming, you change one simple thing at a time so you can debug it. You have changed at least two complex things at the same time, and are struggling to debug it.

Scrum (or any project management framework) requires training and time to be implemented effectively. In addition, agile frameworks require buy-in from the entire team, not just the project manager.

If you have team members who aren't interested in agile practices or Scrum ceremonies, and you have truly exhausted all teachable moments and coaching opportunities, then you need to take responsibility for having prescribed a framework without having first created buy-in. After you do that, you need to form a team that contains self-organizing people who want to follow an agile framework.

Introduce Job Changes Properly

On the job front, you've introduced a host of changes to the team's job description, including changing:

1. Project management framework
2. Language
3. Web application framework
4. Technology stack
5. Technological ecosystem

If you've changed all that, you've also probably changed the product that you're building, too. That's a lot of change to a person's job description, and not everyone in I.T. wants to be cross-functional or learn new languages and frameworks that don't fit their cognitive patterns.

Some people enjoy the chance to use new technologies or work on a new project, while others prefer stability and to stay within a well-defined comfort zone. If you just switched someone's job description from .NET or Java programmer in a waterfall shop to Ruby on Rails developer in a Scrum and/or DevOps organization, there are certainly going to be people who can't or won't make the switch.

If the team didn't drive this change to the technology stack, then management needs to be ready to take responsibility for having changed the job description. Furthermore, both senior management and the project manager should expect to have to retrain and reform a team around a new technology stack.

"Change" Often Requires Actual Change

Not all change is the responsibility of the employee. It's great that you've got five out of six of your current team members on board with the new project and technology frameworks. Now it's your job to determine whether there is a role for anyone who doesn't fit your new I.T. model.

Perhaps this person can take on a different role within the company or the team. Maybe there are other projects or other teams that this person can work on, that may be of more interest to her. If not, you're essentially saying: "Adopt the new paradigm or find a new job."

As a business, that's may not be an unreasonable perspective. From a team-building standpoint, though, you will generally get better results by acknowledging that not every person is the right fit for every team or organizational culture. Keep that in mind if and when you decide to make changes to your team composition, as nothing destroys team cohesion as quickly as blaming workers for the results of strategic decisions by the business.

Treat this as a change in job requirements, rather than an interpersonal issue. Not only is this a more constructive approach than trying to assign blame, it is also more likely to result in an objective resolution.

Answer 3

The fact of the matter is that Rails is an outdated, slow, buggy framework.

I assume you have been forced to take on some legacy project work which mandates its use, but you have to recognise that working on this project will not be benefical to the careers of your developers.

Unless you compensate them with increased pay, working from home, less hours or something the good ones will go work somewhere else.

The solution is simple. Ask the dev "If you were a freelancer how much extra would you charge for a Rails project over a 'favorite language' project?" Then pay them the extra percentage