How can you keep your best developers motivated and busy in an agile/scrumm environment?
Letting a good developer "rocket ahead" optimizes for that developer (localized optimization) but not for the complete system (global optimization).
A more "global" optimization of that developer's time and energy, since they can do twice the work in half the time, is to mentor, support, teach, and otherwise spend their energy helping EVERYONE get to their level. Since they can and will get their "portion" of the work done quickly, they have bandwidth to add values in other ways as a force multiplier.
From my experience people like this end up in "lead" or "architect" roles.
Interesting trait of scrum - whenever there is scrum related discussion the no true Scotsman fallacies immediately pop up. By the way, scrum is actually a methodology to get something out of non-delivering teams. For everybody else it is just like throwing sand into their engine's cylinders.
Most of the problems that management think are because of the team are mostly (80%+) caused by people/processes/habits/cultural issues UPSTREAM of the team.
In other words, shit rolls down hill.
The purpose of Scrum is to highlight issues and bottlenecks in the 'system' so they can be addressed.
"Wide skill variances in team members skillsets" is one such problem, and a fairly common one. One remedy is to drop the dead weight, either through management/hr action or natural attrition. Another remedy is to upgrade the skills of the people who are "behind" using the people who are "ahead" as mentors.
- The Consulting Company
If the scope of a sprint is so far out of whack that fast developers are running out of work, then you're misestimating the complexity of deliverables. That sort of thing gets cleared up pretty quickly if it's being managed correctly.
The only downside to scrumm IMO is that some companies champion it like it's the only valid solution and waterfall is demonized somewhat. It seems to me the best organizational design is the one that takes into account all likely possibilities. Flexibility twists with the wind. Rigidity eventually cracks and collapses.
OTOH, depending on other aspects of the context, there may be organizational efficiencies from cyclic approaches that flow-based approaches don't realize.
It assumes competence. If you are doing scrum with a team that has incompetent and slow developers, you will fail.