Let say agile is not for everybody and agile is not for every project. In the same time agile is very broad term and Scrum is only one implementation of an agile process - I can somehow say the implementation with probably the most constraints which tries to set up standardized process with well known steps.

Another area to think about is what is the purpose of agile? Is agile about the way how developers work? Perhaps - some methodologies indeed go that direction. But agile itself covers areas outside of the development. Agile is more about driving the whole process, the way how an interaction works, the way how you delivery the working product with the most important features on time and the way how you control resources, how you see where in the project you currently are, etc.

There are methodologies which doesn't try to change anything from your development process - Scrum is not the one. All agile methodologies emphasize continuous improvement. You will detect some inefficient step in your process and you will try to improve it / change it - that is the agile way. Check another popular agile methodology - Kanban.

You / Your company have decided to use Scrum and it can lead to fact that some people will not like it and leave. You should deal with each one of your developers separately. You should talk about that with each one and you should try to find some interests which would allow them enjoying the work again.

They can have role of mentors, they can teach others, show them how to refactor code to better architecture when working iteratively. They can form together some global architecture blueprint use across projects. They can also work on proof of concepts, participate in RFI (request for information) when customers make enquiries to think about feasibility of requirements. They can work in pairs with less skilled developers and do the complex task together, etc. Their main value should be in using their skills and allow others learning from them.

Scrum and agile globally indeed somehow keep down individuals and prioritize teams - teams deliver application, not individuals. This idea is based on the fact that you will never have a team where everybody have same skill set and experience.

If your transition to Scrum will be successful they should see that the overall process has improved, delivery times were reduced, quality has improved and customers are more satisfied. They can still believe that developed applications themselves are much worse then they could be but that is the point - customer doesn't work the best code ever written. Customers want the minimal / the cheapest / the fastest developed working code which satisfies their requirements. If brute force is enough for that then be it. This is something that can cause problems to high skilled developers but it is not failure of agile, it the place where business demands and perfectionism go against each other.

Let say agile is not for everybody and agile is not for every project. In the same time agile is very broad term and Scrum is only one implementation of an agile process - I can somehow say the implementation with probably the most constraints which tries to set up standardized process with well known steps.

Another area to think about is what is the purpose of agile? Is agile about the way how developers work? Perhaps - some methodologies indeed go that direction. But agile itself covers areas outside of the development. Agile is more about driving the whole process, the way how an interaction works, the way how you delivery the working product with the most important features on time and the way how you control resources, how you see where in the project you currently are, etc.

There are methodologies which doesn't try to change anything from your development process - Scrum is not the one. All agile methodologies emphasize continuous improvement. You will detect some inefficient step in your process and you will try to improve it / change it - that is the agile way. Check another popular agile methodology - Kanban.

You / Your company have decided to use Scrum and it can lead to fact that some people will not like it and leave. You should deal with each one of your developers separately. You should talk about that with each one and you should try to find some interests which would allow them enjoying the work again.

They can have role of mentors, they can teach others, show them how to refactor code to better architecture when working iteratively. They can form together some global architecture blueprint use across projects. They can also work on proof of concepts, participate in RFI (request for information) when customers make enquiries to think about feasibility of requirements. They can work in pairs with less skilled developers and do the complex task together, etc. Their main value should be in using their skills and allow others learning from them.

Scrum and agile globally indeed somehow keep down individuals and prioritize teams - teams deliver application, not individuals. This idea is based on the fact that you will never have a team where everybody have same skill set and experience.

If your transition to Scrum will be successful they should see that the overall process has improved, delivery times were reduced, quality has improved and customers are more satisfied. They can still believe that developed applications themselves are much worse then they could be but that is the point - customer doesn't want the best code ever written. Customers want the minimal / the cheapest / the fastest developed working code which satisfies their requirements. If brute force is enough for that then be it. This is something that can cause problems to high skilled developers but it is not failure of agile, it the place where business demands and perfectionism go against each other.