Wenn ihr die Durchlaufzeit eines einzelnen Features in aktive Arbeit und Wartezeit aufschlüsselt, ist der Anteil der Wartezeit fast immer größer. Meistens sogar deutlich. Trotzdem wird bei euch über Kapazität gesprochen und fast nie über Wartezeit. Kapazität ist im Budget vorgesehen. Wartezeit taucht nirgendwo auf. Deshalb verteidigt sie niemand, und deshalb greift sie auch niemand an.
Ich schreibe das gleich hier auf, weil ihr es sonst drei Absätze später selbst bemerkt und den Rest anders lest. Was jetzt folgt, ist alles, was ihr für eine Entscheidung braucht, einschließlich der Argumente, die dagegen sprechen. Weiter unten findet ihr einen Abschnitt darüber, für wen die zwei Tage nichts sind, und einen mit acht Einwänden. Auf zwei davon lautet meine Antwort: Dann buche nicht.
Sechs Fragen, bevor ihr weiterlest
Jede Frage muss innerhalb einer Minute beantwortet werden. Keine davon ist rhetorisch gemeint.
Erstens. Wisst ihr, wie lange die Durchlaufzeit einer Funktion von der Idee bis zur Auslieferung dauert? Nicht bis zum Projektende, sondern für eine einzelne Funktion. Eine Schätzung gilt als „Nein“.
Zweitens. Wenn ihr diese Zeit in aktive Arbeit und Wartezeit unterteilt: Wie sieht dabei das Verhältnis aus? 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 sich zwei Teams nicht über eine Schnittstelle einigen können? Eine Person oder ein Gremium, dessen nächste Sitzung erst in drei Wochen stattfindet?
Fünftens. Eure letzte große Verbesserung – sei es ein Werkzeug, eine Methode oder eine Umstrukturierung: Um wie viel hat sich die Durchlaufzeit danach verringert? Wenn ihr diese Zahl nicht kennt, wisst ihr nicht, ob sie etwas bewirkt hat.
Sechstens. Angenommen, morgen wäre der langsamste Schritt in eurer Entwicklung doppelt so schnell. Würde das Produkt dann früher beim Kunden ankommen? 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 schaffen.
Diese sechs Fragen decken in etwa den ersten Vormittag ab. Ihr könnt sie ohne mich stellen, und das solltet ihr auch tun. Was sie jedoch nicht leisten: Sie benennen lediglich ein Symptom. Sie decken nicht den Engpass auf, und sie führen nicht zu einer Maßnahme, die anschließend tatsächlich von jemandem umgesetzt wird. Genau darin liegt der Unterschied zwischen einem Selbsttest und zwei Tagen.
Warum es fast nie an der Kapazität liegt
Eine zusätzliche Entwicklerin verkürzt den kleineren Teil eurer Durchlaufzeit. Eine kürzere Wartezeit verkürzt den größeren Teil. Dennoch dreht sich die Diskussion fast immer um die Entwicklerin.
Das hat einen strukturellen Grund. Wer eine Freigabestufe einführt, wird dafür niemals bestraft. Wer eine abschafft, haftet für den ersten Fehler, der danach passiert. Daher wächst die Anzahl der Stufen nur in eine Richtung – nicht, weil jemand das will, sondern weil in die entgegengesetzte Richtung keine Kraft wirkt. Das Gleiche gilt für Abstimmungsrunden, für Gremien und für Schnittstellen, die niemand vertraglich festgelegt hat.
Der übliche Einwand an dieser Stelle lautet: Bei uns geht das nicht, wir unterliegen regulatorischen Auflagen. Der Einwand ist ernst gemeint und teilweise berechtigt, daher dazu weiter unten noch mehr. Zunächst ein Beispiel.
Wagner baut Anlagen, die den Sauerstoffgehalt in geschlossenen Räumen regeln. Die Regelung ist sicherheitskritisch, und jede Änderung am System muss vom TÜV genehmigt werden. Früher dauerten Zertifizierungszyklen viele Monate und ließen sich nur schwer vorhersagen. Heute liefert das Unternehmen Änderungen innerhalb weniger Wochen aus, einschließlich der Zertifizierung, und die TÜV-Freigabe selbst dauert nur noch Tage, sofern keine grundlegend neue Prüfkategorie hinzukommt. Insgesamt etwa dreimal so schnell wie zuvor.
Niemand bei Wagner arbeitet mehr dafür. Die Zertifizierung ist keine Warteschlange mehr, sondern eine Funktion der Plattform geworden: durchgängige Modelle, automatisierte Regressionstests in einer vom TÜV überwachten Umgebung, Nachvollziehbarkeit als Nebenprodukt statt als zusätzlicher Aufwand. Die Anforderungen sind dieselben geblieben. Der Weg dorthin ist ein anderer.
Das ist der Kern dieser zwei Tage. Nicht schneller arbeiten. Weniger warten.
Was in den zwei Tagen passiert ist
Tag eins beginnt um 9:30 Uhr und endet um 17:00 Uhr, Tag zwei dauert von 9:00 bis 17:00 Uhr. Mindestens sechs, höchstens zwölf Teilnehmer.
Vormittag, Tag eins. Ihr stellt einen Wertfluss dar (gerne euren eigenen), vom Bedarf bis zur Auslieferung. Nicht den Prozess, wie er im Handbuch beschrieben ist, sondern den Weg, den ein konkretes Feature aus dem letzten Jahr tatsächlich genommen hat. In den meisten Fällen ergibt sich daraus ein Bild, das die Beteiligten so noch nie gesehen haben, da jeder bisher immer nur den eigenen Abschnitt kannte.
Nachmittag, Tag eins. Wir unterscheiden zwischen aktiver Arbeit und Wartezeit und berechnen die Zeit. Anschließend suchen wir die Stelle, die das Tempo bestimmt. Die meisten Gruppen tippen zu Beginn auf eine andere Stelle als die, bei der sie letztendlich landen.
Vormittag, Tag zwei. Was Systems Engineering an diesem Engpass leisten kann. Anforderungen und Architektur so aufeinander abstimmen, dass Entscheidungen früher getroffen werden. Schnittstellen als Verträge statt als Vereinbarungen. 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, gerne bezogen auf 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 erkennen könnt, ob sie gewirkt hat. Ohne diesen letzten Punkt ist die Maßnahme nur ein Vorsatz.
Was ihr mitnehmt: eure eigene Wertflussdarstellung, eine benannte Engpassstelle mit Begründung, eine Maßnahme mit Messgröße. Dazu gibt es eine Teilnahmebescheinigung – für die Personalabteilung und für den Fall, dass jemand die beiden Tage nachweisen muss. Was ihr nicht mitbringt: einen Foliensatz zum Vortragen.
Für wen das nichts ist
Vier Fälle, in denen ihr euer Geld lieber behalten solltet.
- Eure Durchlaufzeit ist in Ordnung, und das wisst ihr, weil ihr sie misst. Dann gibt es hier nichts zu holen.
- Ihr sucht nach einer Methode, die ihr im ganzen Haus einführen könnt. Diese hier zielt auf einen konkreten Engpass ab und ist kein Programm. Wer eine flächendeckende Einführung plant, ist mit einem Rahmenwerk besser beraten.
- Ihr wollt einen zweitägigen Überblick über Systems Engineering. Den gibt es bei oose, allerdings in einem anderen Seminar.
- Ihr kommt allein, aus einer Organisation, in der ihr nichts auf den Weg bringen könnt, und ohne dass jemand auf das Ergebnis wartet. Dazu gleich mehr, denn dieses Problem lässt sich beheben.
Warum ihr besser zu dritt kommen solltet
Jemand kehrt aus Hamburg zurück, hat eine Erkenntnis im Gepäck und muss diese nun drei Personen erklären, die die beiden Tage nicht miterlebt haben. Er oder sie erklärt eine Schlussfolgerung, ohne den Weg dorthin zu schildern. Das gelingt selten, und das liegt nicht an der Person.
Drei Mitarbeiter derselben Organisation kommen mit demselben Fall an, diskutieren zwei Tage lang über denselben Wertfluss und fahren mit derselben Maßnahme wieder zurück. Sie müssen einander nichts mehr erklären. Sie sind zu dritt, und drei Personen, die sich einig sind, können in den meisten Unternehmen eine Genehmigungsstufe abschaffen. Eine Person allein kann das nicht.
Dazu kommt noch etwas Praktisches. Der Raum bietet Platz für zwölf Personen, und der Fall, an dem gearbeitet wird, ist der Fall, den jemand mitbringt. Wenn ihr zu dritt kommt, belegt ihr ein Viertel des Raums und arbeitet garantiert zwei Tage lang an eurem eigenen System.
Für Gruppen gibt es einen eigenen Preis. Dieser ist nicht auf der Website angegeben, da er vom Zuschnitt abhängt. Schreibt mir, dann berechnen wir das gemeinsam.
Acht Einwände
1. “Ich kann nicht zwei Tage lang abwesend sein”
Das stimmt vermutlich, und genau das ist das Symptom. Eine Entwicklungsorganisation, in der zwei Tage Ausfallzeit einer einzelnen Person den Ablauf gefährden, verfügt über keine Kapazitätsreserve und damit auch nicht über die Fähigkeit, auf irgendetwas zu reagieren. Rechnet trotzdem einmal nach: Wenn bei euch pro Feature vier Wochen Wartezeit anfallen und ihr davon eine Woche entfernt seid, sind die zwei Tage nach dem ersten Feature bezahlt.
2. “1.650 Euro plus Reisekosten muss ich genehmigen lassen”
Ja. Dabei werdet ihr erfahren, wie lange eine Freigabe bei euch dauert und über wie viele Stufen sie verläuft. Notiert euch das Datum, an dem ihr die Anfrage stellt, und das Datum, an dem ihr eine Antwort erhaltet. Diese Zahl ist Teil der Diagnose, unabhängig davon, 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 spreche mich gegen keines davon aus. Der Punkt ist ein anderer. Nach solchen Einführungen stelle ich regelmäßig fest, dass zwar die Sprache neu ist und die Rollen neue Namen haben, die Anreize jedoch dieselben geblieben sind, die Freigabeprozesse ebenfalls, und sich die Frage, wer entscheiden darf, nicht verschoben hat. Die Struktur wurde umbenannt, das Verhalten nicht. Ein Werkzeug kann man kaufen. Eine Entscheidungsbefugnis muss jemand abgeben. Das Erste ist im Budget vorgesehen, das Zweite hat politische Kosten, also wird das Erste umgesetzt.
Wenn sich eure Durchlaufzeit nach der Einführung verkürzt hat, habt ihr das Problem nicht. Wenn ihr die Zahl nicht kennt, siehe Frage fünf.
4. “Bei uns ist alles geregelt, da geht das nicht”
Die Auflagen sind real und nicht verhandelbar, da gebe ich euch vollkommen recht. Was verhandelbar ist, ist der Weg dorthin.
In fast jeder regulierten Organisation, die ich kennengelernt habe, gibt es zwei Arten von Pflichten. Die erste ist in der Norm festgelegt oder wird vom Prüfer verlangt. Die zweite wurde vor Jahren von jemandem eingeführt, weil einmal etwas schiefgelaufen war, und seitdem hat niemand mehr daran etwas geändert. Die zweite Art ist meist die umfangreichere, und niemand kann sie mehr auseinanderhalten. Der erste sinnvolle Schritt besteht darin, die beiden Listen voneinander 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 rückgängig machen, ein ausgeliefertes Steuergerät hingegen nicht.
Die Prinzipien lassen sich übertragen. Kleine Chargen statt großer. Frühzeitiges Feedback statt erst am Ende. Schnittstellen als Vereinbarungen. Verantwortung dort, wo die Entscheidung getroffen wird. Nichts davon setzt voraus, dass man zurückrollen kann. Alle verkürzen die Zeit zwischen einer Entscheidung und der Erkenntnis, 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 zwar interessant, aber ohne Folgen. Bringt die Person mit, die die Entscheidung trifft, oder zumindest zwei Personen, die gemeinsam Gewicht haben. Wenn das nicht möglich ist, spart euch das Geld und lest stattdessen die sechs Fragen noch einmal.
7. “Ich schicke erst einmal einen Kollegen vorbei, der sich das anschaut.”
Verständlich, und es ist die übliche Vorsichtsmaßnahme. Hier funktioniert sie jedoch schlecht. Ein Kundschafter kehrt 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 kehren mit einer gemeinsamen Diagnose zurück. Wenn das Budget nur für eine Person reicht, schickt die Person, die im Zweifelsfall etwas ändern darf, nicht die, die gerade am wenigsten ausgelastet ist.
8. “Wir sind gerade mitten im Projekt, danach gerne”
Der Zeitpunkt ist tatsächlich ungünstig. Ich will euch das nicht ausreden, und die Aussage, dass es nie einen guten Zeitpunkt gibt, hilft niemandem weiter.
Zwei Dinge dazu, dann entscheidet ihr. Erstens handelt es sich bei dem Fall, an dem ihr in Hamburg arbeitet, genau um dieses Projekt, und die Maßnahme tritt in den nächsten 30 Tagen in Kraft, also noch währenddessen. Zweitens gibt es einen nächsten Durchlauf, und wenn es im September nicht klappt, schreibt mir kurz. Dann melde ich mich, sobald ein Termin feststeht, und muss euch später nicht aus heiterem Himmel anschreiben.
Der eigentliche Stichtag ist der 7. September
Nicht der 21. September. oose sagt Seminare ab, bei denen zwei Wochen vor dem Termin die Mindestteilnehmerzahl von sechs nicht erreicht ist. Das ist die Regel des Veranstalters und keine Verkaufstaktik. Ich schreibe das hier auf, 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 das Gleiche: Wenn ihr zu dritt bucht, ist die Hälfte der Mindestteilnehmerzahl erreicht, und die Frage, ob das Seminar stattfindet, hängt für euch nicht mehr von Fremden ab.
Wenn ihr euch entscheidet,
Zurück zu Frage sechs. Wenn morgen der langsamste Schritt in eurer Entwicklung doppelt so schnell wäre, würde euer Produkt dann früher beim Kunden ankommen?
Wer diese Frage mit „Ja“ beantwortet und die Stelle nennen kann, braucht das Seminar nicht. Fangt einfach an. Wer sie mit „Ja“ beantwortet und die Stelle nicht nennen kann, hat einen Grund, zwei Tage dafür aufzuwenden.
Anmeldung und Details: oose.de/pv
Wenn ihr zu dritt oder in einer größeren Gruppe kommen wollt, schreibt mir bitte vorher. Das ist eine andere Abrechnung, und wir sollten kurz klären, an welchem Fall ihr die zwei Tage arbeitet.
