Meine Erfahrungen dazu:

Ursache 1: STK500 nicht erkannt -> serielle Schnittstelle blockiert -> blockierendes Programm (z.B. Hyperterminal) schliessen.
Ursache 2: Controller-clock und Board-Clock nicht abgestimmt -> meist sind die AVRs auf internen Takt mit 1MHz voreingestellt. Der ISP-Takt darf dann nicht über 250kHz liegen -> Board-Takt auf Mindestwert reduzieren (32kHz) und danach die Fuse settings ändern. Danach kann dann der Board-Takt wieder höher gedreht werden (sonst dauerts zu lange)
Ursache 3: Die Fuse für das serielle ISP steht auf "disable". Dann ist serielle Programmierung gesperrt -> µC gemäß Doku mit paralleler High Voltage programmieren - DABEI DIE FUSE FÜR DAS SERIELLE ISP UMSCHALTEN
Ursache 4: Die Security Fuses sind gebrannt und der Chip ist gegen "Datenklau" geschützt -> "Erase entire chip" (also komplett putzen) und alle Fuses kontrollieren (kann dann zu Ursache 2 oder 3 führen!)
Ursache 5: Die Pins für's ISP sind anderweitig belegt, die Schaltung verträgt sich nicht mit ISP -> AVR alleine (keine Ports belegen!!) in das STK500
Ursache 6: Der RESET-pin ist als alternativer Port gefused -> serielles ISP nicht machbar, nur paralleles high-voltage
Ursache 7: Der RESET ist nicht im STK500 angeschlossen (z.B. ATtiny26) -> zusätzlich verdrahten - ist im Handbuch genauestens beschrieben!

Ich habe bisher keinen AVR in die Finger bekommen, der sich nicht durch eine der beschriebenen Maßnahmen zur Kooperation überreden lies. Falls serielles ISP ums verrecken nicht funktionieren will, den AVR mit der prallelen High-Voltage-Methode behandeln und alle Fuses kontrollieren.

Ist der AVR nicht auf dem STK500, dann können noch weitere Ursachen mitspielen, dafür kann das STK500 aber nix - da ist der Designer der Schaltung zuständig. Die muß gewisse Randbedingungen erfüllen, damit sie ISP geeignet ist!