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:
- Project management framework
- Language
- Web application framework
- Technology stack
- 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.