„Das hier kann sehr hilfreich sein“, sagt Matthias Marschall und holt aus einem weißen Briefumschlag einen kleinen, länglichen Gegenstand, der sich als Bleistift entpuppt. Nehme man den Stift und zerlege ihn in Einzelteile, sei es nicht mehr richtig nützlich, fährt der Keynote-Speaker vom IMC Summit fort und gräbt nach und nach demonstrativ aus dem Couvert winzige Bleistiftstücke aus. „Firmen in Abteilung zu zertrennen, ist ungefähr das Gleiche“.
Dann beschreibt der Referent Situationen, die einem – unabhängig von der Unternehmensgröße – erstaunlich bekannt vorkommen und die wahrscheinlich jeder im Publikum schon mal erlebt hat: neue Features, die an Abteilungsgrenzen hängen bleiben, Mitarbeiter, die nicht miteinander reden, sich nicht verstehen – und sich in den schlimmsten Fällen gegenseitig mit Anschuldigungen konfrontieren. Wenn Ziele nicht abgesprochen werden und „Finger Pointing“ zur allgemeingültigen Kommunikationsform wird, ist nicht nur das Betriebsklima gefährdet, sondern auch die Wertschöpfung des Unternehmens bremst. Das sei das Ergebnis der Silo-Denke, schlussfolgert Marschall.
Am Vorabend des IMC Summit in Mainz beantwortet der Engineering Lead von 
helpster.de hauptsächlich drei Fragen, die um DevOps kreisen. Was ist DevOps genau? Welche Arten der Verschwendung entstehen durch das Abteilungs-Denke? Wie macht man übergreifende Prozesse sichtbar?
Wer wäre geeigneter als Marschall, den Spuren der Verschwendung nachzugehen: Der Referent und Blogger ist seit den Anfängen von DevOps mit dabei. Zirka 2008 habe es angefangen, erzählt er. Der Belgier Patrick Debois habe den Begriff ins Leben gerufen. DevOps genoss dann ziemlich schnell eine relativ große Verbreitung. Inzwischen organisiert die Community jedes Jahr weltweit ein Dutzend Veranstaltungen zum Thema.
Wenngleich der Begriff DevOps inzwischen wohlbekannt ist, wisse man nicht immer, was dahinter steckt, bemängelt der Keynote-Speaker. „DevOps ist nichts Neues“, betont er. Man habe sich bestehende Erfolgsmodelle angeschaut, die zum Beispiel auf Scrum fußen und sich als sinnvoll erwiesen haben. Viele Unternehmen hätten einen Weg gefunden, diese im Bereich Operations umzusetzen. „DevOps ist ein Hype, aber es steckt auch viel Substanz dahinter“, ergänzt Marschall. „Letztendlich ist es nichts Anders als ein „Change Agent“.
Warum eine Umstellung notwendig ist? Um schneller zu wirtschaften, sagt Marschall ganz klar. Culture, Automation, Measurement und Sharing – das sind die vier Säulen der DevOps-Bewegung.
„Die Kultur ist die Basis für alles“, bemerkt der Referent nachdrücklich. Es sei absolut unumgänglich, ein gegenseitiges Interesse sowie eine gemeinsame Verantwortung im Betrieb zu etablieren. Auch müssten die Abteilungen frühzeitig einbezogen werden. Transparenz ist das Schlüsselwort.
„Einfach miteinander reden ist zu einfach“, erwidert ein Teilnehmer. "Wenn es funktionieren würde, wüssten wir es." Auf die Frage, ob Marschall Best Practices nennen könne, erzählt der Referent von seinen Erfahrungen in der eigenen Firma – von zwangslosen Treffen beim Frühstück alle zwei Wochen, von einfachen „Drink-ups“ mit Vorträgen, Pizza und Bier. Darüber hinaus hätte das Unternehmen auch „Business Guilds“ eingeführt, um gemeinsame Interessen abteilungsübergreifend voranzutreiben – zum Beispiel zu den Themen Software Testing und SEO.
„In großen Unternehmen kennt man schon in der eigenen Abteilung nicht mehr jeden persönlich. Solche Maßnahmen helfen, mit anderen in Kontakt zu treten.“ Es sei schon alles viel einfacher, wenn man zu einem Namen ein Gesicht vor Augen hat oder ein paar Anhaltspunkte zu den Interessen vom Kollegen.
Sitzen die Mitarbeiter allerdings geografisch getrennt, dann wird es schwieriger. Marschall vertritt die These, dass es einfacher ist, ein Wir-Gefühl zu erzeugen, wenn alle allein im Home-Office arbeiten. Dann wird auf virtuelle Kommunikationswege zurückgegriffen. Das funktioniert. Arbeiten indes verschiedene Teams an unterschiedlichen Orten, dann ist die Gefahr groß, dass Sub-Kulturen entstehen.
Ein Teilnehmer fragt, ob Marschall es geschafft hat, in seinem Unternehmen die Kultur zu ändern. Marschall bejaht und erklärt: Der Wille müsse von der Basis kommen, die Unterstützung von oben sei aber genauso entscheidend. „Wenn der C-Level sagt ‚Nee, will ich nicht‘, dann haben Sie ganz schlechte Karten. Aber von oben oktroyiert funktioniert es auch schlecht“, fügt er hinzu und verzögert das Gesicht.
Wenn die Kultur stimmt, können durch einen höheren Automatisierungsgrad in Staging und Produktion weitere Verbesserungen erreicht werden. Ziel seien Ein-Klick-Releases, die für genug Schnelligkeit und Flexibilität sorgten. Unternehmen wie Flickr schafften es, zehn Deployments am Tag durchzuführen. Doch sich auf sein Bauchgefühl zu berufen hilft nicht viel: Es sei besonders wichtig, zahlengetrieben zu arbeiten – und zwar nicht nur bei Features, sondern auch beim Serverbetrieb.
Mit Sharing schließt sich der Kreis: "Die Probleme sind der Feind, nicht die Kollegen", heißt es. Wer sich dies regelmäßig vor Augen führt und für genug Transparenz sorgt, schafft Vertrauen. Wer versteht, wie Entscheidungen entstanden sind, ist eher bereit, diese hinzunehmen – selbst wenn sie ihm vielleicht persönlich missfallen.
Dass es alles nichts Neues ist, weiß Marschall sehr wohl. Es handle sich nur um Spotlights, die gut funktionieren. Natürlich könne man nicht alle Probleme lösen. Aber man könne an überraschend vielen Stellen Verbesserungen erzielen.
Trotzdem zirkulieren immer noch gewisse Erneuerungs-Killer in Unternehmen. Es sind Aussagen wie „das haben wir immer schon so gemacht“ oder Vorschriften, die aus der Historie heraus entstanden sind aber keinen Bezug mehr zur Realität haben. Es sind auch Annahmen, die auf falschen Hypothesen beruhen.
Marschall bringt ein schönes Beispiel aus seinen eigenen Erfahrungen: Sein Team hatte in einem Projekt relativ lange Release-Zyklen. Das Team war der Meinung, dass es diese zur Qualitätssicherung brauchen. Um einem unzufriedenen Kunden entgegenzukommen, hat er Zyklen von zwei Monaten eingeführt. Nach dieser Umstellung stellte das Development-Team fest, dass es falsch gelegen hatte. Effektiv hatten sie weniger Features im Release – also auch weniger Bugs. Die Stabilisierungsphase erwies sich auch als extrem kürzer. Sie kamen zu der Erkenntnis, dass kein Unterschied zwischen Bugfixes und Einführung neuer Features besteht. Also verzichteten sie komplett auf Release-Zyklen setzten auf Continuous Deployment.
Solche Zeit- und Nervenfresser sind in Unternehmen weit verbreitet. Auf Japanisch bezeichnet Mulda eine sinnlose Tätigkeit, eine Verschwendung, die durch Wertschöpfung ersetzt werden will. Dafür muss man aber erst in der Lage sein, die Verschwendung zu identifizieren: Marschall präsentiert sieben - dabei geht es zum Beispiel um Übergaben, bei denen viel Know-how verloren geht. Besonders ärgerlich findet Marschall auch das erneute Lernen von Sachen, die man schon mal gelernt, aber wieder vergessen hat – ganz nach dem Motto: „Das wusste ich schon mal“.
Zu den Top-Verschwendungen gehören auch Verzögerungen – sei es das Warten auf Freigaben oder die Überlastung einer Abteilung oder eines Mitarbeiters. Mit einem Value Stream Mapping lassen sich diese Zeitverzögerungen gut aufzeigen und dann von Fall zu Fall vielleicht auch verhindern.
Gegen die „Don’t Care“-Mentalität indes könne nur das Gefühl einer gemeinsamen Verantwortung weiterhelfen, meint Marschall. Es ist die einzige Stellenschraube, an der man in dem Fall drehen kann, , um Fehler und Bugs zu vermeiden.
Das Inventar wird den meisten Unternehmen auch wohl bekannt sein: Es sind lose Listen, die nie abgearbeitet wurden, unfertige Features, Vergessene Sachen. Marschall und sein Team haben sich einmal die Mühe gemacht, im Projekt-Tracker „Jira“ die offenen Punkte alle zu erfassen. Sie kamen auf insgesamt 1448 Items. Der Versuch, diese nachzuvollziehen und priorisieren, um sie dann abzuarbeiten, blieb erfolglos. Es war zu viel. Bis auf 200 wurden alle gelöscht.
Marschall verspricht keine Wunderwaffe. Er kommt allerdings mit interessanten Ideen und mit der Lust, seine Erfahrungen und Kenntnisse mit den DOAG-Teilnehmern zu teilen. Die Gespräche werden nach der Keynote draußen auf der Terrasse des Hotels weitergeführt. Die Veranstaltung – eine Zusammenlegung vom Vorabend des IMC Summits und Regionaltreffen Rhein-Mainz – hätte durchaus mehr Aufmerksamkeit verdient.
