Bei DevOps geht’s um Spaß an der Arbeit und Lernen

Im Grunde könnte dieser dritte Teil meiner DevOps-Serie sehr kurz sein.

Statt zu schreiben, wie sich Feedback-Loops und Systemdenken ins große Ganze einfügen und welche Rolle Lernen dabei spielt, könnte ich einen plakativen Gedanken formulieren, der sich wahrscheinlich in einen 140 Zeichen langen Tweet verpacken in den Äther schicken ließ.

Lernen muss in Unternehmen „Business as usual“ sein.

Acht Wörter und noch 88 Zeichen übrig, die ich mit ein paar Reichweite-erhöhenden Hashtags füllen könnte.

Ich zögere.

Für einen ersten Versuch nicht schlecht, denke ich. Was aber wären die passenden Hashtags und könnte ich einen Bezug zu aktuellen Ereignissen herstellen? Würde dieser Tweet viele Retweets produzieren, eine fruchtbare Diskussion entfachen oder gar das Handeln von irgendwem beeinflussen?

Oder würde die Wirkung dieses Tweets einfach verpuffen?

Da kann man noch was verbessern, folgere ich. In der Flut, die täglich an meinen Followern vorbei zieht, könnte dieser Tweet wohl einfach untergehen.

Schließlich kommt mir das Wort Hypothese in den Sinn und mir wird klar, dass mein innerer Kritiker, der Schelm, einfach Annahmen trifft ohne sie zu testen. Das tut er ständig, muss er vielleicht auch, weil irgendwer mich ja drauf hinweisen muss: Hey du, deine Idee ist Mist. Jedenfalls, wenn mal Leib und Leben dran hängen sollte.

Dann schicke ich den Tweet ab. Einfach so.

Hypothesen sind solange unwahr, wie sie nicht überprüft wurden

Im Alltag treffen wir viele Annahmen.

Wir schätzen Risiken ein und oft bleiben wir dann untätig oder investieren noch ein bisschen mehr Aufand in Absicherung. Manchmal warten wir auch darauf, dass die Umstände besser werden.

Wir haben dafür wunderbar klingende Bezeichnungen wie bedachtes oder überlegtes Handeln und einen großen Werkzeugkasten, mit dem wir unser Urteil a priori untermauern können: darunter so Totschlagargumente wie „Dafür ist jetzt ein ganz schlechter Zeitpunkt“.

Unser Überlegungen erfüllen durchaus einen Zweck: Hin- und wieder mal die Wirtschaftlichkeit zu hinterfragen, verhindert beispielsweise, dass jeder „Hirnfurz“ früher oder später im Gang zum Arbeitsamt gipfelt.

Vorsicht ist die Mutter der Porzellankiste, wie?

Das Problem ist: Wir müssen Risiken eingehen, wenn wir erfolgreich sein wollen. Außerdem sind wir nicht besonders gut tatsächliches Risiko von Unsicherheit oder gar Ungewisssheit zu unterscheiden.

In der Entscheidungstheorie spricht man von Entscheidungen unter Risiko, wenn für die erwarteten Risiken eine Eintrittswahrscheinlichkeit angegeben werden kann. Bei vielen Erscheinungen kennen wir aber nicht mal alle möglichen Ereignisse, sodass es unmöglich ist, für diese eine Eintrittswahrscheinlichkeit anzugeben.

Stellt sich die Frage: Wie gehen wir damit um?

Wenn wir jedes Risiko im Vorfeld ausschließen wollen, verlieren wir wahrscheinlich.

Denn unser Erfolg mit dieser Strategie hängt auch davon ab, wie sich die anderen Marktteilnehmer verhalten – und wir können sicher sein, dass es auch Teilnehmer mit einer höheren Risikoaffinität gibt.

Wenn wir beispielsweise nur „wenn mal Luft ist“ in Fortbildung und interne Verbesserungsmaßnahmen investieren, wird es andere Marktteilnehmer geben, die das zu jeder Zeit tun. Diese könnten es sein, die uns einen wichtigen Auftrag wegschnappen oder auch potenzielle, qualifizierte Mitarbeiter, weil Profis gerne mit anderen Profis zusammen arbeiten.

Damit besteht eine relativ hohe Wahrscheinlichkeit, dass wir dem Markt im Grunde nur hinterher hecheln, während dieser uns früher oder später abhängt.

Nicht die Sprünge ins kalte Wasser sondern die Fallhöhe verringern

Statt den Sprung ins Wasser zu vermeiden, könnte es darum gehen, die Fallhöhe zu verringern. Dafür muss das Unternehmenssystem insgesamt resilienter werden, also lernen, besser mit Ungewissheit und Fehlern umzugehen.

Das setzt vorraus:

1. Eine Umgebung, in der proaktiv Wissen generiert wird, damit auch auf veränderte Marktbedingungen ohne große Anlaufzeit reagiert werden kann, und in der ein Wissensübertrag zwischen den einzelnen Personen und Teams stattfindet.

2. Ein Umgang mit Fehlern, bei dem nicht die Verursacher gesucht und gehängt werden, sondern Ursachenforschung ohne Schuldzuweisung betrieben wird und darauf hin gearbeitet wird, um daraus für die Zukunft zu lernen und Fehlerpotenzial abzustellen (zum Beispiel durch Verbesserungsmaßnahmen).

3. Eine Vorgehensweise, bei der Hypothesen aufgestellt und getestet (vgl. Scientific Method) werden und z.B. mithilfe von Feedback-Loops frühzeitig Erkenntnisse generiert werden.

4. Aktiv die Arbeit im System verbessern, indem gewonnene Erkenntnisse und Wissen in Ergebnisse überführt werden, die allen Akteuren im System zugute kommen.

Gerade dieser letzte Punkt erfordert die Mitarbeit aller im Unternehmen und so muss diesem Punkt eine gewisse Priorität und Zeit dafür eingeräumt werden. Das erfordert auch ein gewisses Vertrauen in die Mitarbeiter und Kollegen.

Wenn immer auf Kante genäht wird und Verbesserung das Privileg einiger Weniger ist, darf man sich schließlich nicht wundern, wenn die Personen im Unternehmen nicht dazu beitragen, die Arbeit für andere Personen im Unternehmen zu verbessern.

Prozesse bleiben nicht einfach wie sie sind, sondern verschlechtern sich mit der Zeit

Even more important than daily work is the improvement of daily work. –Mike Orzen, Autor von „Lean IT“

Verbesserung vor Tagesgeschäft klingt radikal, ist aber sinnvoll wie Erkenntnisse aus der Management-Forschung verdeutlichen:

Der amerikanische Forscher Mike Rother hat beispielsweise festgestellt, dass Prozesse nicht einfach bleiben wie sie sind, sondern sich mit der Zeit sogar verschlechtern.

Seine Lösung für das Problem ist als Toyota Kata bekannt geworden, das einen wesentlichen Aspekt der Lean-Prinzipien ausmacht und mit Deliberate Practice zu tun hat – nur eben unternehmensweit.

Verbesserung ins Daily Doing integrieren

Wir wollen das Tagesgeschäft natürlich nicht vernachlässigen, sodass es darauf ankommt, Verbesserungsmaßnahmen ins „daily doing“ zu integrieren.

So geht es etwa Toyota oder auch Improvement Kata um regelmäßig zu praktizierende Routinen, die auf die Ausbildung positiver Gewohnheiten abzielen.

Wir erinnern uns: Gewohnheiten prägen Unternehmen.

Abschließend möchte ich daher ein paar Einzelmaßnahmen vorschlagen, die dazu beitragen können, aktiv Wissen zu generieren, zu verteilen und „globale“ Verbesserung am System zu erzielen.

Zeit für Verbesserung und Fortbildung reservieren

Von nichts kommt nichts und deshalb muss regelmäßig Zeit für Verbesserung reserviert werden.

Innerhalb von Projekten kann man das beispielsweise erzielen, indem man Zeiten einplant, um Defekte zu beheben, technische Schulden abzubauen oder allgemein Verbesserungen umzusetzen. Eine Möglichkeit sind auch sogenannte Kaizen Blitzes am Anfang eines Projekts. Dabei werden ein paar Tage veranschlagt, innerhalb derer sich die „Entwickler“ selbstorganisieren, um an von ihnen gewählten Problemen zu arbeiten.

Außerhalb von Projekten können Zeiten festgelegt werden, die Mitarbeiter regelmäßig für Fortbildung (zum Beispiel Einarbeitung in neue Themen) oder Mini-Projekte nutzen können.

Bill Talks / Lightning Talks

Angelehnt an das Format von Ted- oder Lightning-Talks veranstalten wir bei der credativ Gmbh schon seit längerem Bill Talks.

Dabei halten Kollegen (freiwillig) einen Kurzvortrag zu einem Thema ihrer Wahl. Bei uns sind das meistens technische Themen wie die Vorstellung neuer Technologien, eines Tools, das man entdeckt hat, oder spannende Themen, an denen gerade gearbeitet wird. Der Fokus liegt hier auf Kürze, womit sich das Format recht gut im Alltag unterbringen lässt.

Meist schließt sich an die Talks noch ein Fachsimpeln unter Kollegen an, womit sich neben dem Wissensübertrag auch eine Chance zum Socializing bietet.

Workshops zur Übertragung fortgeschrittener Fähigkeiten (WUFF)

Ein weiteres Mittel, von dem wir Gebrauch machen, sind Workshops – von uns liebevoll WUFF genannt.

Diese sind etwas zeitintensiver, dafür auch effektiver. Bei diesen Workshops steht ein Thema im Vordergrund, über das ein Kollege anderen Kollegen etwas beibringt.

Wie der Name schon sagt, haben diese Workshops eher einen „Hands on“-Charakter. Beispielsweise hatten wir im Team vor gar nicht all zu langer Zeit noch einen Workshop, indem wir uns unter Anleitung eines Kollegen am Rails-Guide entlang gehangelt und eine kleine, exemplarische Blog-Software gebastelt haben.

Der Vorteil dieser Workshops ist, dass die Kollegen Neues erlernen und dabei von Vorwissen und Erfahrung ihres Kollegen profieren können.

Wall-Skills / Testing on the toilet

Nebenbei ein bisschen Wissen mitnehmen, vielleicht sogar beim Toilettengang?

Die Google-Tester hatten zu diesem Zweck mal eine Initiative namens „Testing on the toilet“ gestart, bei denen sie Flyer mit Tipps zum Testen aufgehängt haben.

Entsprechende „1-pagers“ zu einem größeren Themengebiet (z.B. Agile Methoden, Anforderungsmanagement, Schreibtipps, …) findet man beispielsweise bei Wall-Skills.com, an dem ein ehemaliger Kollege beteiligt ist, der zur Einführung der oben genannten Maßnahmen bei credativ beigetragen hat.

Post mortems bei gelösten Problemen

In einer Umgebung, in der gearbeitet wird, passieren Fehler und treten Probleme auf.

Oft werden diese gelöst und zum Tagesgeschäft übergegangen, ohne dass die Erkenntnisse für die Zukunft nutzbar gemacht werden. Manchmal entstehen dabei aber auch Analysen, die sehr hilfreich sein können, wenn sie an zentraler Stelle gespeichert und für alle zugänglich gemacht werden.

Bei Post Mortems geht es darum, aus einem Vorfall möglichst viele Erkenntnisse zu generieren und so aus einem Problem zu lernen. Dabei wird in dem Post Mortem festgehalten:

• die eingetretenen Ereignisse in chronologischer Reihenfolge

• die ermittelten Ursachen (wobei man sich zum Beispiel dem Mittel der 5 Whys bedienen kann, um tieferliegende Ursachen zu ermitteln)

• welche Annahmen bei der Problembehebung getroffen wurden

• mögliche Verbesserungsmaßnahmen, die über die Problembehebung hinaus helfen können, ein ähnliches Problem zu vermeiden

Auf Schuldzuweisungen oder Konsequenzen für „Verursacher“ soll bei diesen Post Mortems bewusst verzichtet werden, weil so eher dazu beigetragen wird, dass sich Personen absichern statt verantwortungsbewusst zur Problemlösung beizutragen.

FAQs, Wikis, schriftliche Dokumentation

Während der Arbeit auf ein Problem mit einem internen System gestoßen und gelöst? Oder gibt es vielleicht Themen, die häufig angefragt werden und wo sich die Einarbeitung durch Kollegen lohnen würde?

Solche Informationen nützen mehr, wenn sie nicht im Kopf einzelner Personen sind, sondern nachgelesen werden können.

Auch wenn es für Wissenshaltung in vielen Fällen dedizierte Lösungen gibt: ein Eintrag auf einer Wiki-Seite reicht in vielen Fällen schon aus. Manchmal reicht aber natürlich auch eine Mail um Kurztipps an den Mann oder die Frau zu bringen. 🙂

Letztlich geht es um’s Lernen und darum, dass Arbeit Spaß macht

Patrick Debois, einer der Initiatoren der DevOps-Bewegung, soll gesagt haben, dass es bei DevOps um den „Fun“ bei der Arbeit geht.

Aus meiner Sicht macht Arbeit dann Spaß, wenn man sein Wissen und seine Fähigkeiten einbringen kann, um zusammen mit Anderen etwas zu erreichen, und wenn man dabei regelmäßig etwas Neues lernen kann – auch und gerade voneinander.

Wenn man sich andererseits ständig absichern muss, beim kleinsten Fehler mit einem Lynchmob oder mit herabwürdigenden Kommentaren rechnen muss („Wer ist denn so blöd?“) macht Arbeiten keinen Spaß. In so einer Umgebung ist man nur ein Rädchen im System, eine Ziffernfolge auf einer Personalakte und nicht eines der Individuen, die wir tatsächlich sind.**

Wir können alle dazu beitragen, dass Arbeit Spaß macht, wenn wir zusammenarbeiten, unser Wissen, unsere Erfahrung und unsere Erkenntnisse teilen. Vor allem sollten wir bei Problemen nicht „Wer war’s?“ Sondern „Wie kann ich helfen?“ Fragen.

Weiterführende Informationen

Disclaimer in Sachen Transparenz: Ein paar der nachfolgenden Links sind Affliate-Links zu Amazon.

• DevOps Handbook: Im DevOps Handbook beschreiben Initiatoren der DevOps Bewegung, was es damit auf sich hat, wie man es anwendet und warum Unternehmen mit DevOps-Praktiken erfolgreich sind. Ich habe es oft bei Recherchen für diese Serie herangezogen.

• Automation is not DevOps: Englischsprachiger Artikel, der sehr gut darlegt, worum es bei DevOps eigentlich geht: die Kultur des Unternehmens und nicht Automatisierung. Die ist höchstens Mittel zum Zweck.

• Mike Rother hat einige Bücher zum Thema Improvement Kata geschrieben und stellt zudem Materialien (auch ein umfangreiches Workbook) unter „Creative Commons“-Lizenz zur freien Verfügung.

• Blameless Postmortems and a Just Culture: Englischsprachiger Artikel, worauf es bei Post Mortems ankommt, der auch beleuchtet wieso von Schuldzuweisungen Abstand genommen werden sollte.

• We call it saw time: über ein „20% time“-Konzept, das weniger auf Innovation als auf das „Schärfen der Säge“ abzielt: ein Begriff, den einige Leser vielleicht aus Die 7 Wege zur Effektivität von Stephen Covey kennen.

Wenn euch der Artikel gefallen hat, würde ich mich freuen, wenn ihr ihn teilt. Der oben erwähnte Tweet war übrigens nicht sonderlich erfolgreich. 😉