Your question is:

**How do I prevent scrum from turning great developers into average developers?**

Let's answer that. You list a number of problems that your team is seeing, and while they are not the fault of Scrum they are problems that Scrum is unfortunately prone to. Fortunately none of them are unsolvable within the Scrum framework, given the goodwill of the team and competent management.

Most of these answers require some level of influence. An individual developer in the team is not going to fix them on their own, but that is true of most team problems.

> Everyone just wants to take something easy off the board that you can
> get done in a day so you have something to report in tomorrows daily
> scrum.

There are two problems here. Somehow the team has got it into their heads that a standup meeting is there so that those outside the team can check on their progress daily. That is not the point of a standup. Standup is for communication within the team.

To fix this establish it as the norm that the standup simply says what you are doing. **It is perfectly OK to give a standup report that says "I'm working on the export to PDF feature, and I expect to continue that tomorrow."** If the task is expected to take a few days, that it's absolutely fine if that is the report for all of those days. It's also OK to say "I'm designing  the export to PDF feature. I should be done with that tommorow and I'll start coding."

The second problem is caused by the first, which is the picking up of low handing fruit. It's a natural thing to happen if everyone's goal is to look good at standup rather than complete good work. But it should be addressed. If by day 2 of the sprint nobody has picked up the big complex task, then the scrummaster should say "I see nobody has started the database compression task - that's a big task and it needs to be started right away if we are going to finish it this sprint". If nobody offers choose your best developer and say "Cecil, can you pick that one up please." Don't forget to congratulate Cecil at the end of the sprint for doing a good job.

If the big difficult task is not taken early, and so doesn't get completed, then the scrummaster needs to address this at the retrospective and say "We didn't finish the database compression task, and that was because it was picked up too late. We need to pick up big tasks first." The team is responsible for finding a way to make this work.