Redaktionell bearbeitetes Transkript der Audiofolge

00:00 · Sprecher 1: Willkommen zu unserem heutigen Deep Dive. Also stellen Sie sich einmal folgendes Szenario vor. Sie blicken auf das Dashboard Ihres Entwicklerteams und jeder Einzelne ist zu wirklich exakt 100 Prozent ausgelastet.

00:16 · Sprecher 2: Der absolute Klassiker.

00:18 · Sprecher 1: Genau. Keiner hat auch nur eine Minute Leerlauf. Die Kalender platzen aus allen Nähten, die Tastaturen glühen förmlich. Und das klingt ja im ersten Moment nach dem absoluten Traum jedes Managers, oder? Nach purer destillierter Effizienz.

00:34 · Sprecher 2: Zumindest glauben das sehr, sehr viele, ja.

00:36 · Sprecher 1: Bei hoher Variabilität kann genau dieser Zustand erheblich dazu beitragen, dass ein Projekt in ernsthafte Schwierigkeiten gerät. Denn die Realität im Releaseplan spricht oft eine ganz andere Sprache: Wichtige Features verschieben sich, die Liste der Dinge, die angeblich schon zu 90 Prozent fertig sind, wird täglich länger, und am Ende wird nichts verlässlich fertig. Genau das wollen wir heute aufdröseln.

01:05 · Sprecher 2: Ja, und das ist ein fundamentaler Schmerzpunkt, den wir wirklich branchenübergreifend in technischen Organisationen sehen. Ganz besonders betrifft das den Mittelstand, also KMUs, die hochkomplexe Produkte bauen.

01:17 · Sprecher 1: Also da, wo Hard- und Software zusammenkommen.

01:20 · Sprecher 2: Genau. Denken Sie an Unternehmen, in denen Software, Hardware und vielleicht noch Firmware in einem einzigen System vereint werden. Die Teams rennen dort im sprichwörtlichen Hamsterrad und arbeiten am absoluten Limit. Aber die PS kommen einfach nicht auf die Straße. Die Frustration wächst massiv – beim Management ebenso wie bei den Teams selbst.

01:40 · Sprecher 1: Das ist der perfekte Startpunkt für unsere heutige Mission. Wir haben uns durch einen großen Stapel fundierter Quellen gearbeitet, um einer zentralen Frage auf den Grund zu gehen: Warum ist Vollbeschäftigung in der Entwicklung nicht dasselbe wie Fertigstellung? Und vor allem wollen wir besprechen, wie Sie den wirksamen Flaschenhals in Ihrem System finden, ohne dass das Ganze in einer toxischen Hexenjagd endet.

02:09 · Sprecher 2: Das ist so ein wichtiger Punkt. Kein Blame Game.

02:11 · Sprecher 1: Absolut. Auf unserem Tisch liegen heute operationsmathematische Konzepte wie Little’s Law, Erkenntnisse aus der Warteschlangentheorie und, das finde ich besonders spannend, die konkrete Methodik des sogenannten EngpassAudits.

02:25 · Sprecher 2: Und diese Zusammenstellung der Quellen, die ist für uns heute wirklich der Schlüssel. Denn für Sie als CTO, technischer Geschäftsführer oder Entwicklungsleiter ist das schlichtweg Überlebenswissen.

02:34 · Sprecher 1: Wahnsinn, ja.

02:35 · Sprecher 2: Die klassische Management-Intuition besagt ja oft, jeder muss immer etwas zu tun haben, sonst verschwenden wir Geld.

02:43 · Sprecher 1: Genau. Dieser Reflex. Jeder muss beschäftigt aussehen.

02:47 · Sprecher 2: Ja. Aber unsere Quellen zeigen sehr deutlich, dass diese Intuition den mathematischen Zusammenhängen variabler Wissensarbeit fundamental widerspricht.

02:56 · Sprecher 2: Was in einer Fabrik am Fließband noch halbwegs sinnvoll erscheinen mag, führt in komplexer Produktentwicklung oft in eine Sackgasse.

03:06 · Sprecher 1: Lassen Sie uns das mal greifbar machen. Gerade wenn wir über Auslastung, Durchsatz und Fertigstellung sprechen. Ich habe da immer dieses Bild einer Autobahn im Kopf.

03:16 · Sprecher 2: Oh ja, das Autobahnbeispiel ist hervorragend.

03:18 · Sprecher 1: Stellen Sie sich vor, wir stopfen eine Autobahn zu 100 Prozent mit Autos voll. Stoßstange an Stoßstange. Kein Millimeter Platz dazwischen. Die Auslastung dieser Straße liegt bei absolut perfekten 100 Prozent. Aber was passiert real? Es bewegt sich kein einziges Auto mehr vorwärts.

03:39 · Sprecher 2: Genau. Der Durchsatz ist exakt null.

03:41 · Sprecher 1: Niemand kommt jemals an seinem Ziel an. Und wenn wir das doch aus dem täglichen Straßenverkehr alle schmerzlich wissen, warum versuchen wir dann in der Softwareentwicklung auf Teufel komm raus, jeden Mitarbeiter zu 100 Prozent auszulasten?

03:57 · Sprecher 2: Das bringt uns direkt zum Kern des Problems: Variabilität. Auf der Autobahn gibt es unterschiedliche Geschwindigkeiten, unerwartete Bremsvorgänge, Baustellen und hektische Spurwechsel. In der Produktentwicklung tritt das in noch extremerer Form auf. Wissensarbeit ist hochgradig variabel. Keine zwei Features, die Sie programmieren oder konstruieren, sind exakt gleich groß oder gleich komplex.

04:20 · Sprecher 1: Stimmt. Wenn ich eine einfache Farbänderung in einer App umsetze, dauert das vielleicht zehn Minuten.

04:27 · Sprecher 2: Mhm.

04:28 · Sprecher 1: Wenn ich aber einen obskuren Bug in einem Legacy-Code aus dem Jahr 2015 jage, dann sitze ich da vielleicht drei Tage dran. Das kann man ja vorher gar nicht wissen.

04:38 · Sprecher 2: Exakt. Und dazu kommen dann noch die unerwarteten Abhängigkeiten. Eine externe Schnittstelle fällt aus. Der Kunde ändert kurzfristig seine Meinung. Oder ganz banal, ein wichtiger Kollege ist krank.

04:51 · Sprecher 1: Ja.

04:52 · Sprecher 2: Wenn man ein derart variables Arbeitssystem sehr nah an seine Kapazitätsgrenze treibt, wirken die Zusammenhänge der Warteschlangentheorie besonders stark.

05:01 · Sprecher 1: Und was genau heißt das für unsere Durchlaufzeiten?

05:04 · Sprecher 2: Die Quellen zeigen das mathematisch sehr klar: Mit steigender Auslastung können Warteschlangen vor einzelnen Arbeitsschritten und damit auch die Durchlaufzeiten stark und überproportional wachsen.

05:19 · Sprecher 1: Das heißt, der Sprung von 80 auf 90 Prozent kann die Wartezeit bereits deutlich erhöhen. Und der weitere Sprung auf 95 Prozent kann sich in der Praxis noch viel gravierender anfühlen – besonders wenn Verzögerungen über Wochenenden, Feiertage oder feste Freigabefenster hinweg anwachsen.

05:33 · Sprecher 2: Genau das ist der Mechanismus. Schon kleine Störungen können sich massiv aufstauen, weil kaum noch Puffer vorhanden ist, um sie abzufangen.

05:41 · Sprecher 1: Wahnsinn.

05:42 · Sprecher 2: Und das führt zu einem völlig paradoxen Zustand. Ein Team wirkt komplett überlastet, weil wirklich jeder pausenlos arbeitet. Ja. Ja. Die schwitzen alle. Genau. Aber weil die eigentliche Arbeit immer wieder in diesen Warteschlangen feststeckt, beginnen die Leute immer mehr neue Arbeit. Der Entwickler sagt sich dann, ich hänge hier fest, ich warte auf Freigabe von der QA, also ziehe ich mir schon mal das nächste Ticket.

06:04 · Sprecher 1: Ah. Es wird also immer mehr begonnen, aber immer weniger abgeschlossen.

06:09 · Sprecher 2: Richtig. Der kontinuierliche Fluss der Arbeit bricht einfach komplett zusammen.

06:13 · Sprecher 1: Wenn ich jetzt aber in gängige Management-Blogs schaue, dann lese ich dort oft von so einer, ähm, magischen Schwelle. Da heißt es dann, trimmen Sie Ihr System auf genau 80 Prozent Auslastung. Das ist der optimale Sweet Spot. Oh ja. Ist das also die goldene Regel, die wir hier suchen?

06:32 · Sprecher 2: Nein, absolut nicht. Das ist ein Mythos und unsere Quellen räumen damit sehr, sehr klar auf. Es gibt schlichtweg keine universelle optimale Auslastungsquote.

06:41 · Sprecher 1: Okay.

06:42 · Sprecher 2: Eine pauschale 80-Prozent-Regel ist Unsinn, weil die benötigten Reserven eines Systems von vielen individuellen Faktoren abhängen. Zum Beispiel: Wie hoch ist die Variabilität Ihrer Aufgaben? Wie viele Abhängigkeiten bestehen zu Hardware-Lieferanten oder anderen internen Teams?

07:00 · Sprecher 1: Ah, okay.

07:01 · Sprecher 2: Oder wie schnell muss Ihr Team im Notfall auf einen kritischen Server-Ausfall reagieren können? Ein Team, das sehr standardisierte Wartungsarbeiten durchführt, das kann eine deutlich höhere Auslastung vertragen als, sagen wir, ein Forschungsteam, das tief im unklaren Terrain neue Algorithmen entwickelt.

07:17 · Sprecher 1: Verstehe. Die Autobahn ist also verstopft. Und wir wissen jetzt, dass pauschale Geschwindigkeitslimits oder so feste Auslastungsquoten uns nicht retten.

07:26 · Sprecher 2: Genau.

07:27 · Sprecher 1: Meine Intuition als Autofahrer sagt mir jetzt, ich schaue einfach auf Google Maps, wo der Stau dunkelrot ist. Und in der Entwicklung wären das ja meine Metriken, mein Jira-Dashboard.

07:38 · Sprecher 2: Richtig.

07:39 · Sprecher 1: Und das bringt uns zu Little’s Law, das in unseren Quellen immer wieder zitiert wird. Lassen Sie uns das kurz einordnen: Es beschreibt mathematisch den Zusammenhang zwischen der Menge angefangener Arbeit – dem Work in Progress, kurz WIP –, dem Durchsatz und der Durchlaufzeit.

07:57 · Sprecher 2: Ja, exakt.

07:58 · Sprecher 1: Im Grunde funktioniert das doch wie in einem Café, oder?

08:01 · Sprecher 2: Der Vergleich mit dem Café passt wirklich sehr gut. Wie würden Sie das Prinzip denn dort beschreiben?

08:06 · Sprecher 1: Im Grunde funktioniert das wie in einem Café. Wenn 20 Menschen in der Schlange stehen, ist das unser WIP. Schafft der Barista zwei Kaffees pro Minute, ist das der Durchsatz. Unter diesen vereinfachten Annahmen ergibt sich eine durchschnittliche Durchlaufzeit von zehn Minuten. Aber wenn diese Beziehung so klar ist, muss ich etwas provozieren.

08:36 · Sprecher 2: Gerne.

08:37 · Sprecher 1: Warum kappe ich dann nicht einfach per Management-Dekret den WIP? Ich verbiete dem Team, mehr als fünf Tickets gleichzeitig offen zu haben und zack, mein Stau löst sich auf. Problem gelöst, oder?

08:49 · Sprecher 2: Ja, das ist ein extrem verlockender Gedanke. Aber genau da müssen wir aufpassen, dass wir Ursache und Wirkung nicht verwechseln.

08:57 · Sprecher 1: Okay.

08:58 · Sprecher 2: Little’s Law ist eine brillante mathematische Beschreibung für stabile Systeme. Aber, und das ist jetzt der springende Punkt, es beweist absolut keine konkrete Ursache für ihren spezifischen Stau.

09:09 · Sprecher 1: Mhm.

09:10 · Sprecher 2: Und es identifiziert vor allem keinen lokalen Engpass.

09:13 · Sprecher 1: Das Gesetz sagt mir also, dass es sich staut, aber nicht, warum der Barista heute so langsam ist?

09:20 · Sprecher 2: Ganz genau. Metriken wie ein hoher WIP-Bestand oder ein hohes Ticketalter, das sogenannte Work Item Age oder eben auch lange Cycle Times, das sind extrem wertvolle diagnostische Signale.

09:32 · Sprecher 1: Okay.

09:33 · Sprecher 2: Sie sind wie ein Fieberthermometer. Das Thermometer sagt Ihnen zuverlässig, dass der Patient 40 Grad Fieber hat. Es sagt Ihnen aber nicht, ob die Ursache eine Grippe, eine Entzündung oder etwas ganz anderes ist.

09:45 · Sprecher 1: Verstehe.

09:46 · Sprecher 2: Ein hoher Bestand an unfertiger Arbeit ist fast immer ein Symptom, aber nicht zwingend die Wurzel des Problems. Wenn wir also einfach nur blind den WIP limitieren, ohne wirklich zu verstehen, warum sich die Arbeit überhaupt staut, dann verlagern wir das Problem oft nur.

10:02 · Sprecher 1: Ah, okay. Wir drücken den Stau also einfach an eine andere Stelle. Dann staut sich die Arbeit eben vor dem Backlog. Und die Fachabteilungen beschweren sich, dass ihre tollen neuen Ideen nicht mehr angenommen werden.

10:14 · Sprecher 2: Genau so ist es.

10:15 · Sprecher 1: Oder, und das habe ich auch schon oft gesehen, die Leute dokumentieren ihre Aufgaben einfach nicht mehr im Tool, um das künstliche WIP-Limit optisch einzuhalten. Die Arbeit wird dann komplett unsichtbar, aber sie ist natürlich immer noch da.

10:28 · Sprecher 2: Ja. Schatten-IT und versteckte Backlogs – ein klassisches Symptom.

10:32 · Sprecher 1: Und wenn wir über Metriken sprechen, in den Quellen tauchen ja auch Begriffe auf wie Cycle Time oder CI/CD-Pipelines für diejenigen, die vielleicht nicht jeden Tag tief im Maschinenraum sind. In dem Maschinenraum der Softwareentwicklung stehen CI/CD, also Continuous Integration und Continuous Deployment. Das ist im Grunde unser automatisiertes Fließband, das den Code vom Entwickler zum Kunden bringt.

10:57 · Sprecher 2: Genau.

10:57 · Sprecher 1: Und auch dort messen wir ja permanent irgendwelche Zeiten. Aber wie Sie sagen, das sind am Ende alles nur Fieberthermometer.

11:05 · Sprecher 2: Richtig. Sie messen die Symptome eines Systems, das völlig aus dem Gleichgewicht geraten ist.

11:11 · Sprecher 1: Wenn nun aber das Fieberthermometer glüht, das Team liefert zu langsam, die ganzen Dashboards leuchten rot – was ist dann die typische Reaktion?

11:20 · Sprecher 2: Das wissen Sie als Führungskraft wahrscheinlich am besten.

11:23 · Sprecher 1: Ja, da muss ich gar nicht lange überlegen. Wir brauchen mehr Leute. Wenn das Haus brennt, rufe ich mehr Feuerwehrleute. Die logische Managemententscheidung lautet also ganz oft, wir stellen neue Entwickler ein.

11:36 · Sprecher 2: Ja.

11:37 · Sprecher 1: Warum um alles in der Welt warnen unsere Quellen so extrem eindringlich davor, dass zusätzliches Personal den Stau oft noch viel schlimmer macht?

11:45 · Sprecher 2: Weil wir hier wieder der Illusion der lokalen Effizienz aufsitzen. Lassen Sie uns das mal an einem ganz konkreten Praxisbeispiel aus der technischen Produktentwicklung durchspielen.

11:54 · Sprecher 1: Gerne.

11:55 · Sprecher 2: Wohlwissend, dass das nur ein mögliches Szenario von vielen ist: Nehmen wir an, Ihr Unternehmen entwickelt ein mechatronisches System – also Software, die auf komplexer physischer Hardware laufen muss. Das Management sieht rote Dashboards und schließt daraus, dass die Softwarefeatures zu lange dauern. Die reflexartige Reaktion lautet: Wir genehmigen Budget und stellen sofort fünf neue Senior-Softwareentwickler ein.

12:18 · Sprecher 1: Klingt erstmal vernünftig.

12:20 · Sprecher 2: Das fundamentale Problem dabei ist aber, der tatsächliche Engpass des Systems liegt in diesem speziellen Fall vielleicht gar nicht beim Schreiben des Quellcodes.

12:28 · Sprecher 1: Klar, wenn der Code geschrieben ist, ist das Feature noch lange nicht beim Kunden. Sie spielen auf die nachgelagerten Prozesse an.

12:35 · Sprecher 2: Absolut. Der echte wirksame Engpass liegt in unserem Beispiel vielleicht bei einer knappen Integrationsumgebung.

12:41 · Sprecher 1: Okay.

12:41 · Sprecher 2: Einem sogenannten Hardware-in-the-Loop-Prüfstand, an dem die Software zum allerersten Mal auf die echte physische Hardware trifft und getestet wird. Davon gibt es im Unternehmen vielleicht nur zwei Stück und die sind ständig belegt.

12:54 · Sprecher 1: Ah, okay.

12:55 · Sprecher 2: Oder der Engpass ist eine sehr strenge regulatorische Freigabeinstanz. Manchmal ist es auch ein einzelner stark gefragter Spezialist für Systemarchitektur, der bestimmte Sicherheitsfreigaben erteilen muss.

13:09 · Sprecher 1: Und was passiert jetzt, wenn ich in genau dieses System meine fünf teuren, hochmotivierten neuen Entwickler reinsetze? Die fangen natürlich sofort an, fröhlich neuen Code zu produzieren, weil sie ja auch zeigen wollen, was sie können.

13:23 · Sprecher 2: Und genau das führt dann zur absoluten Katastrophe. Warum? Weil der echte Engpass am Ende des Prozesses sitzt, also an unserem Prüfstand, staut sich dieser viele neue Code einfach nur noch schneller davor. Die neuen Entwickler produzieren am laufenden Band Arbeit, die aber nicht abfließen kann. Mehr Personal hilft in einem System wirklich nur dann zuverlässig, wenn es den tatsächlichen Engpass entlastet.

13:48 · Sprecher 1: Das leuchtet ein. Wir haben also noch mehr Autos auf die Autobahn geschickt, obwohl die Baustelle am Ende immer noch nur einspurig ist.

13:55 · Sprecher 2: Richtig.

13:56 · Sprecher 1: Aber es wird ja noch schlimmer, oder?

13:58 · Sprecher 2: Deutlich schlimmer. Wenn Sie mehr Entwickler in ein System geben, dessen Engpass bei Freigabe oder Hardware-Integration liegt, erzeugt die zusätzliche Parallelität ein weiteres Nadelöhr mit massivem Koordinationsaufwand.

14:10 · Sprecher 1: Oh ja, die treten sich dann gegenseitig auf die Füße.

14:12 · Sprecher 2: Genau. Es entstehen Merge-Konflikte, weil plötzlich mehr Menschen gleichzeitig an ähnlichen Stellen im System arbeiten. Es braucht mehr Abstimmung, die Kontextwechsel nehmen zu, und die neuen Mitarbeitenden müssen eingearbeitet werden. Dadurch binden sie zunächst Kapazität der ohnehin stark belasteten erfahrenen Entwickler.

14:33 · Sprecher 1: Das ist im Grunde das berühmte Brooks’sche Gesetz in Aktion, oder? Sinngemäß: Zusätzliche Menschen machen ein bereits verspätetes Softwareprojekt noch später.

14:42 · Sprecher 2: Genau. In einem bereits verspäteten Projekt kann zusätzliche Kapazität das System zunächst langsamer machen, wenn sie den wirksamen Engpass nicht entlastet.

14:47 · Sprecher 1: Puh. Okay, fassen wir mal kurz zusammen. Bauchgefühl führt uns in die Irre. Metriken und Formeln wie Little’s Law zeigen uns nur die Symptome.

14:57 · Sprecher 2: Ja.

14:57 · Sprecher 1: Und einfach planlos mehr Personal draufzuwerfen, kann das System komplett zum Kollabieren bringen. Da muss ich jetzt als Geschäftsführer aber langsam echt verzweifeln. Wie zur Hölle finde ich denn dann heraus, wo die Arbeit wirklich wartet?

15:12 · Sprecher 2: Und hier kommt in unseren Quellen das sogenannte EngpassAudit ins Spiel. Das ist eine spezifische Methodik zur Engpassanalyse.

15:22 · Sprecher 1: Da muss ich jetzt aber mal kurz die CTO-Brille aufsetzen und hart widersprechen.

15:26 · Sprecher 2: Bitte.

15:26 · Sprecher 1: Ein Audit – zehn Arbeitstage für Interviews und Analysen. Warum brauche ich das? Meine Tools, also Jira, GitLab oder Azure DevOps, protokollieren doch jeden Commit und jede Millisekunde. Warum ziehe ich nicht einfach einen detaillierten Report und weiß in fünf Minuten, wo der Engpass ist?

15:49 · Sprecher 2: Das ist ein weit verbreiteter und verlockender Gedanke. Aber die Daten aus Ihren Tools sind keine universelle, unangreifbare Wahrheit. Tooldaten hängen stark von der Erfassungsdisziplin im Team und davon ab, wie Workflows tatsächlich gelebt werden – im Gegensatz zu dem, was vielleicht auf dem Papier steht.

16:15 · Sprecher 1: Geben Sie mir da mal ein Beispiel. Wo lügt mich mein Jira an?

16:19 · Sprecher 2: Stellen Sie sich einen Entwickler vor, der an einem Ticket arbeitet. Er stößt auf ein Problem und braucht eine Entscheidung vom Produktmanager. Er schreibt eine E-Mail und wartet. Im Tool lässt er das Ticket aber häufig auf „In Progress“ stehen. Das Tool vermittelt dem Management dadurch den Eindruck, dass aktiv gearbeitet wird.

16:39 · Sprecher 1: Oh ja.

16:40 · Sprecher 2: Die Realität ist aber, die Arbeit ruht komplett. Sie wartet auf eine Antwort. Oder das genaue Gegenteil passiert. Blockierte Arbeit wird in irgendwelche Parked- oder On-Hold-Status verschoben. Und die werden dann aus Ihren schicken Auswertungen und Metriken für die Durchlaufzeit einfach automatisch herausgefiltert.

16:57 · Sprecher 1: Ah.

16:58 · Sprecher 2: Wir nennen dieses Phänomen in der Analyse informative Zensierung.

17:03 · Sprecher 1: Informative Zensierung, also quasi das Phänomen, dass das Tool uns belügt, weil es den Stillstand systematisch ausblendet. Exakt. Das ist ja wie ein Blitzer an der Autobahn, der nur die Autos fotografiert, die mit 130 km/h vorbeirauschen, aber den zehn Kilometer langen Stau direkt dahinter einfach ignoriert, weil stehende Autos seinen Sensor nicht auslösen.

17:24 · Sprecher 2: Das ist ein exzellentes Bild. Genau das passiert. Und genau deshalb können Sie sich eben nicht blind auf die reinen Systemdaten verlassen. Aber – und das ist jetzt genauso wichtig – Sie können sich auch nicht ausschließlich auf Interviews verlassen.

17:38 · Sprecher 1: Warum nicht? Da frage ich doch die echten Menschen.

17:41 · Sprecher 2: Weil das die andere Seite der Medaille ist. Wenn Sie nur die Leute fragen, dann sieht jeder die Welt durch die gefärbte Brille seiner eigenen Abteilung.

17:48 · Sprecher 1: Stimmt auch wieder.

17:49 · Sprecher 2: Die QA-Abteilung sagt dann, boah, die Entwickler liefern heute wieder miese Qualität. Und die Entwickler sagen, ach, die QA ist ein rein bürokratisches System. Das ist ein dramatischer Albtraum und viel zu langsam.

17:59 · Sprecher 1: Klassiker.

18:00 · Sprecher 2: Beide Evidenzformen, also Daten und Interviews, können unvollständig oder eben verzerrt sein. Und sie müssen unbedingt gegeneinander geprüft werden.

18:09 · Sprecher 1: Und das EngpassAudit bringt diese beiden Welten dann zusammen?

18:13 · Sprecher 2: Ganz genau. Die Methodik verschneidet quantitative Datenanalyse aus den Tools mit qualitativen Interviews.

18:21 · Sprecher 1: Und da gibt es ein Werkzeug, das in den Quellen besonders hervorgehoben wird: sogenannte Falltraces. Das klang für mich beim Lesen fast nach kriminalistischer Detektivarbeit. Was genau passiert da?

18:34 · Sprecher 2: Bei einem Falltrace nimmt man nicht den Durchschnitt von tausend anonymen Tickets, sondern greift ein konkretes Feature, Vorhaben oder Release der letzten Zeit heraus. Dann rekonstruiert man den gesamten Lebenszyklus chronologisch – vom ersten Konzeptgedanken bis zu dem Moment, in dem der Kunde das Ergebnis wirklich nutzen konnte. Man geht den relevanten Ende-zu-Ende-Fluss nach und gleicht die dokumentierten Schritte mit den Wahrnehmungen der beteiligten Rollen ab.

19:04 · Sprecher 1: Also wir rekonstruieren quasi den Tatort?

19:07 · Sprecher 2: Sozusagen, ja.

19:08 · Sprecher 1: Ich frage dann den Entwickler, schau mal, laut Jira lag dieses wichtige Feature vom 14. bis zum 20. Mai in der Review-Spalte. Was ist da wirklich passiert?

19:19 · Sprecher 2: Richtig. Der Entwickler sagt vielleicht: „Ich war am 14. eigentlich fertig, musste aber noch auf die Freigabe aus dem Testlabor warten.“ Wenn Sie dann mit dem Laborleiter sprechen, sagt dieser möglicherweise: „Das Labor war die ganze Woche frei, aber die Software war bei der Übergabe noch nicht testbereit konfiguriert.“

19:38 · Sprecher 1: Wahnsinn. Plötzlich haben Sie einen echten, belastbaren Einblick in die wirkliche Systemdynamik. Widersprüchliche Wahrnehmungen werden so direkt abgeglichen.

19:49 · Sprecher 2: Das ist der springende Punkt.

19:50 · Sprecher 1: Die Methodik trennt dabei ja offenbar extrem strikt zwischen einer bloßen Beobachtung, einer Hypothese und echter Evidenz.

19:58 · Sprecher 2: Absolut, ja.

19:59 · Sprecher 1: Und was mir bei der Lektüre der Quellen sehr positiv aufgefallen ist, es geht hier bei null um Fingerpointing.

20:06 · Sprecher 2: Nein, überhaupt nicht.

20:07 · Sprecher 1: Das Audit bewertet nicht, wer am härtesten arbeitet oder wer vermeintlich am wenigsten leistet. Es gibt kein Blame Game und keine versteckte Leistungsbewertung von Personen. Es sucht nach Bedingungen im Systemdesign, die Arbeit zum Warten zwingen, richtig?

20:22 · Sprecher 2: Ganz genau so ist es. Es untersucht ausschließlich, wo die Arbeit tatsächlich wartet und welche Abhängigkeit die Fertigstellung am Ende begrenzt.

20:28 · Sprecher 1: Okay. Lassen wir die Theorie mal kurz beiseite. Wenn ich als Manager nach diesen zehn Tagen Audit-Prozess morgens in die Firma komme, was genau mache ich mit dieser Erkenntnis?

20:41 · Sprecher 2: Ja, gute Frage.

20:42 · Sprecher 1: Eine philosophische Diskussion über Systemdesign hilft mir ja nicht weiter. Wenn mein Release brennt, was halte ich ganz konkret in der Hand, um handlungsfähig zu werden, ohne gleich das gesamte Unternehmen in so einer jahrelangen agilen Transformation umzukrempeln?

20:57 · Sprecher 2: Die Quellen skizzieren hier sehr praxisnahe, managementtaugliche Ergebnisse.

21:02 · Sprecher 1: Okay.

21:03 · Sprecher 2: Erstens erhalten Sie eine fundierte Engpasskarte. Sie visualisiert den Ende-zu-Ende-Fluss und trennt sichtbare Symptome von prüfbaren Engpasshypothesen. Zweitens bekommen Sie eine priorisierte Ursachenanalyse.

21:20 · Sprecher 1: Und daraus leiten sich dann die Maßnahmen ab. Aber bitte sagen Sie mir jetzt nicht, dass das Management eine 150-Punkte-Checkliste bekommt, die sowieso niemand abarbeitet.

21:30 · Sprecher 2: Nein, im Gegenteil. Drittens liefert das Audit genau fünf fokussierte Sofortmaßnahmen. Nicht mehr. Keine vagen „Wir müssen alle besser kommunizieren“-Tipps, sondern präzise umsetzbare Hebel, die am identifizierten Engpass ansetzen.

21:48 · Sprecher 1: Sehr gut.

21:49 · Sprecher 2: Und viertens gibt es einen adaptiven 30-, 60- und 90-Tage-Plan für die Umsetzung. Das liefert Ihnen als Management eine enorm belastbare Entscheidungsgrundlage.

22:00 · Sprecher 1: Da muss ich aber kurz die Erwartungshaltung erden, denn auch das steht sehr transparent in den Unterlagen. Wir reden hier nicht von Magie, oder? Es gibt keine hundertprozentige Garantie.

22:10 · Sprecher 2: Völlig richtig. Diese fachlichen Grenzen müssen wir ganz klar ziehen. Ein seriöser Audit-Prozess wird Ihnen niemals versprechen, dass er garantiert eine doppelt so schnelle Delivery bringt.

22:20 · Sprecher 1: Okay.

22:21 · Sprecher 2: Oder dass er für alle Ewigkeit den einen wahren, ultimativen Engpass findet. In komplexen Systemen geht es um Wahrscheinlichkeiten. Es geht darum, die Maßnahme zu finden, die den größten überprüfbaren Effekt auf den gesamten Fluss verspricht. Wenn ein Engpass entlastet wird, kann sich die wirksame Begrenzung an eine andere Stelle des Systems verlagern. Das ist ein normaler Teil kontinuierlicher Verbesserung.

22:47 · Sprecher 1: Puh, das war ein echt intensiver Ritt durch die Maschinenräume der Produktentwicklung. Lassen Sie uns die wichtigsten Erkenntnisse für Sie noch einmal kompakt zusammenfassen, damit Sie sie direkt in Ihren Alltag mitnehmen können.

22:59 · Sprecher 2: Gerne.

23:00 · Sprecher 1: Also, erstens, Vollbeschäftigung in Ihrem Team ist absolut nicht dasselbe wie Fertigstellung.

23:07 · Sprecher 2: Richtig.

23:08 · Sprecher 1: Zweitens: Je näher ein variables Entwicklungssystem an seine wirksame Kapazitätsgrenze kommt, desto stärker steigt das Risiko langer Warteschlangen und Durchlaufzeiten. Die Autobahn verstopft. Drittens: Ihre Jira-Metriken und Formeln zeigen Muster, beweisen aber nicht automatisch die wahre Ursache. Sie sind das Fieberthermometer, nicht das MRT.

23:33 · Sprecher 2: Sehr schönes Bild, ja.

23:36 · Sprecher 1: Viertens, mehr Personal hilft Ihrem System nur dann zuverlässig, wenn es den tatsächlichen Engpass entlastet. Andernfalls produzieren neue Leute nur noch mehr Stau und Chaos.

23:47 · Sprecher 2: Absolut.

23:48 · Sprecher 1: Und fünftens, ein EngpassAudit untersucht genau diesen Ende-zu-Ende-Fluss, gleicht Daten mit Interviews ab und priorisiert überprüfbare Maßnahmen, anstatt in subjektiven Schuldzuweisungen zu enden.

24:01 · Sprecher 2: Und zum Abschluss noch ein provokanter Gedanke für den nächsten Blick auf Ihr Ressourcendashboard: Was, wenn der Versuch, jede Abteilung für sich auf maximale lokale Effizienz zu trimmen, genau dazu beiträgt, dass das Gesamtprodukt zu spät auf den Markt kommt?

24:28 · Sprecher 1: Das ist eine Frage, die wehtut, aber die richtigen Denkprozesse anstößt. Wenn Sie ähnliche Muster in Ihrer technischen Entwicklung erkennen, können Sie auf engpassaudit.de prüfen, ob ein EngpassAudit zu Ihrer Situation passt, und einen unverbindlichen Audit-Fit vereinbaren.