If you're getting rotten code, then the team's not really completing
the stories, are they? I assume your definition of Done includes
having sufficient unit tests and acceptance tests, having them pass,
and having well-structured (i.e. refactored) code; if it doesn't, I
recommend you change it so it does.
I'm guessing that if the focus is on doing individual tasks, then:
1) The individual tasks are visible to the team, and the overall value
delivered by the sprint isn't, and
2) The team members are individually rewarded or rated according to
number of tasks reported done, and not by the overall value delivered
by the sprint.
If you want the team to be delivering value overall, you need to
measure (and make visible) value at the team level, not effort at the
individual level. (This is an example of See the whole, by the
Performance is also a matter of the whole system, in a different way:
the only parts of the system that you want to spend effort speeding up
are the bottlenecks. Being a bottleneck is not a property of a part
of the system (even the part that's currently a bottleneck), but of
I recommend you measure the performance of the system frequently,
either every day or on every integration, whichever is more frequent.
This will let you know when performance sinks below a threshold, and
give you an idea which changes partially triggered it. Improving the
performance should probably take the form of stories: usually a spike
to try a particular optimization approach, then (if that's successful)
a development story to implement it.
Constant refactoring will help you achieve 3 (Decide as late as
possible). Regular retrospectives will help your team achieve 7 (See
the whole). They are also an opportunity to 1 (Eliminate waste),
especially if you include an activity in your retrospective focused on
identifying waste (hint: look for work piling up in queues).
I hope this is helpful.