Warnung
Die beschriebenen Situationen und Beispiele beruhen auf allgemeinen Erfahrungen aus vielen Projekten. Ähnlichkeiten mit realen Personen oder Organisationen sind rein zufällig – oder zeigen höchstens, dass manche Muster in der Softwareentwicklung universeller sind, als uns lieb ist.
Manche Organisationen erinnern mich an diese Szenen in Katastrophenfilmen, wo das Rettungsteam die Luke aufstößt und ruft: „Da ist der Ausgang!“ – und unten sitzen sie, beraten in Flipchart-Kreisen, ob sie zuerst eine Taskforce bilden oder ein neues Tool brauchen. Es ist, als hätten sie sich so sehr an ihr eigenes Elend gewöhnt, dass eine Lösung fast als Beleidigung empfunden wird.
Die Kunst, das Problem zu lieben
Ich habe in über dreißig Jahren Beratung unzählige Projekte gesehen. Start-ups, Behörden, Industriekonzerne – alle mit denselben Ritualen: Zuerst kommt die Selbstgeißelung („Wir sind so chaotisch!“), dann die Toolsuche („Wir brauchen unbedingt das richtige System!“), und zum Schluss der Workshop, in dem man beschließt, beim nächsten Mal strukturierter vorzugehen. Natürlich ohne zu definieren, was strukturierter heißt.
Und wehe, jemand kommt mit einer Lösung, bevor das Jammern abgeschlossen ist. Dann heißt es: „Wie kannst du schon Lösungen bringen, wenn wir noch gar nicht fertig sind, das Problem zu spüren?“
Homöostase der Dysfunktion
Manche Organisationen funktionieren nur, solange sie nicht funktionieren. Ihre Abläufe sind so konstruiert, dass jede echte Verbesserung eine Störung der Balance wäre. Sie haben die erstaunliche Fähigkeit entwickelt, Dysfunktion auf einem konstanten Niveau zu halten.
Das nennt man in der Systemtheorie Homöostase – die Tendenz eines Systems, seinen inneren Zustand aufrechtzuerhalten, selbst wenn es dafür Energie verschwendet oder Chancen vernichtet.
In solchen Organisationen dient jedes Problem als Bestandteil der Stabilität:
- Meetings existieren, um Zeit zu füllen.
- Prozesse dienen dem Nachweis, dass es sie gibt.
- Audits bestätigen, dass das Chaos strukturiert ist.
Und wehe, jemand schlägt etwas vor, das wirklich funktionieren könnte. Dann gerät das System in Panik – denn plötzlich müsste man sich neu organisieren, Verantwortung übernehmen, oder – Gott bewahre – Erfolg haben.
Dysfunktionale Homöostase ist bequem. Sie erlaubt es, alles beim Alten zu lassen und sich gleichzeitig mit dem Gefühl moralischer Anstrengung zu umgeben. Alle „arbeiten hart“, aber niemand verändert etwas.
Das Märchen vom rettenden Tool
Das Tool ist die Lieblingsausrede aller dysfunktionalen Organisationen. Wenn man nur das richtige Werkzeug hätte, dann … ja, dann wäre alles anders. Dann würden Projekte pünktlich fertig, Anforderungen eindeutig formuliert und Deployments sauber dokumentiert. Man glaubt ernsthaft, man könne Kultur installieren.
Wer glaubt, ein neues Tool löst seine organisatorischen Probleme, glaubt auch, dass eine neue Bohrmaschine das Haus repariert.
Ein Tool ist aber kein Organisationsersatz. Ein Tool verzeiht nichts, es spiegelt nur schonungslos, was da ist. Wenn du Chaos digitalisierst, hast du danach digitales Chaos.
Ich habe noch nie erlebt, dass Jira, Confluence, ServiceNow oder irgendein anderes System eine Firma reifer gemacht hätte. Was sie tun: Sie zeigen den Reifegrad – ungeschönt. Und das ist der Moment, in dem viele lieber den Boten erschießen.
Reifegrade und Realität
Das Capability Maturity Model (CMM) ist so etwas wie ein Seismograph für organisatorische Erdplattenverschiebungen. Es misst nicht, wie modern eine Firma ist, sondern wie konsistent sie arbeitet. Von „Wir schaffen’s, wenn Karl nicht im Urlaub ist“ bis „Wir verbessern uns selbst, weil’s uns Spaß macht“ ist ein weiter Weg.
Das Capability Maturity Model (CMM) beschreibt, wie reif und beherrscht die Prozesse einer Organisation sind. Es wurde am Software Engineering Institute der Carnegie Mellon University entwickelt und dient weltweit als Referenzrahmen für Prozessverbesserung in der Software- und Systementwicklung.
Level 1 – Initial Ad-hoc-Prozesse, stark personenabhängig. Erfolg hängt vom Engagement einzelner ab, nicht von der Organisation. Beispiel: Start-ups in der frühen Wachstumsphase, die schnell liefern, aber kaum dokumentieren.
Level 2 – Repeatable Wiederholbare Abläufe entstehen, Projekte werden planbarer. Beispiel: Mittelständische IT-Dienstleister mit definierten Projekt-Templates und Review-Zyklen.
Level 3 – Defined Prozesse sind dokumentiert, verstanden und standardisiert. Beispiel: Großunternehmen mit zentralen Prozesshandbüchern und verbindlichen Entwicklungsrichtlinien (z. B. Siemens, IBM im internen Software-Engineering).
Level 4 – Managed Prozesse werden aktiv gemessen und quantitativ gesteuert. Beispiel: Automotive-Unternehmen oder Luft- und Raumfahrt (Boeing, Airbus), wo Metriken für Qualität, Zuverlässigkeit und Risiko in jedem Schritt erhoben werden.
Level 5 – Optimizing Kontinuierliche Verbesserung ist institutionalisiert. Organisationen lernen aus Daten, Feedback und Experimenten. Typische Vertreter:
- Google nutzt „blameless post-mortems“, datengetriebenes Engineering und A/B-Testing, um Prozesse ständig zu verfeinern.
- Netflix lebt eine Kultur des Experimentierens („Chaos Engineering“) – Fehler werden analysiert, nicht sanktioniert.
- Toyota ist das Industrie-Vorbild mit „Kaizen“ – kontinuierlicher Prozessverbesserung und Lernschleifen über alle Ebenen hinweg.
Auf Level 5 ist Prozessverbesserung Teil der DNA: Jede Abweichung wird als Chance begriffen, besser zu werden.
Der Reifegrad des Selbstmitleids
Die Opferrolle ist verführerisch. Sie hat den Charme des Ausredenmanagements:
- „Wir würden ja gern, aber die Umstände …“
- „Wir sind halt speziell …“
- „Bei uns geht das nicht …“
Das Schöne daran: Man kann sich gleichzeitig als Opfer und als Held inszenieren. Held, weil man „trotz allem“ kämpft. Opfer, weil man nie gewinnen kann. Das gibt Sinn. Und Sinn ist gefährlich – er kann jede Dysfunktion überleben.
Wie man Potenziale sichtbar macht
Wer verstehen will, wo eine Organisation steht, braucht mehr als Bauchgefühl und Meeting-Protokolle. Man braucht eine Datenbasis, die zeigt, wo die Engpässe liegen und welche Stellhebel tatsächlich Wirkung haben. Das beginnt mit der richtigen Fragestellung:
- Wie schaffen wir Vergleichbarkeit, ohne zu bewerten?
- Wie messen wir, ob Veränderungen etwas verbessern oder nur Bewegung simulieren?
Tipp
Teste den Reifegrad Deiner Organisations selber mit meinem Online-Assessment!
Mit modernen Werkzeugen – etwa dynamischen Reports und interaktiven Dashboards (z. B. mit Marimo) – lässt sich das erstaunlich gut abbilden. Ich verwende multivariate Statistik (neudeutsch: Data Science), um Muster zu erkennen, Teams zu clustern und systematische Unterschiede sichtbar zu machen. Das ist die Grundlage dafür, gezielt zu verbessern.
Aus solchen Daten entstehen Landkarten:
- Wo sind die Prozesse stabil, wo bricht Kommunikation ab,
- wo entstehen Verzögerungen, wo passiert echte Wertschöpfung?
Auf dieser Basis lassen sich Systeme wie eine übergreifende CI/CD-Architektur planen – nicht als Selbstzweck, sondern als Mittel, um Arbeit zu entlasten, Fehler messbar zu machen und Verbesserungen als Feedbackschleifen zu verstehen statt als Kritik.
Kurz gesagt: Man kann die Potenziale einer Organisation berechnen, wenn man sie richtig misst. Und wer messen kann, kann gezielt steuern – nicht durch Bauchgefühl, sondern durch Evidenz. Leider verwechseln viele Organisationen Messbarkeit mit Bedrohung. Sie wollen Fortschritt, ohne gesehen zu werden. Das funktioniert ungefähr so gut, wie ein Fitnessprogramm ohne Waage und ohne Trainingsplan.
Fazit
Wer die Opferrolle liebt, hat immer recht. Und wer sie verlässt, hat plötzlich Arbeit. Oder, frei nach CMM: Erfolg ist kein Zufall, sondern das Nebenprodukt einer wiederholbaren Entscheidung.
Quellen und Links
CMMI: Verbesserung von Software- und Systementwicklungsprozessen mit Capability Maturity Model Integration von Ralf Kneuper
Gefangen in der Opferrolle von Varnan Chandreswaran zeigt, wie der psychologische Mechanismus der Opferrolle funktioniert, allerdings bezogen auf soziale Themen.
Kommentare