Verschwendungen 5 & 6: Aufgabenwechsel und Fehler - Lean Software Development

1Die Kontextwechsel-Steuer

Jedes Mal, wenn Sie die Aufgabe wechseln, zahlen Sie eine Steuer.

Forschung zeigt konsistent, dass Kontextwechsel 15-25 Minuten kosten, um zur vollen Produktivität zurückzukehren. Nicht um mit der Arbeit zu beginnen – um die gleiche Fokustiefe zu erreichen, die Sie vor der Unterbrechung hatten.

Wenn Sie an einem Nachmittag 4-mal den Kontext wechseln, verbringen Sie möglicherweise mehr Zeit mit Neuorientierung als mit tatsächlicher Arbeit.

In der Fertigung wird diese Verschwendung „Transport" und „Bewegung" genannt – unnötige Bewegung von Materialien oder Personen. In der Softwareentwicklung ist es die unnötige Bewegung der Aufmerksamkeit.

Quellen von Aufgabenwechseln:

Zu viel WIP: Das Jonglieren mehrerer Projekte bedeutet ständiges Wechseln
Unterbrechungen: Slack-Nachrichten, Schultertippen, „kurze Fragen"
Meetings: Jedes Meeting ist ein Kontextwechsel hin und zurück
E-Mail/Benachrichtigungen: Ständiges Prüfen fragmentiert die Aufmerksamkeit
Unklare Prioritäten: Nicht zu wissen, woran man arbeiten soll, führt zu Hin und Her

Die Kosten sind nicht nur Zeit – es ist Qualität. Oberflächliche Arbeit produziert oberflächliche Ergebnisse. Tiefgehende Arbeit erfordert anhaltenden Fokus. Aufgabenwechsel verhindern tiefgehende Arbeit.

Der Multitasking-Mythos

Menschen können kein Multitasking – wir wechseln zwischen Aufgaben. Wir sind schlecht darin. Was sich wie Produktivität anfühlt, ist tatsächlich kognitiver Overhead. Die Person, die durch das Jonglieren von Aufgaben „viel erledigt", ist oft weniger produktiv als jemand, der sich auf eine Sache konzentriert.

2Der Fehler-Multiplikator

Fehler sind aus offensichtlichen Gründen Verschwendung: Sie erfordern Nacharbeit. Aber die tatsächlichen Kosten sind schlimmer, als es scheint.

Spät gefundene Fehler kosten exponentiell mehr als früh gefundene Fehler. Ein Bug, der in der Entwicklung gefunden wird, braucht vielleicht 10 Minuten zur Behebung. Der gleiche Bug, der im Test gefunden wird, braucht vielleicht eine Stunde (Reproduktion, Diagnose, Behebung, erneuter Test). In der Produktion gefunden, kann er Tage dauern (Untersuchung, Kundenkommunikation, Notfall-Fix, Post-Mortem).

Fehler erzeugen Fehler. Das Beheben eines Bugs unter Druck führt oft zu neuen Bugs. Die Codebasis wird zum Minenfeld. Entwickler werden langsamer. Die Qualität sinkt spiralförmig.

Fehler zerstören Vertrauen. Nach genügend Produktionsvorfällen erfordert jede Änderung umfangreiche Genehmigung, umfangreiche Tests, umfangreiche Freigabe. Der Prozess bläht sich auf, um vor den Fehlern zu schützen, die der Prozess erzeugt.

Die versteckte Verschwendung: Inspektion und Tests. Wenn Sie Fehler haben, brauchen Sie umfangreiche QA. QA ist notwendige Verschwendung – sie fügt keinen Wert hinzu, sie fängt nur die Verschwendung auf, die durch Fehler entsteht. Bauen Sie Qualität ein, und Sie brauchen weniger Inspektion.

Der unterbrechungsgetriebene Entwickler

Ein Entwickler bearbeitet den ganzen Tag „kurze Fragen": Slack-Nachrichten, Schultertippen, E-Mail. Er fühlt sich hilfreich. Aber seine eigene Arbeit erreicht nie Tiefe. Komplexe Aufgaben dauern Wochen. Bugs schlüpfen durch, weil der Fokus fragmentiert ist.

Maker's Schedule

Ein Team etabliert „Fokuszeit" von 10-14 Uhr: keine Meetings, kein Slack, keine Unterbrechungen. Komplexe Arbeit wird am Vormittag erledigt. Kommunikation findet in gebündelten Zeitfenstern statt. Qualität und Velocity verbessern sich.

3Wechsel und Fehler reduzieren

Für Aufgabenwechsel:

WIP-Limits: Die direkteste Intervention. Wenn Sie nur an einer Sache gleichzeitig arbeiten können, können Sie nicht den Kontext wechseln. Beenden Sie, bevor Sie beginnen.

Gebündelte Kommunikation: Prüfen Sie E-Mail/Slack zu definierten Zeiten, nicht ständig. Lassen Sie die Leute wissen, wann Sie verfügbar sind und wann nicht.

Meetingfreie Zeit: Legen Sie Blöcke für fokussierte Arbeit fest. Schützen Sie sie energisch.

Klarere Prioritäten: Wenn Leute nicht wissen, woran sie arbeiten sollen, schlagen sie hin und her. Machen Sie Prioritäten explizit und stabil.

Für Fehler:

Testgetriebene Entwicklung: Schreiben Sie Tests zuerst. Bauen Sie Qualität von Anfang an ein, inspizieren Sie sie nicht am Ende hinein.

Pair Programming: Echtzeit-Review fängt Fehler ab, bevor sie zu Bugs werden.

Continuous Integration: Finden Sie Integrationsfehler sofort, wenn der Kontext frisch und Fixes günstig sind.

Stoppen und beheben: Wenn Sie einen Bug finden, beheben Sie ihn jetzt. Fügen Sie ihn nicht zu einem Backlog hinzu, um veraltet zu werden. Toyotas Andon-Cord-Prinzip.

Schuldzuweisungsfreie Postmortems: Wenn Bugs entkommen, verstehen Sie warum, ohne Schuldzuweisung. Beheben Sie das System, das den Bug zugelassen hat, nicht nur den Bug selbst.

Der Erkennungs-Trugschluss

Mehr Tests hinzuzufügen reduziert keine Fehler – es erkennt sie. Und Erkennung ist teuer. Das Ziel ist, zu verhindern, dass Fehler überhaupt erst entstehen. Bauen Sie Qualität ein; inspizieren Sie sie nicht hinein.