Wenn ihr die Durchlaufzeit eines einzelnen Features aufschlüsselt, in aktive Arbeit und in Warten, ist der wartende Anteil fast immer der größere. Meistens deutlich. Trotzdem wird bei euch über Kapazität gesprochen und fast nie über Wartezeit. Kapazität steht im Budget. Wartezeit steht nirgends. Deshalb verteidigt sie niemand, und deshalb greift sie auch niemand an.
Ich schreibe das gleich hier hin, weil ihr es sonst drei Absätze später selbst merkt und den Rest anders lest. Was jetzt kommt, ist alles, was ihr für eine Entscheidung braucht, einschließlich der Teile, die dagegen sprechen. Weiter unten steht ein Abschnitt darüber, für wen die zwei Tage nichts sind, und einer mit acht Einwänden. Bei zweien davon lautet meine Antwort: dann buch nicht.
Sechs Fragen, bevor ihr weiterlest
Jede Frage ist in einer Minute zu beantworten. Keine davon ist rhetorisch gemeint.
Erstens. Kennt ihr die Durchlaufzeit eines Features von der Idee bis zur Auslieferung? Nicht das Projektende, sondern ein einzelnes Feature. Schätzen zählt als Nein.
Zweitens. Wenn ihr diese Zeit aufteilt in aktive Arbeit und Warten: kennt ihr das Verhältnis? Nicht ungefähr, sondern für einen konkreten Fall aus dem letzten Jahr.
Drittens. Nennt eine eurer Freigabestufen, die in den letzten drei Jahren tatsächlich einmal etwas gestoppt hat. Wenn euch keine einfällt, ist das die Antwort.
Viertens. Wer entscheidet, wenn zwei Teams sich über eine Schnittstelle nicht einigen? Eine Person, oder ein Gremium mit dem nächsten Termin in drei Wochen?
Fünftens. Eure letzte große Verbesserung, ob Werkzeug, Methode oder Umorganisation: um wie viel ist die Durchlaufzeit danach gesunken? Wenn ihr die Zahl nicht habt, wisst ihr nicht, ob sie gewirkt hat.
Sechstens. Angenommen, morgen wäre die langsamste Stelle in eurer Entwicklung doppelt so schnell. Käme das Produkt früher beim Kunden an? Wenn nein, arbeitet ihr gerade an der falschen Stelle.
Wenn ihr drei oder mehr dieser Fragen nicht beantworten könnt, habt ihr kein Ressourcenproblem. Ihr habt ein Sichtbarkeitsproblem, und das ist die bessere Nachricht von beiden. Ressourcen muss man beantragen. Sichtbarkeit kann man herstellen.
Diese sechs Fragen sind ungefähr der erste Vormittag. Ihr könnt sie ohne mich stellen, und ihr solltet das auch tun. Was sie nicht leisten: sie benennen ein Symptom. Sie finden nicht den Engpass, und sie erzeugen keine Maßnahme, die danach jemand tatsächlich umsetzt. Genau das ist der Unterschied zwischen einem Selbsttest und zwei Tagen.
Warum es fast nie die Kapazität ist
Eine zusätzliche Entwicklerin beschleunigt den kleineren Teil eurer Durchlaufzeit. Eine kürzere Wartezeit beschleunigt den größeren. Diskutiert wird trotzdem fast immer über die Entwicklerin.
Das hat einen strukturellen Grund. Wer eine Freigabestufe einführt, wird nie dafür bestraft. Wer eine entfernt, haftet für den ersten Fehler, der danach passiert. Also wächst die Zahl der Stufen nur in eine Richtung, nicht weil jemand das will, sondern weil in die Gegenrichtung keine Kraft wirkt. Dasselbe gilt für Abstimmungsrunden, für Gremien und für Schnittstellen, die niemand als Vertrag festgeschrieben hat.
Der übliche Einwand an dieser Stelle lautet: bei uns geht das nicht, wir sind reguliert. Der Einwand ist ernst gemeint und er ist teilweise berechtigt, deshalb steht dazu unten noch mehr. Ein Fall vorweg.
Wagner baut Anlagen, die den Sauerstoffgehalt in geschlossenen Räumen regeln. Die Regelung ist sicherheitskritisch, und jede Änderung am System muss durch den TÜV. Früher dauerten Zertifizierungszyklen viele Monate und ließen sich schlecht vorhersagen. Heute liefert das Unternehmen Änderungen in wenigen Wochen aus, Zertifizierung eingeschlossen, und die TÜV-Freigabe selbst dauert Tage, solange keine grundlegend neue Prüfkategorie dazukommt. Insgesamt etwa dreimal so schnell wie vorher.
Niemand bei Wagner arbeitet dafür mehr. Die Zertifizierung hat aufgehört, eine Warteschlange zu sein, und ist eine Fähigkeit der Plattform geworden: durchgängige Modelle, automatisierte Regressionstests in einer vom TÜV überwachten Umgebung, Nachvollziehbarkeit als Nebenprodukt statt als Extraaufwand. Die Auflagen sind dieselben geblieben. Der Weg dorthin ist ein anderer.
Das ist der Kern der zwei Tage. Nicht schneller arbeiten. Weniger warten.
Was in den zwei Tagen passiert
Tag eins beginnt um 9:30 Uhr und endet um 17:00 Uhr, Tag zwei läuft von 9:00 bis 17:00 Uhr. Mindestens sechs, höchstens zwölf Teilnehmende.
Vormittag Tag eins. Ihr zeichnet einen Wertfluss auf (gern euren eigenen), vom Bedarf bis zur Auslieferung. Nicht den Prozess, wie er im Handbuch steht, sondern den Weg, den ein konkretes Feature aus dem letzten Jahr tatsächlich genommen hat. In den meisten Fällen steht danach etwas, das die Beteiligten so noch nie gesehen haben, weil jeder immer nur den eigenen Abschnitt kannte.
Nachmittag Tag eins. Wir trennen aktive Arbeit von Wartezeit und rechnen nach. Dann suchen wir die eine Stelle, die das Tempo bestimmt. Die meisten Gruppen tippen zu Beginn auf eine andere Stelle als die, bei der sie am Ende landen.
Vormittag Tag zwei. Was Systems Engineering an diesem Engpass leisten kann. Anforderungen und Architektur so schneiden, dass Entscheidungen früher fallen. Schnittstellen als Verträge statt als Absprachen. MBSE dort, wo es Abstimmungszeit spart, und ausdrücklich nicht flächendeckend. Prüfen und Simulieren früher im Ablauf, damit Fehler auftauchen, bevor sie teuer werden.
Nachmittag Tag zwei. Ihr formuliert eine Maßnahme für die nächsten 30 Tage, gern für Eure eigene Situation. Eine, nicht fünf. Dazu gehört, wer sie umsetzt, wen ihr dafür überzeugen müsst und woran ihr in 30 Tagen erkennt, ob sie gewirkt hat. Ohne dieses letzte Stück ist die Maßnahme ein Vorsatz.
Was ihr mitnehmt: eure eigene Wertflussdarstellung, eine benannte Engpassstelle mit Begründung, eine Maßnahme mit Messgröße. Ein Teilnahmezertifikat gibt es dazu, für die Personalabteilung und für den Fall, dass jemand die zwei Tage nachweisen muss. Was ihr nicht mitnehmt: einen Foliensatz zum Ausrollen.
Für wen das nichts ist
Vier Fälle, in denen ihr euer Geld behalten solltet.
- Eure Durchlaufzeit ist in Ordnung, und ihr wisst das, weil ihr sie messt. Dann gibt es hier nichts zu holen.
- Ihr sucht eine Methode, die ihr im ganzen Haus einführt. Das hier setzt an einer konkreten Engstelle an und nicht als Programm. Wer ein Rollout plant, ist bei einem Rahmenwerk besser aufgehoben.
- Ihr wollt zwei Tage Überblick über Systems Engineering. Den gibt es bei oose, aber in einem anderen Seminar.
- Ihr kommt allein, aus einer Organisation, in der ihr nichts anstoßen könnt, und ohne dass jemand auf das Ergebnis wartet. Dazu gleich mehr, denn dieser Fall lässt sich beheben.
Warum ihr besser zu dritt kommt
Eine Person kommt aus Hamburg zurück, hat eine Maßnahme im Gepäck und muss sie jetzt drei Leuten erklären, die die zwei Tage nicht erlebt haben. Sie erklärt eine Schlussfolgerung ohne den Weg dorthin. Das gelingt selten, und es liegt nicht an der Person.
Drei Leute aus derselben Organisation kommen mit demselben Fall an, streiten die zwei Tage über denselben Wertfluss und fahren mit derselben Maßnahme zurück. Sie müssen einander nichts mehr erklären. Sie sind zu dritt, und drei Leute, die sich einig sind, können in den meisten Häusern eine Freigabestufe abschaffen. Eine Person kann das nicht.
Dazu kommt etwas Praktisches. Der Raum fasst zwölf Personen, und der Fall, an dem gearbeitet wird, ist der Fall, den jemand mitbringt. Wenn ihr zu dritt kommt, stellt ihr ein Viertel des Raums und arbeitet zwei Tage lang garantiert an eurem eigenen System.
Für Gruppen gibt es einen eigenen Preis. Der steht nicht auf der Seite, weil er vom Zuschnitt abhängt. Schreibt mir, dann rechnen wir das durch.
Acht Einwände
1. “Zwei Tage kann ich nicht abwesend sein”
Das stimmt vermutlich, und es ist genau das Symptom. Eine Entwicklungsorganisation, in der zwei Tage einer einzelnen Person den Ablauf gefährden, hat keine Kapazitätsreserve und damit auch keine Fähigkeit, auf irgendetwas zu reagieren. Rechnet trotzdem einmal gegen: wenn bei euch pro Feature vier Wochen Wartezeit anfallen und ihr davon eine Woche entfernt, sind die zwei Tage nach dem ersten Feature bezahlt.
2. “1.650 Euro plus Reise muss ich freigeben lassen”
Ja. Und ihr werdet dabei erfahren, wie lange eine Freigabe bei euch dauert und über wie viele Stufen sie läuft. Notiert das Datum, an dem ihr fragt, und das Datum, an dem ihr eine Antwort bekommt. Diese Zahl ist Teil der Diagnose, egal wie die Antwort ausfällt. Bringt sie mit.
3. “Wir haben doch gerade erst PLM eingeführt” (oder MBSE, oder SAFe)
Alle drei sind nützlich, und ich argumentiere gegen keines davon. Der Punkt ist ein anderer. Nach solchen Einführungen sehe ich regelmäßig, dass die Sprache neu ist und die Rollen neue Namen haben, während die Anreize dieselben geblieben sind, die Freigabewege auch, und die Frage, wer entscheiden darf, sich nicht verschoben hat. Struktur wurde umbenannt, Verhalten nicht. Ein Werkzeug kann man kaufen. Eine Entscheidungsbefugnis muss jemand abgeben. Das erste steht im Budget, das zweite kostet politisch, also wird das erste gemacht.
Wenn eure Durchlaufzeit nach der Einführung gesunken ist, habt ihr das Problem nicht. Wenn ihr die Zahl nicht kennt, siehe Frage fünf.
4. “Bei uns ist alles reguliert, da geht das nicht”
Die Auflagen sind real und nicht verhandelbar, da gebe ich euch vollständig recht. Was verhandelbar ist, ist der Weg dorthin.
In fast jeder regulierten Organisation, die ich gesehen habe, gibt es zwei Sorten von Pflichten. Die erste steht in der Norm oder verlangt der Prüfer. Die zweite hat vor Jahren jemand eingeführt, weil einmal etwas schiefgegangen war, und seitdem hat sie niemand angefasst. Die zweite Sorte ist meistens die größere, und niemand kann sie mehr auseinanderhalten. Der erste nützliche Schritt ist, die beiden Listen zu trennen. Wagner musste die TÜV-Anforderungen nicht abschwächen, um dreimal schneller zu werden.
5. “Software-Prinzipien lassen sich nicht auf Hardware übertragen”
Die Werkzeuge nicht, da habt ihr recht. Ein fehlerhaftes Deployment lässt sich zurückrollen, ein ausgeliefertes Steuergerät nicht.
Die Prinzipien übertragen sich. Kleine Chargen statt großer. Rückmeldung früh statt am Ende. Schnittstellen als Verträge. Verantwortung dort, wo die Entscheidung fällt. Keines davon setzt voraus, dass man zurückrollen kann. Alle verkürzen die Zeit zwischen einer Entscheidung und dem Wissen, ob sie richtig war. Diese Zeit ist in der Hardwareentwicklung teurer als in der Software, nicht billiger. Der Hebel ist also größer.
6. “Ich kann bei uns sowieso nichts entscheiden”
Dann kommt nicht allein. Das ist keine Floskel, sondern die ehrliche Antwort auf diesen Einwand. Wenn ihr die Maßnahme, die ihr am zweiten Nachmittag formuliert, anschließend niemandem verkaufen könnt, waren die zwei Tage interessant und folgenlos. Bringt die Person mit, die entscheidet, oder mindestens zwei Leute, die zusammen Gewicht haben. Wenn das nicht möglich ist, spart euch das Geld und lest stattdessen die sechs Fragen noch einmal.
7. “Ich schicke erstmal einen Kollegen zum Anschauen”
Verständlich, und es ist die übliche Vorsichtsmaßnahme. Sie funktioniert hier schlecht. Ein Kundschafter kommt mit einem Bericht zurück, und ein Bericht über einen Wertfluss ist ungefähr so nützlich wie ein Bericht über ein Konzert. Drei Leute kommen mit einer gemeinsamen Diagnose zurück. Wenn das Budget nur für eine Person reicht, schickt die Person, die im Zweifel etwas ändern darf, nicht die, die gerade am wenigsten ausgelastet ist.
8. “Wir stecken mitten im Projekt, danach gerne”
Das Timing ist tatsächlich schlecht. Ich will euch das nicht ausreden, und der Satz, dass es nie einen guten Zeitpunkt gibt, hilft niemandem weiter.
Zwei Dinge dazu, dann entscheidet ihr. Erstens ist der Fall, an dem ihr in Hamburg arbeitet, genau dieses Projekt, und die Maßnahme wirkt in den nächsten 30 Tagen, also noch währenddessen. Zweitens gibt es einen nächsten Durchlauf, und wenn September nicht geht, schreibt mir eine Zeile. Dann melde ich mich, sobald ein Termin steht, und muss euch später nicht kalt anschreiben.
Der eigentliche Stichtag ist der 7. September
Nicht der 21. September. oose sagt Seminare ab, die zwei Wochen vor dem Termin unter der Mindestteilnehmerzahl liegen, und die liegt bei sechs. Das ist die Regel des Veranstalters und keine Verkaufstaktik. Ich schreibe sie hin, weil ich in den letzten Wochen mehrfach gehört habe: klingt gut, ich melde mich später an. Später ist in diesem Fall der 7. September.
Umgekehrt gilt dasselbe: wenn ihr zu dritt bucht, ist die Hälfte der Mindestzahl erreicht, und die Frage, ob das Seminar stattfindet, hängt für euch nicht mehr an Fremden.
Wenn ihr euch entscheidet
Zurück zu Frage sechs. Wenn morgen die langsamste Stelle in eurer Entwicklung doppelt so schnell wäre, käme euer Produkt dann früher beim Kunden an?
Wer diese Frage mit Ja beantwortet und die Stelle benennen kann, braucht das Seminar nicht. Fangt einfach an. Wer sie mit Ja beantwortet und die Stelle nicht benennen kann, hat den Grund, zwei Tage dafür aufzuwenden.
Anmeldung und Details: oose.de/pv
Wenn ihr zu dritt oder größer kommen wollt, schreibt mir vorher. Das ist eine andere Rechnung, und wir sollten kurz klären, an welchem Fall ihr die zwei Tage arbeitet.
