The most successful Scrum teams I have been on have focused on the Product Owner. This seems backwards, as Scrum is supposed to be about the team, but if you've been having the problems you describe, this Product Owner centric approach may help.
Scrum is not a framework to make the best software possible. It's a framework to make the best software possible in a business environment. The most powerful aspect of Scrum is that the Product Owner is responsible for keeping the customers happy. They act as a shield for the rest of the team from the rest of the political bureaucracy.
This is certainly not unique to Scrum. Any development model worth it's salt gets the corporate as far away from the developers as the developers need. What does make Scrum unique is the set of tools it chooses to put in the Product Owner's hands. There's a contract between how much visibility and responsiveness the PO can expect from a team and the autonomy that developers expect.
The most successful Scrum teams I've been on have treated this as a departure point. At worst, everyone knows that we can fall back on this set of rules. But at its best, these teams were not afraid to bend the rules of scrum. Scrum simply provided a framework for negotiations between the PO and the team members: here is what the team members needed to provide in order for the PO to continue keeping the rest of the corporation off their back.
I did Scrum with a team of 4. The first thing we did was ditch the daily standups. The team was already working together as a tightly knit team. Nothing new would be reported at the standups. But everyone knew that if the product started to suffer due to disconnections, the standups were something to fall back on.
The sprint is probably the trickiest element of Scrum to treat in this way. The most important thing I learned about this was the term "Minimum Viable Product." Each sprint plan was basically saying "As the PO, if the team can produce this product, I can demonstrate to leadership that the team is doing their job and should keep getting paid." The nature of the MVP changes over time. Near a business deadline (agile may say these don't exist, but they do), the MVP became much more focused on testable productivity. Between builds, the MVP shifted more towards proving that we were developing in the right direction. The PO and Scrum Master made it clear that it was up to us to work out what the MVP should be each time. If your developers are turning average, they're probably not having much say in what this is.
The single greatest failure I've found in Scrum is that it makes people want to overplan. If your velocity is 500 points/wk, people want to commit to 500 points/wk of tasking up front. This leads to a lot of the failures others have mentioned, where people are cramming just to get the work in. Budget far less (maybe 200-300 points) that has to be done, and use the concept of MVP to direct development mid-sprint. If you find you have to budget all 500 points, then your structure is brittle and will prevent innovation.
Not committing to a full velocity also opens the door for splitting tasks. If I pick up a 13 point task near the end of the sprint, which wasn't committed to, and I don't complete it, I should break it up into a 5point and a 8 point task, and complete one of them with the mindset of MVP. If the result of the 5 point task isn't a complete unit, then I'd question the agility of the situation.
But what should be done? Whatever lets the PO sell the fact that the team is doing their job correctly.
True story: I worked on a team which was using Scrum to reign in some out of control internal customers. It was armor for us. What we found was that many of their tasks were indeed too agile to fit in scrum. Waiting until next sprint wasn't reasonable. Our solution was to develop in two parallel processes. We had Scrum going for things that could be predicted, and a home-grown process for the popups that plagued the development. Our home grown process centered around continuous contact with the customer - if they didn't want to dance with us, they should put the task in Scrum.
This worked great for us because our PO found that he could sell it properly. If we spent too much time working directly with the customers, they tended to realize that that's how the time was spent, so they were okay when fewer stories were accomplished. Any time they just wanted a "fire and forget" solution, they went through Scrum. And everyone understood the power of Scrum here: if they didn't play ball with the development team in our home-grown approach, they had to "take a number" in the scrum process. So for us, that worked. Is it the solution for everyone? No. But it's something the Product Owner could work with. And the Product Owner is more important to Scrum than most let on!
