Schneller Software entwickeln, nur wie? Teil 3: Reduzieren, reduzieren, reduzieren!

In den ersten beiden Teilen der Artikelserie (Über Warteschlangen, Über Schleifen) haben wir herausgefunden, dass die benötigte Zeit für die Fertigstellung von Software-Features zum größten Teil vom eingerichteten System abhängt. Das ist übrigens auch der Grund, warum “bessere Schätzungen” so gut wie keinen Effekt haben: Die aktive Touch-Time von Entwickler:innen oder Tester:innen ist zwar einigermaßen gut bestimmbar, sie spielt im Time-2-Market aber kaum mehr eine Rolle. 

Die Produktivität unseres Systems ist also eine Folge des Setups, nicht des Verhaltens oder der Leistung der Menschen innerhalb.

Systemisches Denken sagt uns, dass wir die einzelnen Faktoren im System nicht mehr isoliert betrachten dürfen, vielmehr müssen wir uns auf die Interaktionen der einzelnen Bestandteile konzentrieren.

Abhilfe ist in Sicht.

Energisch gegen Warteschlangen und Schleifen vorgehen

Wie beschrieben wird unser System dominiert von drei Faktoren: Warteschlangen (Queues), Schleifen (Loops) und Fehlern (Defects). Was können wir dagegen tun?

WIP-Limitierung: Grenzen setzen, um Freiheit zu ermöglichen

Der offensichtliche erste Schritt zur Reduktion von Warteschlangen ist die Reduktion von gleichzeitiger Arbeit (Work in Progress). Wir erreichen kürzere Warteschlangen (und damit automatisch eine bessere Time-2-Market), wenn Menschen auf Arbeit warten statt Arbeit auf Menschen. Es mag sich auf den ersten Blick kontraintuitiv anhören, Menschen fürs Warten zu bezahlen. Aber stellen wir doch einmal die Gegenrechnung an: Nur wenn wir früher/schneller liefern, können wir auch schneller Wert ernten — so verbessern wir unseren Return-on-Investment.

In Automatisierung investieren

Testing, Deployment, schlicht die ganzen ungeliebten Aktivitäten, die wir regelmäßig tun müssen und die Zeit fressen, müssen wir automatisieren (ja, das ist ein Invest und er lohnt sich jedes Mal — auch wenn die Zeitgewinne zu Beginn klein scheinen). In diesem Artikel zu Extreme-Programming in Scrum-Teams wird der Nutzen, den wir davon haben, klar herausgestellt und es werden einige nützliche Techniken besprochen, die uns dabei helfen können.

Kurze Feedbackzyklen reduzieren Bugs auf ein Minimum

Daneben kümmern wir uns darum, die Anzahl der Schleifen im System zu verringern (jede Schleife ist eine Queue!). 

Um Schleifen zu reduzieren, müssen wir das Aufkommen von Rework (Defects) verringern. Natürlich wollen wir keine schlechte Arbeit in Produktion bringen, daher müssen wir daran arbeiten, von Beginn an höchste Qualität zu erzeugen. Qualität lässt sich nicht ein-testen.

Es ist kaum möglich, alle Fehler zu vermeiden, daher bleibt uns nichts anderes übrig, als Fehler früher zu identifizieren. Auch hier gibt uns Extreme-Programming wertvolle Hinweise und Methoden und die Hand, um den Feedback-Zyklus bei weniger Kosten zu verkürzen:

Alle für eins: “Team up” zur Vermeidung von Handovers

Zu guter Letzt nutzen wir das Prinzip “Team Up” zur Vermeidung von Handovers: Statt Entwicklung, Review und Merge zu separieren, warum nicht gemeinsam just in time? Alles was es dafür braucht, ist, die erforderlichen Menschen zusammenzubringen. “Team Up” ist das Wesen von echter Teamarbeit: Wir tun uns schnell und direkt zusammen, um ein Work-Item voranzubringen. 

Dieses Verständnis von Cross-Funktionalität im Team mag sich radikal anhören, aber stellen wir uns das Plus an Geschwindigkeit (und damit wiederum Time-2-Market) vor, wenn es uns gelingt, die Warteschlangen durch Handovers zu eliminieren.

Fazit: Befreien wir die Arbeit von Schleifen und Warteschlangen, ergibt sich rechnerisch ein Geschwindigkeitsgewinn von bis zu 90%.

In Summe: Wenn Warteschlangen und Schleifen für 90% der Lieferzeit verantwortlich sind, ist ein theoretischer Gewinn an Geschwindigkeit von bis zu 90% denkbar.

Und all das ist erreichbar ohne mehr oder härtere Arbeit und ohne zusätzliches Personal. 

Das heißt nicht, dass es einfach wäre — immerhin müssen Sie diese Erkenntnisse auf die Praxis übertragen und Ihr ganzes Arbeitssystem neu/anders gestalten.