DevOps-Kultur
im Unternehmen
etablieren.
Tools und Pipelines sind die leichte Hälfte von DevOps. Die schwere Hälfte ist die Kultur: wie ein Team mit Fehlern umgeht, ob jemand ohne Angst widerspricht und ob IT und OT dieselbe Anlage als gemeinsame Aufgabe sehen.
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
DevOps, CI/CD und Industrial Automation seit 2006.
AIKultur ist
wichtiger als
jedes Tool.
Eine DevOps-Kultur etablieren Sie im Unternehmen, indem IT- und OT-Teams gemeinsame Ziele, gemeinsame Retrospektiven, psychologische Sicherheit und eine positive, blameless Fehlerkultur entwickeln, nicht durch das Installieren weiterer Tools. Das CALMS-Framework gibt den Rahmen vor. Entscheidend ist, dass die Teams es im Alltag anwenden, am besten schrittweise über ein geschütztes Pilotteam.
Stand: 29. September 2026 · CALMS · DORA 2025 · Project Aristotle · Conway 1968
Die meisten DevOps-Transformationen scheitern nicht an der Technik. Jenkins lässt sich installieren, eine Pipeline ist in ein paar Tagen gebaut. Vertrauen lässt sich nicht installieren. Oft läuft die Pipeline längst, und ein Teil des Teams baut trotzdem weiter auf dem eigenen Rechner.
In der Industrie verschärft sich das. Der IT-Engineer hat gelernt, dass ein schneller Rollback fast jeden Fehler heilt. Für den OT-Engineer ist jede ungeplante Änderung an einer laufenden Anlage ein Sicherheitsrisiko, im schlimmsten Fall für die Menschen an der Maschine. Beide haben recht. Die typischen Konfliktmuster beschreiben wir ausführlich im Artikel IT vs. OT: Warum Kultur entscheidet.
Ist Fehlerkultur bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Was ist
DevOps-Kultur?
DevOps-Kultur, englisch DevOps Culture, ist die Arbeitsweise, in der Entwicklung und Betrieb ein Produkt gemeinsam verantworten, statt es über eine Abteilungsgrenze hinweg zu übergeben. Sie ruht auf vier Elementen: gemeinsame Ziele, geteilte Verantwortung für den laufenden Betrieb, psychologische Sicherheit und eine Fehlerkultur ohne Schuldzuweisung. Das CALMS-Framework mit Culture, Automation, Lean, Measurement und Sharing beschreibt ihre fünf Säulen. In der Industrie gehört die OT-Seite mit SPS-Programmierung und Anlagenbetrieb ausdrücklich dazu.
Wie groß der Unterschied ist, sehen wir an Werken mit identischer Jenkins-Installation, die völlig unterschiedlich ausliefern. Im einen ist ein fehlgeschlagener Build eine Information, im anderen eine Schuldfrage. Zwei Begriffe tragen diesen Unterschied, deshalb klären wir sie gleich hier.
Was ist Fehlerkultur?
Fehlerkultur beschreibt, wie eine Organisation mit Fehlern umgeht: als Schuldfrage oder als Lernchance. Eine positive Fehlerkultur trennt Person und Problem. Sie sucht die Ursache im System statt einen Schuldigen und macht Fehler so zur besten Datenquelle für Verbesserung.
Was ist psychologische Sicherheit?
Psychologische Sicherheit ist die geteilte Überzeugung im Team, dass niemand bloßgestellt oder bestraft wird, wenn er einen Fehler zugibt, eine Frage stellt oder widerspricht. Der Begriff geht auf Amy Edmondson (Harvard) zurück. Googles Studie Project Aristotle fand sie unter fünf Faktoren als den mit Abstand wichtigsten für effektive Teams.
Wie etabliert
man eine
DevOps-Kultur
im Unternehmen?
Eine DevOps-Kultur etabliert man nicht per Anordnung, sondern schrittweise über ein geschütztes, cross-funktionales Pilotteam aus IT und OT. Bewährt hat sich ein Weg in sechs Schritten, vom ehrlichen Ist-Zustand bis zur Routine im ganzen Werk. Keiner davon braucht ein neues Tool, alle sechs brauchen Konsequenz.
- /01
Ist-Zustand einordnen
Wo steht Ihre Kultur heute: Ad-hoc, Managed oder schon Defined? Eine ehrliche Standortbestimmung verhindert unrealistische Ziele. Der kostenlose Reifegrad-Check liefert in 3 Minuten einen Startpunkt.
Mehr dazu in Abschnitt 05 - /02
Pilotteam bilden
Ein cross-funktionales Team aus Software-, Plattform- und SPS-Engineers mit gemeinsamem Backlog, gemeinsamem Daily und einer Definition of Done, die für Steuerungs- und Applikationscode gleich gilt. Kein neues DevOps-Silo daneben.
Mehr dazu in Abschnitt 06 - /03
Spielregeln für Fehler vereinbaren
Bevor das erste Jenkinsfile entsteht, klärt das Team, wie es mit Fehlern umgeht. Wer einen Fehler offen anspricht, wird nicht bloßgestellt. Ohne diese Regel bleibt jeder weitere Schritt Fassade.
Mehr dazu in Abschnitt 08 - /04
Blameless Post-Mortems einführen
Nach jedem nennenswerten Vorfall ein dokumentiertes Post-Mortem mit Timeline, Systemursache und Maßnahme, geteilt im ganzen Werk. Die Leitfrage lautet „Warum war der Fehler möglich?“, nicht „Wer war es?“.
Mehr dazu in Abschnitt 08 - /05
Erfolge messbar machen
Die DORA-Metriken neben die OEE der Anlage legen und kleine Erfolge mit Zahl erzählen, etwa „Freigabe in zwei Stunden statt drei Tagen“. Sichtbarer Erfolg zieht Mitstreiter an.
Mehr dazu in Abschnitt 04 - /06
Skalieren
Das erprobte Muster Bereich für Bereich übertragen, nicht per Stichtag für das ganze Werk. Die Führung schafft dafür den Rahmen.
Mehr dazu in Abschnitt 10
Wie lange
dauert ein
Kulturwandel?
Rechnen Sie in Monaten, nicht in Wochen. Vom ehrlichen Ist-Zustand auf der Stufe Ad-hoc bis zu standardisierten, cross-funktionalen Routinen auf der Stufe Defined vergehen in unseren Industrieprojekten typischerweise 12 bis 18 Monate. Ein einzelnes, geschütztes Pilotteam zeigt erste belastbare Ergebnisse aber oft schon nach einem Quartal.
Wann es kippt, lässt sich selten im Voraus terminieren, aber gut erkennen: beim ersten Post-Mortem, in dem jemand freiwillig einen eigenen Fehler auf den Tisch legt, statt ihn zu verwalten. Ab da trägt sich die Routine selbst. Wer Rückschläge einplant, kommt schneller ans Ziel als ein Team, dem der Wandel per Stichtag verordnet wurde.
Quellen: Google re:Work, Project Aristotle (Teams mit starker Teamkultur) · DORA Metrics Guide · Comquent-Projekterfahrung
Eine generative KulturDORA · Capability Generative Organizational Culture · aus dem Englischen übersetzt
mit hohem Vertrauen sagt
Delivery-Performance voraus.
DORA meint damit Software-Delivery- und Organisationsleistung zugleich. Derselbe Forschungsstrang fand 2019, dass eine Kultur psychologischer Sicherheit beides vorhersagt, dazu die Produktivität. Über ein einzelnes Tool hat DORA eine solche Aussage nie getroffen.
Was sind die fünf
Säulen der
DevOps-Kultur?
Die fünf Säulen der DevOps-Kultur sind das CALMS-Framework: Culture, Automation, Lean, Measurement und Sharing. John Willis und Damon Edwards prägten 2010 das Kürzel CAMS, Jez Humble ergänzte später das L für Lean. In der Industrie bekommt jede Säule eine eigene Ausprägung, die wir unter jedem Punkt zeigen.
- /C
Culture
Zusammenarbeit und Vertrauen
Entwicklung, Betrieb und Automatisierung verantworten ein Ergebnis gemeinsam. Sichtbar wird das an Kleinigkeiten: ein gemeinsames Backlog, eine gemeinsame Retrospektive, und im Meeting sagt niemand mehr „die von der IT“.
In der IndustrieIm Maschinenbau sitzen Softwareentwickler und SPS-Programmierer im selben Team statt in zwei Gebäuden. Wer an einer Anlage einen Fehler zugibt, wird dafür geschützt. In vielen Werken ist genau das bis heute ein Karriererisiko.
- /A
Automation
Routine an die Pipeline abgeben
Automatisiert wird, was sich wiederholt und Fehler anzieht: Build, Test, Auslieferung, Nachweise. Die frei werdende Zeit geht in Engineering statt in Deployments per Copy-and-paste.
In der IndustrieSicherheits- und Compliance-Anforderungen aus IEC 62443 oder der Maschinenrichtlinie werden zu automatischen Prüfschritten in der Pipeline, statt am Ende als manuelle Bremse zu warten. Ab 20. Januar 2027 gilt die neue EU-Maschinenverordnung, und der Nachweisbedarf wächst eher, als dass er schrumpft.
- /L
Lean
Kleine Schritte, kurzer Fluss
Kleine, umkehrbare Änderungen statt großer Umbauten. Wartezeiten und Übergaben in der Lieferkette werden sichtbar gemacht und abgebaut.
In der IndustrieMaschinenbauer kennen das als Kaizen und Wertstromanalyse. Im Werk überzeugt DevOps deshalb am ehesten, wenn es nicht als IT-Trend auftritt, sondern als dieselbe Methode, angewandt auf die Kette vom Commit bis zur Anlage.
- /M
Measurement
Zahlen statt Bauchgefühl
Gemessen wird der Fluss, nicht die Auslastung. DORA nennt dafür heute fünf Kennzahlen: Deployment Frequency, Change Lead Time, Change Fail Rate, Failed Deployment Recovery Time und seit 2024 die Deployment Rework Rate.
In der IndustrieNeben die DORA-Kennzahlen gehört die OEE (Overall Equipment Effectiveness) der Anlage. Erst beide auf einem Dashboard zeigen, ob schnellere Auslieferung die Linie ruhiger macht oder nervöser.
- /S
Sharing
Wissen teilen statt horten
Wissen ist kein Machtfaktor. Tech Talks, Pair Programming, Code Reviews über Teamgrenzen und offene Post-Mortems verteilen es auf mehrere Köpfe.
In der IndustrieDer erfahrene SPS-Programmierer zeigt dem Plattform-Engineer, warum ein Baustein so parametriert ist, und lernt im Gegenzug Git und Pipeline. Wie viel Wissen noch an einer einzigen Person hängt, misst der Bus-Faktor in Abschnitt 07.
Wo steht
die Kultur in
Ihrem Team?
Kulturwandel ist kein Schalter. Zwei Blickwinkel helfen bei der Einordnung. Die Westrum-Typologie fragt, wie Information in der Organisation fließt. Die fünf Reifestufen darunter fragen, welche Praktiken schon Routine sind.
Beides hängt zusammen. Solange Information zurückgehalten wird, bleibt in unseren Projekten jede Praktik auf Stufe 2 stecken: Das Git-Repository existiert, aber niemand traut sich, darin einen Fehler sichtbar zu machen.
Ron Westrum ist Soziologe und hat Sicherheitskulturen in Luftfahrt und Medizin untersucht. DORA misst seine drei Typen mit sechs Aussagen, denen Teammitglieder auf einer Skala von 1 bis 7 zustimmen oder nicht, zum Beispiel „Überbringer schlechter Nachrichten werden nicht bestraft“ oder „Fehler werden vor allem als Gelegenheit gesehen, das System zu verbessern“.
- Keine Versionskontrolle für SPS-Code
- Deployments nur durch bestimmte Personen
- „Das haben wir schon immer so gemacht“
- Git für Steuerungscode eingeführt
- Regelmäßige Abstimmung zwischen IT und OT
- Erste Build-Automatisierung
- CI/CD für Steuerungscode produktiv
- Gemeinsame Retrospektiven von IT und OT
- Blameless Post-Mortems etabliert
- DORA-Metriken werden erhoben
- Verbesserungen starten als Experiment mit Messpunkt
- Wissensaustausch hat feste Termine
- Teams treiben Verbesserungen ohne Auftrag
- Feste Zeit für Innovation (etwa 20 %)
- Niemand spricht mehr von „DevOps-Einführung“
Was der DORA-Report 2025 an der Einordnung ändert
Im Report State of AI-assisted Software Development 2025 hat DORA die gewohnte Einteilung in Elite-, High-, Medium- und Low-Performer durch sieben Teamprofile ersetzt. Sie bilden neben Tempo und Stabilität auch Reibung, Belastung und Burnout ab. Ein Team kann stabil und langsam sein, ohne deshalb auf der untersten Stufe zu stehen.
Die wichtigste Aussage des Reports betrifft die Kultur direkter als jede Kennzahl: KI wirkt als Verstärker. Sie vergrößert die Stärken einer Organisation und genauso ihre Schwächen. Ein Team, das Fehler meldet und in kleinen Schritten ausliefert, wird mit KI-Assistenz schneller. Ein Team, das Fehler verschweigt, produziert mit KI mehr davon, und zwar im höheren Tempo. Wer KI in Pipeline und Code-Review holen will, sollte deshalb vorher wissen, auf welcher Stufe seine Kultur steht.
Die fünf Stufen oben beschreiben, wie im Team über Fehler gesprochen wird. Die Teamprofile beschreiben, was am Ende der Pipeline herauskommt. Beides gehört nebeneinander, sonst verbessert man Kennzahlen an einer Kultur vorbei, die den Fortschritt nicht trägt. Wie Sie den Ist-Zustand systematisch erheben, zeigt DevOps-Reifegrad messen.
Woran scheitert
ein DevOps-Kulturwandel?
Meist daran, dass ein Unternehmen Kultur wie ein Tool-Projekt behandelt: installieren, anordnen, abhaken. Fünf Muster sehen wir immer wieder, und für jedes gibt es einen besseren Weg.
- /01
„DevOps ist ein Tool-Problem“
SymptomJenkins ist installiert, Prozesse und Zusammenarbeit sind unverändert. Die Pipeline existiert, aber niemand vertraut ihr.
BesserMit Prozess und Zusammenarbeit anfangen. Die Tool-Entscheidung folgt daraus, nicht umgekehrt.
- /02
„Wir haben jetzt ein DevOps-Team“
SymptomEine neue Abteilung namens DevOps entsteht und wird zum dritten Silo zwischen Entwicklung und Betrieb.
BesserDevOps ist eine Arbeitsweise, keine Abteilung. Die Fähigkeiten gehören in die bestehenden Teams.
- /03
„Die OT-Seite macht nicht mit“
SymptomDie IT treibt das Thema, die OT fühlt sich übergangen. Der Widerstand wächst, weil niemand Anlagenrisiken und Wartungsfenster ernst nimmt.
BesserOT-Leute von Anfang an ins Pilotteam holen und mit einem Ergebnis starten, das ihnen sofort hilft, etwa einem nachvollziehbaren Steuerungsstand je Maschine.
- /04
„Das Management hat es angeordnet“
SymptomEine Verordnung ohne Begründung. Teams halten Rituale ab, deren Sinn ihnen niemand erklärt hat.
BesserFührung erklärt das Warum, lebt es selbst vor und schafft Freiraum. Was das konkret heißt, steht in Abschnitt 10.
- /05
„Automatisierung ersetzt Menschen“
SymptomAngst um den Arbeitsplatz blockiert jede Veränderung. Automatisierungsprojekte versanden leise.
BesserOffen sagen, was wegfällt und was bleibt: Die Routine fällt weg, die Menschen bleiben und bekommen Zeit für Engineering. Und sich dann auch daran halten.
Warum entsteht
Silodenken?
Silodenken entsteht, wenn Abteilungen an gegensätzlichen Zielen gemessen werden und nur noch über Tickets miteinander sprechen. Die Entwicklung wird an ausgelieferten Features gemessen, der Betrieb an Verfügbarkeit. Beide Ziele sind für sich genommen richtig, und beide belohnen genau das Verhalten, das der anderen Seite schadet.
Böswillig handelt dabei niemand. Der Entwickler, der freitags noch deployen will, hat seinen Sprint im Nacken. Der Anlagenverantwortliche, der das blockiert, hat am Wochenende Rufbereitschaft. Beide tun genau das, wofür sie bezahlt werden. Das Silo haben die Zielsysteme gebaut.
AIWas besagt Conway’s Law?
Conway’s Law besagt, dass Organisationen Systeme entwerfen, die ihre eigene Kommunikationsstruktur abbilden. Melvin Conway formulierte den Satz 1968 in dem Aufsatz „How Do Committees Invent?“. Auf Deutsch wird er als Gesetz von Conway zitiert. Praktisch heißt das: Vier Teams, die kaum miteinander reden, bauen eine Software mit vier Schnittstellen, an denen es klemmt.
In der Industrie sieht man das besonders deutlich. Das SPS-Team pflegt seinen Steuerungscode, das HMI-Team seine Visualisierung, das Cloud-Team seine Auswertung. Drei Teams, drei Repositories, drei Release-Rhythmen. Zum ersten Mal kommen die drei Stände bei der Inbetriebnahme beim Kunden zusammen, und dort zeigt sich, dass die Schnittstelle anders gemeint war als gebaut.
Nützlich wird das Gesetz erst im Umkehrschluss. Wenn die Architektur dem Organigramm folgt, ist der Umbau des Organigramms ein Architekturwerkzeug. Genau das meint der Begriff Inverse Conway Maneuver: erst die Teams so schneiden, wie das System aussehen soll, dann das System bauen. An dieser Stelle hört Kulturarbeit auf, weich zu sein, und bekommt technische Folgen.
Woran erkennt man den Silo-Effekt?
Der Silo-Effekt beschreibt, was passiert, wenn Abteilungen ihr Wissen und ihre Ziele gegeneinander abschotten. Er kündigt sich lange an, bevor ihn jemand beim Namen nennt. Diese fünf Symptome sind unsere Prüfliste in der ersten Woche eines Projekts, und Sie können sie diese Woche selbst prüfen.
- /01
Die Übergabe läuft über ein Ticket
Entwicklung und Betrieb sprechen nicht mehr miteinander, sondern schreiben sich. Wer den Status wissen will, liest ein Feld, statt eine Frage zu stellen.
- /02
Jede Abteilung hat ihre eigene Wahrheit
Die IT misst Deployment Frequency, die Produktion misst OEE, die Qualitätssicherung zählt Abweichungen. Drei Dashboards, drei Zahlen, kein gemeinsames Bild der Lage.
- /03
Namen werden durch „die“ ersetzt
Sobald im Meeting „die von der IT“ oder „die aus der Fertigung“ fällt, ist die Grenze bereits gezogen. Menschen, die zusammenarbeiten, nennen einander beim Namen.
- /04
Eskalation ist der normale Weg
Zwei Teams klären eine technische Frage nicht untereinander, sondern über zwei Vorgesetzte. Das kostet Tage und trainiert beide Seiten darauf, es beim nächsten Mal wieder so zu machen.
- /05
Niemand kennt die Zahlen der anderen
Fragen Sie einen Entwickler, was eine Stunde Stillstand an Linie 3 kostet. Fragen Sie den Schichtleiter, wie lange ein Rollback dauert. Wenn beide raten, ist das Silo vollständig.
Silodenken aufbrechen heißt in der Praxis selten, Abteilungen aufzulösen. Es heißt, beiden Seiten eine gemeinsame Zahl zu geben, für die sie zusammen geradestehen, und einen Ort, an dem sie sich sehen. Bei uns ist das meistens die gemeinsame Retrospektive nach einem Vorfall, dazu eine Kennzahl, die beide Seiten gleichzeitig gut oder schlecht aussehen lässt. Wie wir das moderieren, steht in unserem DevOps Coaching.
Was ist der
Bus-Faktor?
Der Bus-Faktor ist die Anzahl der Menschen in einem Team, die gleichzeitig ausfallen müssten, damit die Arbeit stehen bleibt. Bus-Faktor 1 heißt, dass eine einzige Person unersetzlich ist. Im englischen Sprachraum heißt dieselbe Kennzahl Truck Number oder Bus Factor, gemeint ist immer dasselbe Risiko: Wissen, das nur in einem Kopf existiert.
Der Name ist makaber gemeint, das Risiko ist es nicht. Bei der Bestandsaufnahme fragen wir deshalb zuerst, wer weiß, welcher Steuerungsstand auf welcher Maschine läuft, warum das Skript um 22 Uhr laufen muss und was passiert, wenn es das nicht tut. Meist fällt bei allen drei Fragen derselbe Name. Wir haben Werke erlebt, in denen nach einem einzigen Renteneintritt niemand mehr sagen konnte, warum ein Baustein so parametriert ist, wie er ist.
Eine Person trägt die Anlage
Ein Kollege kennt den Steuerungsstand jeder Maschine, den Nachtbuild und die undokumentierte Ausnahme an Linie 2. Urlaub ist ein Risiko, Rente ein Projektstopp.
Zwei wissen es, keiner schreibt es auf
Das Wissen ist verdoppelt, aber immer noch mündlich. Es überlebt einen Urlaub und keinen Wechsel. Ein typisches Zwischenstadium nach dem ersten Schreckmoment, das sich gern als Lösung ausgibt.
Das System erklärt sich selbst
Die Konfiguration liegt versioniert im Repository, der Build läuft als Pipeline, Freigaben sind Commits. Neue Kollegen lesen die Historie, statt jemanden zu fragen. Ab hier ist Wissen kein Personalrisiko mehr.
AIDen Bus-Faktor hebt man nicht mit einem Wiki-Artikel. Man hebt ihn, indem die Arbeit selbst das Wissen sichtbar macht: Steuerungscode im Repository statt auf dem Netzlaufwerk, der Nachtbuild als Pipeline statt als Skript auf einem Rechner unter dem Schreibtisch, die Freigabe als Commit statt als Zuruf. Kulturarbeit und Technik lösen hier dasselbe Problem von zwei Seiten. Wer diese Arbeit nicht dauerhaft selbst leisten will, findet in Automation as a Service die Variante, in der ein Team die Strecke betreibt.
Wie entsteht
psychologische
Sicherheit
im Team?
Psychologische Sicherheit entsteht durch wiederholte Erfahrung, nicht durch Ankündigung. Jemand meldet einen Fehler, und es passiert ihm nichts, außer dass das Team das System verbessert. Das wirksamste Ritual dafür ist das Blameless Post-Mortem.
Amy Edmondson definiert psychologische Sicherheit als „die geteilte Überzeugung, dass das Team sicher ist für zwischenmenschliche Risikobereitschaft“. Im Alltag heißt das: Kann ich einen Fehler zugeben, ohne bestraft zu werden?
In der OT wiegt die Frage schwerer, weil ein Fehler an einer Anlage Menschen verletzen kann. Viele Organisationen reagieren darauf mit strenger Kontrolle und Strafe. Das Ergebnis ist das Gegenteil des Gewollten: Fehler werden vertuscht statt gemeldet, und der nächste Beinahe-Unfall kommt ohne Vorwarnung. Wie IT-Unternehmen diesen Wandel angehen, zeigt unser Anwendungsfall IT-Unternehmen.
Die Matrix erklärt, warum psychologische Sicherheit nichts mit Kuschelkurs zu tun hat. Sicherheit ohne Anspruch ergibt die Komfort-Zone, Anspruch ohne Sicherheit die Angst-Zone. Ein Pilotteam soll in der Lern-Zone arbeiten: klare Ziele, hohe Qualitätsansprüche, und trotzdem darf jeder sagen, wenn etwas schiefgeht.
Wie läuft ein Blameless Post-Mortem ab?
In fünf Schritten, und der dritte ist der entscheidende. Google beschreibt die Praxis im SRE-Buch, Kapitel 15, wir haben sie für Anlagenstillstände und fehlgeschlagene Deployments gleichermaßen übernommen.
- /01
Fakten sammeln: Was ist passiert? Eine Timeline ohne Interpretation.
- /02
System analysieren: Welche Faktoren haben den Vorfall möglich gemacht? Prozesse, Werkzeuge, Kommunikation.
- /03
Menschen schützen: Die Frage lautet „Warum war der Fehler möglich?“, nicht „Wer hat den Fehler gemacht?“.
- /04
Maßnahmen ableiten: Was ändern wir am System, damit derselbe Fehler nicht wieder passieren kann?
- /05
Teilen: Das Team veröffentlicht das Post-Mortem, damit andere Bereiche daraus lernen, bevor ihnen dasselbe passiert.
AINach unserer Erfahrung ist das Blameless Post-Mortem die wirksamste Einzelmaßnahme für psychologische Sicherheit, weil es jedes Mal zeigt, dass Ursachen gesucht werden und keine Schuldigen. In regulierten Umgebungen zahlt es sich doppelt aus. Dieselbe Offenheit, die ein Team lernfähig macht, erzeugt die lückenlose Änderungs- und Freigabespur, die ein Audit nach IEC 62443 verlangt. Kommt nach einem Vorfall die Frage „Wer hat das wann freigegeben?“, dauert die Antwort dann einen Vormittag statt Wochen.
Welche Best
Practices tragen
die Kultur
im Alltag?
Kultur entsteht aus Gewohnheiten, nicht aus Absichten. Diese neun Praktiken haben sich in unseren Industrial-DevOps-Projekten bewährt, sortiert nach ihrem Rhythmus. Keine davon braucht ein neues Tool, nur einen festen Termin im Kalender.
Täglich
- Gemeinsames Standup
IT- und OT-Leute im selben Daily. 15 Minuten, dieselben Prioritäten.
- Pair Programming / Pair Commissioning
Ein Softwareentwickler und ein SPS-Programmierer lösen eine Aufgabe gemeinsam am selben Bildschirm oder an derselben Anlage.
- Shared On-Call
Gemeinsame Rufbereitschaft. Es gibt kein IT-Problem und kein OT-Problem, nur ein gemeinsames.
Wöchentlich
- Tech Talk am Freitag
30 Minuten, ein Teammitglied stellt ein Thema vor, abwechselnd aus IT und OT: OPC UA, Kubernetes, PROFINET, GitOps.
- Code Review über Teamgrenzen
OT-Engineers prüfen IT-Code auf Praxistauglichkeit, IT-Engineers prüfen SPS-Code auf Struktur und Testbarkeit.
- Failure Friday
Zehn Minuten über die Fehler der Woche: was schiefging und was wir daraufhin ändern. Ohne Schuldfrage.
Monatlich
- Retrospektive
Was lief gut, was nicht? Konkrete Maßnahmen mit Namen und Termin, und beim nächsten Mal wird nachgefragt.
- Gemba Walk
Die IT geht in die Produktion, die OT in die Entwicklungsabteilung. Wer den Arbeitsplatz des anderen gesehen hat, schreibt andere Tickets.
- Metriken-Review
DORA-Metriken und OEE gemeinsam ansehen, Zusammenhänge suchen, die nächste Verbesserung planen.
AIWo Ihr Team heute steht, ordnet unser kostenloser Reifegrad-Check ein. Bei der Umsetzung begleitet unser DevOps-Coaching.
Welche Rolle
spielt die
Führung?
Die Führung entscheidet nicht alles, aber sie setzt den Rahmen, in dem Kultur wächst oder erstickt. Fünf Prinzipien machen den Unterschied. Externe DevOps-Beratung kann diesen Rahmen moderieren, etwa über begleitetes Coaching für Führungskräfte.
- /01
Vorleben, nicht anordnen
Kultur wird kopiert, nicht verordnet.
Führungskräfte nutzen die Werkzeuge selbst, sitzen in Retrospektiven und benennen eigene Fehlentscheidungen. Wer als Führungskraft nie einen Fehler zugibt, bekommt ein Team, das keine meldet.
- /02
Schutzraum schaffen
Luft für das Pilotteam.
Weniger Berichtspflicht, weniger Statusrunden, dafür ein klares Ziel. Neue Arbeitsweisen probiert niemand aus, der für jeden Fehlversuch einen Bericht schreiben muss.
- /03
Erfolge sichtbar machen
Mit Zahl, nicht mit Adjektiv.
Kleine Erfolge im Werksmeeting erzählen, mit der Zahl und dem Namen des Teams, das sie erreicht hat. Die Zahl liefert die Pipeline, der Name sorgt dafür, dass das nächste Team mitmachen will.
- /04
Widerstände ernst nehmen
Widerstand ist ein Signal.
Hinter „Das funktioniert bei uns nicht“ steckt oft eine berechtigte Sorge: ein Wartungsfenster, eine Haftungsfrage, eine schlechte Erfahrung mit dem letzten Projekt. Wer zuhört, erfährt von den Stolpersteinen, bevor er hineinläuft.
- /05
Langfristig denken
Monate, nicht Wochen.
Rückschläge gehören dazu und stehen besser vorher im Plan als hinterher in einer Rechtfertigung. Von Stufe 1 bis Stufe 3 rechnen wir mit 12–18 Monaten.
Was Kunden
wirklich fragen.
- Wie etabliert man eine DevOps-Kultur im Unternehmen?
- DevOps-Kultur etabliert man nicht per Anordnung, sondern schrittweise über ein geschütztes, cross-funktionales Pilotteam. Bewährt hat sich ein Weg in sechs Schritten: den kulturellen Ist-Zustand ehrlich einordnen, ein Pilotteam aus IT und OT bilden, verbindliche Spielregeln für den Umgang mit Fehlern vereinbaren, Blameless Post-Mortems als feste Routine einführen, Erfolge mit DORA-Metriken messbar und sichtbar machen und das Muster anschließend auf weitere Bereiche übertragen. Tools sind dabei Mittel, nicht Zweck.
- Wie lange dauert es, eine DevOps-Kultur zu etablieren?
- Rechnen Sie in Monaten, nicht in Wochen. Vom Ist-Zustand auf der Stufe Ad-hoc bis zu standardisierten, cross-funktionalen Routinen auf der Stufe Defined vergehen in Industrieprojekten typischerweise 12 bis 18 Monate. Ein einzelnes, geschütztes Pilotteam liefert erste belastbare Ergebnisse aber häufig schon nach einem Quartal. Wer Rückschläge einplant und den Wandel nicht per Stichtag verordnet, kommt schneller ans Ziel.
- Wie wirkt sich die DevOps-Kultur auf die Organisationsstruktur eines Unternehmens aus?
- DevOps-Kultur verschiebt die Organisation von funktionalen Silos zu cross-funktionalen Teams, die ein Produkt von der Entwicklung bis zum Betrieb gemeinsam verantworten. Ein separates DevOps-Team als eigene Abteilung ist damit ausdrücklich nicht gemeint, es wäre nur ein neues Silo zwischen den alten. In der Industrie arbeiten Software-, Plattform- und SPS-Engineers mit gemeinsamem Backlog und gemeinsamer Rufbereitschaft, und die Führung setzt den Rahmen, statt Aufgaben zu verteilen.
- Wie kann die DevOps-Kultur in die Kultur des Servicemanagements und des Betriebs integriert werden?
- Der tragfähigste Weg ist, die bestehenden ITSM-Prozesse nicht abzuschaffen, sondern in die Pipeline zu verlagern: Change-Freigaben werden zu automatisierten Prüfschritten, Incidents münden in Blameless Post-Mortems statt in Eskalationsrunden, und Betrieb und Entwicklung teilen sich Rufbereitschaft und Kennzahlen. ITIL und DevOps widersprechen sich weniger, als beide Lager annehmen. Beide wollen Änderungen nachvollziehbar und risikoarm ausrollen, nur in unterschiedlichem Takt. Meist beginnt die Integration damit, dass Betrieb und Entwicklung zum ersten Mal denselben Vorfall gemeinsam auswerten.
- Wie misst man DevOps-Kultur?
- DevOps-Kultur misst man mit einer kurzen Teambefragung nach der Westrum-Typologie, wie DORA sie verwendet. Teammitglieder bewerten auf einer Skala von 1 bis 7 sechs Aussagen, etwa „Überbringer schlechter Nachrichten werden nicht bestraft“ oder „Fehler werden als Gelegenheit gesehen, das System zu verbessern“. Daneben stehen die DORA-Kennzahlen für Tempo und Stabilität der Auslieferung. Erst beides zusammen zeigt, ob eine bessere Kultur auch zu besseren Ergebnissen führt.
- Was ist die DevOps-Kultur?
- Die DevOps-Kultur, englisch DevOps Culture, ist eine Arbeitsweise, die Entwicklung (Dev) und Betrieb (Ops) über gemeinsame Ziele, geteilte Verantwortung, Automatisierung und kontinuierliches Lernen verbindet, statt beide in getrennten Silos zu führen. Im industriellen Kontext gehört die OT-Seite mit SPS-Programmierung und Automatisierung ausdrücklich dazu. Das CALMS-Framework beschreibt ihre fünf Säulen: Culture, Automation, Lean, Measurement, Sharing.
- Was versteht man unter DevOps?
- DevOps ist eine Arbeitsweise, in der Entwicklung (Development) und Betrieb (Operations) ein Produkt gemeinsam verantworten, von der ersten Zeile Code bis zum laufenden System. DevOps ist damit weder ein Tool noch eine Stellenbezeichnung, sondern zuerst eine Frage der Zusammenarbeit. Pipelines und Automatisierung sind das Mittel, mit dem diese Zusammenarbeit im Alltag funktioniert. Im Industrieumfeld laufen Steuerungs- und Applikationscode durch dieselbe Kette, mit denselben Freigaberegeln.
- Was sind die wichtigsten DevOps-Prinzipien?
- Die wichtigsten DevOps-Prinzipien sind gemeinsame Verantwortung von Entwicklung und Betrieb, Automatisierung wiederkehrender Arbeit, kurze Feedbackschleifen, messbare Verbesserung statt Bauchgefühl und ein Umgang mit Fehlern ohne Schuldzuweisung. Das CALMS-Framework fasst sie als Culture, Automation, Lean, Measurement und Sharing zusammen. Wer sie angeht, beginnt bei der Kultur und nicht beim Werkzeug, weil automatisierte Prozesse in einem Umfeld ohne Vertrauen zwar existieren, aber nicht benutzt werden.
- Was sind die 5 Säulen von DevOps?
- Die fünf Säulen der DevOps-Kultur sind das CALMS-Framework. CALMS steht für Culture (Zusammenarbeit über Silos hinweg), Automation (Routine an die Pipeline abgeben), Lean (kleine Schritte, kurzer Fluss), Measurement (Entscheidungen auf Basis der DORA-Metriken) und Sharing (Wissen teilen statt horten). Das Kürzel geht auf John Willis und Damon Edwards zurück, Jez Humble ergänzte das L. Im Industrieumfeld verbindet sich jede Säule mit OT-Praxis, etwa Kaizen mit Lean oder die OEE mit den DORA-Metriken.
- Was sind die 4 wichtigsten DevOps-Kennzahlen?
- Die vier klassischen DevOps-Kennzahlen sind die DORA-Metriken Deployment Frequency (wie oft Sie ausliefern), Change Lead Time (wie lange eine Änderung bis in die Produktion braucht), Change Fail Rate (welcher Anteil der Deployments Probleme verursacht) und die Wiederherstellungszeit nach einem fehlgeschlagenen Deployment. Letztere hieß früher Mean Time to Recovery (MTTR), DORA nennt sie seit 2023 Failed Deployment Recovery Time. Seit 2024 kommt als fünfte Kennzahl die Deployment Rework Rate hinzu. Im Industrieumfeld stellen wir sie neben die OEE, damit IT und OT über dieselbe Datenbasis sprechen.
- Was bedeutet Kultur im Unternehmen?
- Unternehmenskultur ist die Summe der ungeschriebenen Regeln, nach denen in einer Organisation tatsächlich entschieden und gehandelt wird. Sie zeigt sich nicht im Leitbild, sondern daran, was passiert, wenn etwas schiefgeht: ob jemand den Fehler meldet oder verschweigt, ob nach der Ursache gesucht wird oder nach einem Verantwortlichen. In DevOps ist genau dieser Punkt der Unterschied zwischen einer Pipeline, die läuft, und einer Pipeline, die auch benutzt wird.
- Was ist psychologische Sicherheit und warum braucht DevOps sie?
- Psychologische Sicherheit ist die geteilte Überzeugung im Team, dass niemand bloßgestellt oder bestraft wird, wenn er einen Fehler zugibt, eine Frage stellt oder widerspricht. Der Begriff geht auf die Harvard-Professorin Amy Edmondson zurück. Googles Studie Project Aristotle fand sie unter fünf Faktoren als den wichtigsten für effektive Teams, und DORA zeigte 2019, dass sie Software-Delivery-Leistung vorhersagt. Ohne sie werden Fehler vertuscht und Verbesserungsvorschläge zurückgehalten.
- Was ist eine positive Fehlerkultur?
- Eine positive Fehlerkultur behandelt Fehler als Lernchance statt als Versagen. Sie trennt Person und Problem, verzichtet auf Schuldzuweisungen, sucht die Ursache im System und teilt die Erkenntnisse offen. So wird aus jedem Fehler dokumentiertes Lernen der ganzen Organisation statt Vertuschung.
- Welche Fehlerkulturen gibt es?
- Grob unterscheidet man eine negative Fehlerkultur, die Energie in die Schuldfrage steckt und Fehler vertuscht, von einer positiven Fehlerkultur, die Fehler offen analysiert und als Lernchance nutzt. Die Westrum-Typologie verfeinert das in drei Stufen: pathologisch (machtorientiert, Information wird zurückgehalten), bürokratisch (regelorientiert, Information bleibt in Silos) und generativ (leistungsorientiert, Information fließt frei).
- Was sind die drei Säulen einer Fehlerkultur?
- Eine tragfähige Fehlerkultur ruht auf drei Säulen: psychologische Sicherheit (Fehler dürfen offen angesprochen werden), Analyse ohne Schuldzuweisung (Systemursachen statt Schuldige) und Lernen im System (Maßnahmen werden umgesetzt und geteilt). Erst alle drei zusammen verändern das Verhalten dauerhaft.
- Was ist ein Blameless Post-Mortem?
- Ein Blameless Post-Mortem ist eine strukturierte Auswertung eines Vorfalls, die bewusst auf Schuldzuweisungen verzichtet und stattdessen nach Systemursachen fragt. Die Leitfrage lautet „Warum war der Fehler möglich?“ statt „Wer war es?“. Die Methode stammt aus dem Site Reliability Engineering bei Google und macht aus Fehlern dokumentiertes Lernen für die ganze Organisation.
- Was ist mit Silodenken gemeint?
- Silodenken bezeichnet die Abschottung von Abteilungen, die ihr Wissen, ihre Ziele und ihre Werkzeuge nicht mehr teilen. Zwischen Entwicklung und Betrieb entsteht es, weil beide an gegensätzlichen Kennzahlen gemessen werden: die Entwicklung an ausgelieferten Features, der Betrieb an Verfügbarkeit. Beide Seiten handeln dann korrekt im Sinne ihrer Zielvorgabe und blockieren sich trotzdem gegenseitig.
- Was ist der Silo-Effekt?
- Der Silo-Effekt beschreibt die Folgen von Silodenken: doppelte Arbeit, Informationsverluste an den Abteilungsgrenzen und Entscheidungen, die für eine Abteilung optimal und für das Unternehmen teuer sind. Erkennbar ist er an fünf Symptomen: Übergaben laufen nur noch über Tickets, jede Abteilung hat eigene Kennzahlen, im Meeting fällt „die von der IT“ statt eines Namens, technische Fragen werden über Vorgesetzte eskaliert, und keine Seite kennt die Zahlen der anderen.
- Wie bricht man Silodenken auf?
- Silodenken bricht man auf, indem beide Seiten eine gemeinsame Kennzahl bekommen, für die sie zusammen geradestehen, und einen festen Ort, an dem sie sich sehen. In der Praxis sind das eine gemeinsame Retrospektive nach jedem Vorfall, ein cross-funktionales Pilotteam aus IT und OT und eine Kennzahl wie die Change Lead Time, die beide Seiten gleichzeitig gut oder schlecht aussehen lässt. Abteilungen aufzulösen ist dafür fast nie nötig.
- Was besagt Conway's Law?
- Conway's Law besagt, dass Organisationen Systeme entwerfen, die ihre eigene Kommunikationsstruktur abbilden. Melvin Conway formulierte das 1968 im Aufsatz „How Do Committees Invent?“, im Deutschen wird es als Gesetz von Conway zitiert. Für DevOps folgt daraus der nützliche Umkehrschluss, das Inverse Conway Maneuver: Wer die Architektur ändern will, schneidet zuerst die Teams so, wie das System später aussehen soll.
- Was ist der Bus-Faktor?
- Der Bus-Faktor ist die Anzahl der Personen in einem Team, die gleichzeitig ausfallen müssten, damit die Arbeit stehen bleibt. Bus-Faktor 1 bedeutet, dass eine einzige Person unersetzlich ist, etwa weil nur sie weiß, welcher Steuerungsstand auf welcher Maschine läuft. Im Englischen heißt dieselbe Kennzahl Bus Factor oder Truck Number. Er steigt nicht durch Dokumentation allein, sondern dadurch, dass die Arbeit selbst das Wissen sichtbar macht: versionierter Code, Builds als Pipeline, Freigaben als Commit.
Ein Tag.
Ein Fahrplan.
Ihr Kulturwandel.
In einem eintägigen Workshop sehen wir uns gemeinsam Ihre Ausgangslage an, benennen die zwei, drei Stellen, an denen sich am meisten bewegen lässt, und entwickeln einen Fahrplan, den Ihr Team am nächsten Montag anfangen kann. Ob das der richtige Schritt ist, klären wir vorab in einem fachlichen Erstgespräch.
Erstgespräch · 30 Minuten · unverbindlich
Auf welchen Quellen
dieser Artikel
aufbaut.
Die zentralen Konzepte dieses Beitrags, also CALMS, psychologische Sicherheit, die Westrum-Typologie, Conway’s Law und Blameless Post-Mortems, gehen auf diese Primärquellen aus Forschung und Praxis zurück. Alle Links geprüft am 29. September 2026.
- /01DORA: Generative Organizational Culture
DORA-Capability zur Westrum-Typologie, mit den sechs Aussagen, über die DORA Kultur misst. Kernaussage: Eine generative Kultur mit hohem Vertrauen sagt Software-Delivery- und Organisationsleistung voraus.
https://dora.dev/capabilities/generative-organizational-culture/
- /02DORA: State of AI-assisted Software Development 2025
Ersetzt die Performer-Klassen durch sieben Teamprofile. Hauptbefund: KI wirkt als Verstärker der vorhandenen Stärken und Schwächen einer Organisation.
https://dora.dev/research/2025/dora-report/
- /03DORA Metrics Guide
Die heute fünf Software-Delivery-Kennzahlen. MTTR heißt seit 2023 Failed Deployment Recovery Time, die Deployment Rework Rate kam 2024 dazu.
https://dora.dev/guides/dora-metrics/
- /04Google re:Work: Understand team effectiveness (Project Aristotle)
Googles Studie über 180 Teams. Psychologische Sicherheit war der wichtigste von fünf Faktoren; Teams mit starker Teamkultur wurden von Führungskräften doppelt so oft als effektiv bewertet.
https://rework.withgoogle.com/intl/en/guides/understand-team-effectiveness
- /05Amy C. Edmondson: Psychological Safety
Originaldefinition psychologischer Sicherheit (1999), ausgeführt im Buch „The Fearless Organization“ (2018).
https://amycedmondson.com/psychological-safety/
- /06Ron Westrum: A typology of organisation culture
BMJ Quality & Safety 13 (2004). Die Typologie pathologisch, bürokratisch, generativ, auf die sich DORA stützt.
https://doi.org/10.1136/qshc.2003.009522
- /07IT Revolution: DevOps Culture
Ursprung des CALMS-Modells: CAMS von John Willis und Damon Edwards (2010), das L für Lean ergänzte Jez Humble.
https://itrevolution.com/articles/devops-culture-part-1/
- /08Google SRE Book: Postmortem Culture
Blameless Post-Mortems: Systemursachen statt Schuldzuweisung (Site Reliability Engineering, Kapitel 15).
https://sre.google/sre-book/postmortem-culture/
- /09Melvin E. Conway: How Do Committees Invent?
Der Originalaufsatz von 1968 (Datamation), aus dem Conway’s Law stammt: Organisationen entwerfen Systeme, die ihre Kommunikationsstruktur abbilden.
https://www.melconway.com/Home/Committees_Paper.html
- /10Martin Fowler: Conway’s Law
Einordnung für die Praxis, einschließlich Inverse Conway Maneuver: Teams so schneiden, wie das System aussehen soll.
https://martinfowler.com/bliki/ConwaysLaw.html
Wie geht es bei Ihnen mit Fehlerkultur weiter?
Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.
Verwandte Artikel
IT/OT-Kulturwandel in der Fertigung
Warum cross-funktionale Teams die größte DevOps-Herausforderung sind.
DevOps-Reifegrad messen & benchmarken
DORA-Metriken, Maturity Assessment und Value-Stream-Mapping.
Industrial DevOps: Der komplette Leitfaden
Was ist Industrial DevOps? CI/CD für cyber-physische Systeme und Industrie 4.0.
Erstgespräch.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance