Verschwendung 3 & 4: Übergaben und Wartezeiten

Jedes Mal, wenn Arbeit von einer Person oder einem Team zu einer anderen weitergegeben wird, geht Kontext verloren.

Der Product Manager schreibt Anforderungen. Er kennt den Schmerz des Nutzers, die geschäftlichen Rahmenbedingungen, die Prioritäts-Trade-offs. Er übergibt dies an einen Designer.

Der Designer liest die Anforderungen, stellt klärende Fragen (von denen einige der PM nicht mehr beantworten kann, weil der Kontext verblasst ist) und erstellt Mockups. Er übergibt dies an Entwickler.

Die Entwickler lesen die Anforderungen und Mockups, stellen klärende Fragen (von denen weder PM noch Designer einige mehr beantworten können) und bauen etwas. Sie übergeben es an QA.

QA testet gegen die Anforderungen, findet Probleme und gibt es zurück an die Entwickler.

Bei jeder Übergabe gehen Informationen verloren. Bis das Feature die Nutzer erreicht, ähnelt es kaum noch dem, was der PM ursprünglich über die Nutzerbedürfnisse verstanden hat. Und jede Übergabe hat Zeit gekostet – manchmal Tage des Wartens in Warteschlangen.

Übergaben sind der Ort, an dem Kontext stirbt.

Der Großteil der Durchlaufzeit ist Wartezeit, nicht Arbeitszeit. Eine Aufgabe, die 2 Stunden aktive Arbeit erfordert, kann eine Durchlaufzeit von 2 Wochen haben. Wo geht der Rest hin?

• Warteschlangenzeit: Warten in Backlogs auf Priorisierung
• Warten auf Review: PRs liegen ungeprüft herum
• Warten auf Genehmigung: Entscheidungen stecken im Management fest
• Warten auf Abhängigkeiten: Blockiert durch andere Teams
• Warten auf Umgebungen: Kann nicht testen, weil Staging kaputt ist
• Warten auf Informationen: Fragen unbeantwortet
• Warten auf Terminierung: Meetings, die erst nächste Woche stattfinden können

Jede Wartezeit führt zu Verzögerungen und erfordert oft eine erneute Einarbeitung, wenn die Arbeit wieder aufgenommen wird. Sie lesen den Code, verstehen den Kontext, werden weggezogen und müssen diesen Kontext später wieder aufbauen.

Flow-Effizienz misst die wertschöpfende Zeit als Prozentsatz der Durchlaufzeit. In den meisten Softwareorganisationen liegt sie bei 5-15%. Das bedeutet, dass 85-95% der Zeit Arbeit wartet, nicht bearbeitet wird.

Cross-Functional Teams: Bringen Sie alle Fähigkeiten, die zur Wertschöpfung benötigt werden, in ein Team. Product, Design, Entwicklung, Testing – alle zusammen. Übergaben werden zu Gesprächen.

Generalisierende Spezialisten: Menschen, die tiefes Fachwissen in einem Bereich haben, aber in anderen beitragen können. Wenn sich Arbeit im Review staut, können Entwickler beim Review helfen. Weniger Warteschlangen.

Pair und Mob Programming: Zwei oder mehr Personen, die zusammenarbeiten, eliminieren Übergaben innerhalb der Arbeit. Review ist eingebaut. Wissenstransfer ist kontinuierlich.

Echtzeit-Zusammenarbeit: Ersetzen Sie asynchrone Übergaben durch synchrone Zusammenarbeit. Statt eine Spezifikation zu schreiben, führen Sie ein Gespräch. Statt einen Bug zu melden, gehen Sie rüber und zeigen Sie ihn dem Entwickler.

Genehmigungen eliminieren: Die meisten Genehmigungsschritte fügen keinen Wert hinzu – sie sind Kontrollmechanismen aus Umgebungen mit geringem Vertrauen. Hinterfragen Sie jede Genehmigung: Welchen Wert fügt dies hinzu? Könnten wir den gleichen Nutzen auf andere Weise erzielen?

Übergaben automatisieren: Wenn Arbeit übertragen werden muss, automatisieren Sie die Warteschlange. CI/CD-Pipelines, die automatisch deployen. PR-Bots, die Reviewer sofort benachrichtigen. Slack-Integrationen, die blockierte Arbeit sichtbar machen.

Das Ziel ist nicht, schneller zu arbeiten – sondern weniger zu warten. Greifen Sie die 85% an, nicht die 15%.