Organisatorische Schulden

Bild: Flickr/Rachel Doherty - CC BY 2.0

Vor einigen Jahren befand sich meine Firma in Gesprächen mit einem Startup, dem wir ein Testkonzept für seine Software erstellen sollten. Bis zu diesem Zeitpunk hatte es dort nur Unit Tests gegeben, wir hätten dort Integrationstests eingeführt, vielleicht wären auch Lasttests dazugekommen. Hätten, wären. Kurz vor einem wichtigen Termin wurde dieser abgesagt, da das gesamte Entwicklungsteam dieser Firma bei ihrem größten Kunden Hotfixing machen musste. Der Ersatztermin entfiehl aus dem selben Grund, zu einem dritten kam es nicht mehr. Ein Jahr später hörte ich, dass die Situation unverändert gleich war - noch immer bestimmten Hotfixes das Tagesgeschäft. Bei der Gelegenheit wurde mir beiläufig der wahre Grund für das geplatzte Geschäft mitgeteilt - es gab dort einfach niemanden, der sich für das Thema Qualitätssicherung verantwortlich fühlte. Die Entwickler interessierten sich nur für ihre eigenen Komponenten, einen QA- oder Testkoordinator gab es nicht, das Management war mit Auftrags- und Personalbeschaffung ausgelastet. Das hoffnungsvolle Startup erstickte gerade an etwas, dessen Existenz ihm gar nicht bewusst war: Organisatorischer Schuld.

Die organisatorische Schuld ist gewissermassen der unbekannte Zwilling der technischen Schuld. Unter der versteht man den Mehraufwand, den man für Reparaturen und Instandhaltung schlecht geschriebener Software aufbringen muss. Organisatorische Schuld ist dementsprechend der Mehraufwand der sich aus einer unzureichenden Organisationsstruktur ergibt - im oben genannten Fall aus dem Fehlen einer Person die sich für das Thema der übergreifenden Software-Qualität verantwortlich gefühlt hätte. Genau wie im Fall der technischen Schuld erscheint das Ganze zum Zeitpunkt des "Schulden Aufnehmens" auch oft unproblematisch, vielleicht sogar rational. Im Normalfall ist das Schulden aufnehmende Unternehmen noch klein und/oder jung und andere Probleme sind dringender, so dass die Weiterentwicklung der eigenen Strukturen auf "später" verschoben wird. Später sind dann andere Probleme dringender und noch später wieder andere, so dass es niemals zu einer Lösung kommt. Besonders perfide: viele der später auftretenden Probleme wären niemals entstanden wenn die Organisation von Anfang an besser aufgestellt gewesen wäre, ein Beispiel dafür sind die oben genannten Hotfix-Phasen. Letztendlich entsteht ein Teufelskreis - organisatorische Defizite führen zu Mehraufwänden wegen denen die Organisation nicht weiterentwickelt wird, was wieder zu Mehraufwänden führt. Und so weiter.

Was man an dieser Stelle bedenken sollte ist, dass die Existenz organisatorischer Schulden keineswegs notwendigerweise ein Fehler dessen ist, der sie aufgenommen hat. Möglicherweise stehen handfeste Gründe dahinter. Um ein letztes mal das Beispiel des oben genannten Startups anzuführen - vielleicht war am Anfang einfach kein Geld für jemanden mit Test- und QA-Know How da? Der Fehler dürfte eher in mangelnder oder fehlender Agilität liegen: bei funktionierendem Inspect & Adapt wäre zum einen das organisatorische Defizit rechtzeitig aufgefallen, zum anderen wäre auch klar geworden, wann man dieses Problem am besten (oder spätestens) hätte lösen müssen. Nicht, dass es später nicht mehr ginge. Es wird dann nur sehr, sehr teuer.