“Uns fehlen einfach Leute in der Entwicklung!” Diesen Satz hört man nur zu oft in deutschen Softwareunternehmen. Kein Wunder: Die Bundesagentur für Arbeit schätzt Berufe in der Softwareentwicklung als Engpassberufe ein und im Jahr 2021 gab es laut dem Bitkom Verband ca. 96.000 offene Stellen für IT-Fachkräfte in Deutschland, wobei 41% der befragten Unternehmen nach Entwicklerinnen und Softwarearchitekten suchten. Perspektivisch wird sich der Fachkräftemangel infolge des demographischen Wandels eher verschärfen als verbessern. Softwareunternehmen sollten also die Herausforderung akzeptieren, dass sie ihre Ziele trotz dieses Personalmangels erreichen müssen und Wege für den Umgang damit finden.

Dass solche auf Mangel basierenden Herausforderungen auch Fortschritt und Wachstum mit sich bringen können, hat das japanische Unternehmen Toyota Mitte des 20. Jahrhunderts gezeigt. Die damalige Rohstoffknappheit in Japan zwang den Autobauer dazu, sehr sparsam mit allen verfügbaren Ressourcen umzugehen und jede Art von Verschwendung zu vermeiden. Aus diesem Ansatz hat der Produktionsleiter Taiichi Ohno das Toyota Produktionssystem entwickelt, das heute als Inbegriff von effizienter Produktion gilt. 

Was können wir heute als Softwareabteilung vom Toyota Produktionssystem lernen? Wie können wir Softwarehersteller dabei unterstützen, den Personalmangel als Anreiz zur Verbesserung des eigenen Entwicklungsprozesses zu begreifen?

Ein zentrales Konzept des Toyota Produktionssystems ist die Idee der Reduktion von Inventar im Lager. Wenn die Beschaffungsabteilung mehr Rohstoffe einkauft als in naher Zukunft benötigt werden, dann müssen diese eingelagert werden und erzeugen dadurch Lagerkosten. Oder noch schlimmer: Wenn nicht nur Rohstoffe, sondern fertige Autos ohne sicheren Abnehmer auf Vorrat produziert werden, dann besteht das Risiko, dass diese spezifischen Autos mit der spezifischen Konfiguration vergeblich gebaut wurden und nie verkauft werden. Das Toyota Produktionssystem verhindert diese Formen von Verschwendung (große Lagerhaltung und Überproduktion), indem das Inventar möglichst gering gehalten und das Prinzip Just-in-Time angewendet wird, d. h. Materialien nur auf einen Kundenauftrag hin eingekauft und verarbeitet werden.

Aber Moment einmal - Inventar und Lagerkosten in einem komplett digitalen Prozess wie der Softwareentwicklung? Das gibt es doch gar nicht! 

Natürlich kann man die Fließbandproduktion von Autos nicht eins zu eins auf die Softwareentwicklung übertragen, aber das Gedankenmodell kann uns helfen, eine andere Perspektive auf den Prozess der Entwicklung einzunehmen. Inventar könnte hier zum Beispiel ein Ticket in Jira sein, ein offener Merge Request in GitLab oder eine Wikiseite in Confluence. Man muss natürlich keine Lagerkosten pro angelegtem Ticket oder Merge Request bezahlen. Aber je länger ein solches digitales Inventarstück “auf Lager liegt” ohne weiterverarbeitet zu werden, desto mehr potentielle Probleme verursacht es in der Zukunft. Probleme, die unsere knappe Ressource verschwendet, nämlich die Zeit von Entwicklungsteams.

Ein Beispiel: Wenn ein Merge Request eine Woche unbeachtet in GitLab auf eine Review wartet, stehen die Chancen gut, dass in der Zwischenzeit jemand anderes den gleichen Code angefasst hat und Merge Conflicts das Zusammenführen der Arbeit aufwendiger machen. Ebenso eine User Story in Form eines Jira-Tickets, die zum Projektstart schon einmal zur Sicherheit angelegt, jedoch erst neun Monate später bearbeitet wird. Je länger das Ticket herumliegt, desto höher die Wahrscheinlichkeit, dass sich die Kundenanforderungen in der Zwischenzeit ändern und das Ticket nun umgeschrieben werden muss, d. h. doppelt spezifiziert wird. An einigen Stellen wäre es also gut, das Inventar auch in der Softwareentwicklung gemäß des Prinzips Just-in-Time zu reduzieren, um die kostbare Zeit der Entwicklungsteams nicht zu verschwenden.

Warum tendieren wir dazu, Artefakte der Softwareentwicklung als Inventar anzuhäufen? Grund dafür ist ein fundamentales Missverständnis in der täglichen Arbeit: Der Unterschied zwischen Output und Outcome. Output bezieht sich auf das zählbare Ergebnis der Arbeitszeit. Wie viele Zeilen Code habe ich heute hinzugefügt? Wie viele User Stories habe ich in diesem Sprint erstellt? Outcome hingegen beschreibt die Wertschöpfung, die eine Aktivität für die Kundschaft erzeugt. Zum Beispiel wenn das Team am Ende des Sprints erfolgreich das Feature “Bezahlprozess” in einen Webshop eingebaut hat, sodass der Kunde bald Zahlungen erhalten kann. Output ist eine notwendige Bedingung für Outcome, aber keine hinreichende. Wenn das Sprintteam jede Menge Story Points schafft, diese Stories jedoch keinen Wert für den Kunden schaffen, dann ist diese Arbeit nicht wertschöpfend. Output zu erzeugen und Inventar anzuhäufen gibt uns zunächst das Gefühl, etwas geschafft zu haben. Daher kann es sich durchaus befriedigend anfühlen, viele Jira-Tickets am Beginn eines Projekts anzulegen. In unseren bisherigen Projekterfahrungen haben wir bereits einige Softwarehersteller erlebt, die mehrere 10.000 offene Tickets mit sich schleppen. Aber ein starrer Fokus auf Inventar bzw. Output ohne Wertschöpfung führt langfristig zur Verschwendung von wertvollen Arbeitsstunden des Entwicklungsteams und zu Frustration. Statt also das Inventar zu vergrößern, sollten wir versuchen, nur so viel Inventar anzusammeln wie für die Wertschöpfung der nahen Zukunft nötig und hilfreich ist - just in time.

Als ersten Schritt hin zu einer wertschöpfungsorientierten Entwicklung empfehlen wir von DevBoost, sich die Entwicklung wie eine Produktionslinie vorzustellen und den Status Quo zu erheben.

• Was ist unser Entwicklungsinventar? Hierzu geht man durch die eigenen Systeme - Jira, Monday, Confluence, GitLab, BitBucket und so weiter - und erfasst die Art und Anzahl der Artefakte.
• Was sind unsere Arbeitsstationen wie etwa User Stories schreiben, Review oder Deployment? 

Über ein bis zwei Wochen beobachtet man jetzt, wie schnell das Inventar durch die einzelnen Arbeitsstationen fließt und betrachtet das Ergebnis aus zwei Perspektiven.

An welcher Stelle in meiner “Produktionslinie” stapelt sich das Inventar? Warten fertige Features zum Beispiel oft unbearbeitet im Testing oder in der Review? Häufen sich Tickets zu Architekturthemen zunehmend an, während User Stories für Features schnell bearbeitet werden? Werden die produzierten Inventarstücke wie etwa Confluence-Seiten überhaupt “gekauft”, d.h. gelesen? Die Erfassung solcher Daten hilft dabei, das Anhäufen von Inventar an bestimmten Stationen zu erkennen und aufzuhören, mehr Tickets, User Stories und Merge Requests zu produzieren als in der nächsten Station weiterverarbeitet werden können. Das spart Zeit in der Produktion und in der “Lagerung”, die man stattdessen in das aktuell nächste wertschöpfende Feature investieren kann. Hier gilt also das Motto “Reduce production to increase productivity.”

Außerdem macht die Inventarmetapher vorher unsichtbare Nadelöhre sichtbar, welche die Wertschöpfung der gesamten Produktionslinie beschränken. Denn sobald an einer Station nur wenige Inventarstücke mehr weiterfließen, wird die Wertschöpfungskette für die gesamte Produktion verlangsamt. Nadelöhre bestimmen somit die Gesamtgeschwindigkeit der Entwicklung. Die Metapher der Produktionslinie und des Inventars haben wir zum Beispiel in der Vergangenheit mit einem Kundenunternehmen gemeinsam angewendet.

Wir haben in der Vergangenheit mehrfach ein Experiment im Projektkontext durchgeführt, das zugegebenermaßen momentan in Zeiten häufiger remote Tätigkeiten nicht mehr so wirkungsvoll ist. Allerdings veranschaulicht es sehr gut, wie man methodisch die Sichtbarkeit von Produktivität und Inventar verändern kann - und das ist letztlich der Kerngedanke des Experimentes, der auch in der vorrangig digitalen Wert Bestand hat.

Alle Tickets wurden zusätzlich zur digitalen Erfassung auf einen physischen Pappwürfel mit Post-its geklebt, ähnlich wie der Würfel auf dem Bild oben. Wenn eine Kollegin einem Kollegen eine Aufgabe zugewiesen hat, legte sie den entsprechenden Ticketwürfel auf dessen Schreibtisch. Schnell wurde durch die Würfeltürmchen sichtbar, dass sich die Tickets beim Operations Team stapelten, das für allerlei Aufgaben verantwortlich war wie etwa schnelle Hilfe bei Problemen mit dem internen Login, das Anlegen von Accounts oder Unterstützung beim Deployment. Oft haben die Mitarbeitenden also auf Hilfe vom Operations Team gewartet und wurden davon blockiert. Sobald das Problem offensichtlich geworden war, konnten wir gemeinsam nach Lösungen suchen. In diesem Fall konnte dem Operations Team zusätzliches Personal zur Verfügung gestellt werden. Bei einem anderen Kundenunternehmen mit einer ähnlichen “Würfeltürmchenstruktur” hat das Operations Team einen Workshop zum Thema “Selbsthilfe beim Deployment” gehalten, um die Deployment-Würfel besser auf alle Schultern zu verteilen statt sie zum Nadelöhr Team weiterzugeben.

Das Gedankenmodell des Entwicklungsinventars kann Dir also auf zwei Arten helfen. Erstens, versuche das Inventar im Sinne des Just-in-Time Ansatzes zu reduzieren, denn je länger ein Inventarstück unbearbeitet “auf Lager liegt”, desto mehr Zeit muss Dein Entwicklungsteam in dessen Pflege investieren. Zweitens, nutze die Metapher, um Nadelöhre im Entwicklungsalltag aufzuspüren und zu beheben. Wenn Du die Idee gemeinsam mit uns ausprobieren möchtest, erzählen wir Dir gerne mehr dazu in einem Beratungsgespräch.