Suche
Interview mit Thomas Much

„Agile und DevOps bringen Probleme frühzeitig zum Vorschein, anstatt sie zu verstecken“

Carina Schipper, Hartmut Schlosser

Thomas Much

Agile Methoden und sogar DevOps sind keine neumodische Erscheinung in der Welt der Softwareentwicklung, sondern – wenn auch nicht unter diesen Namen – weitaus länger bekannt. Die historischen Wurzeln ergründet Thomas Much in diesem Interview zur W-JAX 2017 und bezieht sich dabei vor allem auf das Apollo-Programm der NASA.

JAXenter: In deinem Talk auf der W-JAX 2017 hast du Agile und DevOps aus einer historischen Perspektive betrachtet. Und zwar aus der Warte des Apollo-Programms beim Flug zum Mond. Wie kam dir die Idee, IT mit dem Apollo-Programm zu vergleichen?

Thomas Much: Seit meiner Kindheit bin ich begeistert von der Raumfahrt. Zwar habe ich die Mondlandungen nicht bewusst miterlebt, aber die Flüge der Space Shuttles haben mich vor den Fernseher gefesselt. Ich habe alles an Literatur dazu verschlungen, was ich finden konnte, nur um dann auf meinem Heimcomputer (einem ZX Spectrum 🙂 ) zu versuchen, Flugbahnen zu berechnen und Aufnahmen von Forschungssatelliten zu simulieren.

Fast Forward in die 90er/2000er: Viele der ehemaligen Apollo-Mitarbeiter veröffentlichen nach und nach ihre Biografien. Als ich vor einigen Jahren „Flight“ von Chris Kraft über seine Zeit im Mission Control Center gelesen habe, dachte ich nur: Wow. Da sind so viele coole Analogien zur heutigen Softwareentwicklung drin, davon muss ich unbedingt meinen Teams erzählen. Das habe ich gemacht und wir haben angeregte Diskussionen geführt – und schließlich ist ein ganzer Vortrag daraus entstanden.

JAXenter: Inwiefern spielte Agile und DevOps damals eine Rolle?

In einzelnen Bereichen des Apollo-Programms entstanden Vorgehensweisen, die man aus heutiger Sicht als Agile oder DevOps bezeichnen kann.

Thomas Much: Die Begriffe existierten in der heutigen Form natürlich noch nicht, und auch das „klassische“ Projektmanagement war gerade erst am Entstehen. Für das Apollo-Programm mit seinen zeitweise bis zu 400.000 Mitarbeitern mussten ganz neue Formen des Managements und der Zusammenarbeit erfunden werden.

In einer so riesigen Organisation bildeten sich Hierarchien und Silos mit all ihren Problemen. Aber in einzelnen Bereichen entstanden Vorgehensweisen, die man aus heutiger Sicht durchaus als Agile oder DevOps bezeichnen kann. Denn dort wurden die Grundlagen gefunden – und gelebt! –, die für den Erfolg von Apollo entscheidend waren und die auch heute für erfolgreiches agiles Vorgehen bzw. DevOps unabdingbar sind. Und diese Grundlagen sind viel wichtiger als irgend ein bestimmtes Vorgehensmodell oder ein cooler Name.

JAXenter: Könnt ihr ein Beispiel nennen, wo wir aus der damaligen Team-Organisation etwas für heute lernen können?

Thomas Much: Ganz klar vom Umgang mit Fehlern und Fehlschlägen. Zwar kümmern sich mittlerweile immer mehr Firmen um eine „Fehlerkultur“. Aber die Selbstverständlichkeit und Regelmäßigkeit, mit der bei Apollo Probleme analysiert und Konsequenzen daraus gezogen wurden, ist immer noch beeindruckend. Und das Üben bzw. Durchspielen von möglichen Problemsituationen ist unserem Wissen nach unübertroffen. Davon können wir uns in der IT noch mehr als eine kleine Scheibe abschneiden.

JAXenter: Und sagt der historische Vergleich auch etwas darüber aus, was mit einem agilen Vorgehen nur schwierig zu vereinbaren ist?

Thomas Much: Falsche bzw. fehlende Planung hat schon bei der Apollo-Software zu den Problemen geführt, die wir auch heute bei fehlgesteuerten Softwareprojekten bekommen. Leider trifft man immer noch die Meinung an, dass bei „agilen“ Projekten wenig Planung nötig sei. Das Gegenteil ist der Fall! Wir müssen eine Idee von unserem Ziel haben, und der Weg dorthin muss gut geplant (und bei Bedarf umgeplant) werden. Ohne vernünftige Planung bekommt man statt agiler Softwareentwicklung oft nur Chaos.

Lesen Sie auch: Was ist eigentlich DevOps?

Bei Apollo 1 hatten Schludrigkeit und schlechte Kommunikation tödliche Konsequenzen, drei Astronauten starben. Wenn wir heute mit DevOps unsere Softwareauslieferung automatisieren, brauchen wir eine vernünftige Qualität, damit wir nicht aus Versehen automatisiert viel kaputtmachen. Wir brauchen einen Willen für Qualität und Exzellenz.

JAXenter: Viele Unternehmen wagen sich derzeit an DevOps – führen Docker ein, setzen Continuous-Delivery-Pipelines auf, bilden cross-funktionale Teams. Und dennoch leben die Kleinkriege zwischen den früheren Abteilungen weiter. Weshalb ist es denn so schwierig, eine Kultur der gegenseitigen Blockade gegen eine Kultur der kollaborativen Zusammenarbeit zu tauschen?

Thomas Much: Agiles, kontinuierliches Vorgehen (und damit auch DevOps) bringt Probleme frühzeitig zum Vorschein, anstatt sie zu verstecken. Das ist für viele ungewohnt, vor allem wenn man bisher gewohnt war, erst einmal im Stillen zu frickeln und irgendwann später etwas abzuliefern. Wenn dann beim großen Release etwas schief ging, konnte man sich viel besser hinter der Masse an Änderungen (und damit den möglichen Fehlerquellen) verstecken.

Viele fühlen sich durch das Aufdecken von Fehlern bedroht, sehen das als persönlichen Angriff oder Infragestellung der eigenen Kompetenz.

Viele fühlen sich durch das Aufdecken von Fehlern bedroht, sehen das als persönlichen Angriff oder Infragestellung der eigenen Kompetenz. Menschlich gesehen ist das absolut nachvollziehbar. Für das Umdenken und Umlernen muss ein Umfeld geschaffen werden, in dem man sich sicher fühlt und anderen offen und vertrauensvoll gegenübertreten kann. In einer Kultur von „Finger Pointing“ und Schuldzuweisungen ist das sicher nicht der Fall.

Was schon innerhalb eines Teams eine Herausforderung darstellt, wird zwischen Teams und Abteilungen nicht einfacher. Werden dann noch falsche Anreize gesetzt („Welches Team hat am wenigsten Fehler gemeldet?“), darf man sich nicht wundern, wenn man als Ergebnis Abschottung statt Offenheit vorfindet. Häufig gibt es auch bürokratische Hürden: Zuständigkeiten, Hierarchien, Budgetierung. Wenn die Zusammenarbeit ein paar Mal an solchen Hürden scheitert, schalten viele Mitarbeiter auf einen Mir-doch-egal-Modus um.

JAXenter: Worauf kommt es deiner Erfahrung nach an, wenn man einen Kulturwandel hin zu mehr Kollaboration über Abteilungsgrenzen hinweg erreichen möchte? Hast du da vielleicht einen konkreten Tipp, der sich in der Praxis bewährt hat?

Thomas Much: Erfolgreiche Kollaboration braucht Vertrauen. Vertrauen schaffen ist nicht leicht. Am ehesten gelingt das, wenn ich dem anderen menschlich auf Augenhöhe begegnen kann. Und wenn Führungskräfte ehrlich mit gutem Beispiel vorangehen. Beispielsweise könnte auch das Management über „Lessons Learned“ berichten, wie man dort mit Problemen und Fehlentscheidungen umgegangen ist.

Für Entwickler haben wir ganz konkret die Erfahrung gemacht, dass ein Austausch von einzelnen Entwicklern zwischen den Teams unglaublich hilfreich ist, um Vertrauen aufzubauen, Best Practices auszutauschen und Verständnis für die Aufgaben des anderen Teams zu bekommen. So ein Austausch ist normalerweise auf Zeit, z.B. im Rahmen von zwei bis sechs Wochen. Und planbar ist das auch ziemlich problemlos, denn ob jemand für 1-3 Sprints im Austausch oder im Urlaub ist, ist aus Planungssicht egal.

Lesen Sie auch: DevOps: „Mit Optimierung in der IT allein kann man den Herausforderungen der Digitalisierung nicht beikommen“

Damit der Austausch als Bereicherung für beide Seiten empfunden wird, sollte ein Austausch-Entwickler gut mit anderen Entwicklern zusammenarbeiten können. Hier haben wir Pair Programming als große Hilfe empfunden. Wenn ich es in meinem Team gewohnt bin, häufig mit anderen zusammen zu programmieren, gelingt mir das auch schnell in einem anderen Team.

JAXenter: Viele Teams erleben irgendwann ihr persönliches „Apollo 13“ – wie sollten Teams damit umgehen?

Es ist ganz normal, dass Teams irgendwann Probleme bekommen, selbst wenn lange Zeit alles rund lief.

Thomas Much: Nehmt Hilfe von außen an! Es ist ganz normal, dass Teams irgendwann Probleme bekommen, selbst wenn lange Zeit alles rund lief. Es muss nur ein Teammitglied neu dazukommen oder aus dem Team verschwinden, schon laufen gruppendynamische Prozesse ab, die ein Team im schlimmsten Fall zerstören können. Es ist aber unglaublich schwierig, als Team selbst das Problem erkennen und somit lösen zu können. Man ist viel zu sehr ins Tagesgeschäft eingebunden und akzeptiert viele Dinge als „normal“. Ein Außenstehender erkennt die Problemursachen meist viel besser.

Wenn ich als Coach in Teams eingeladen werde, bemerke ich diesen Effekt immer wieder. Und wenn ich als Softwareentwickler in einem Team mitarbeite, gibt es immer wieder Situationen, wo ich mir Hilfe von Außen wünschen würde. Aber natürlich muss die Team-/Projekt-/Abteilungsleitung hinter einer solchen Entscheidung stehen.

So kann man aus Team-Problemen sogar gestärkt hervorgehen. Nicht umsonst gilt Apollo 13 als „erfolgreicher Fehlschlag“! Das Team wurde gerettet, man hat viel gelernt und für die Zukunft verbessert.

JAXenter: Der berühmte Blick über den Tellerrand: Fallen dir abgesehen von Apollo andere Beispiele ein, von denen sich die IT etwas abschauen könnte?

Thomas Much Da fallen mir spontan zwei Vorträge ein. Vor kurzem hat Julia Dellnitz über ihre Expedition auf einem Forschungsschiff berichtet. Sehr spannend, vor allem für Planung, Selbstorganisation und (Team-)Entscheidungen! Und bereits vor längerer Zeit hat Udo Wiegärtner über Agilität in seinem Bekanntenkreis erzählt, z.B. wie eine Friseurin oder ein Feuerwehrmann sich auf die Dinge vorbereiten, die nicht exakt planbar sind. Ich selbst bin derzeit fasziniert davon, was ich aus der Grundschulklasse unseres Sohnes mitbekomme: Wie sich die Kinder als Gruppe zusammenfinden und gemeinsam das Lernen lernen. Vielleicht erzähle ich im nächsten Jahr darüber mal etwas 😉

P.S.: Wer doch noch mehr von der Raumfahrt lernen möchte, findet hier meine Top 5 der Bücher, die ich als Einstieg empfehlen würde:

  1. „Flight“ von Chris Kraft
  2. „An Astronaut’s Guide to Life on Earth“ von Chris Hadfield (Danke an Jens Schauder für diesen Tipp!)
  3. „Failure Is Not An Option“ von Gene Kranz
  4. „Last Man on the Moon“ von Eugene Cernan
  5. „Riding Rockets“ von Mike Mullane
Als Agile Developer Coach und Softwareentwickler unterstützt Thomas Much zahlreiche Teams bei der Bewältigung der alltäglichen Projektherausforderungen, sowohl methodisch als auch technisch – und oft auch an der Reibefläche dazwischen. Er lebt mit seiner Familie in Hamburg und lässt sich gerne vom nordischen Wind den Kopf für neue Ideen freipusten.

Verwandte Themen:

Geschrieben von
Carina Schipper
Carina Schipper
Carina Schipper ist seit 2017 Redakteurin beim Java Magazin, Business Technology und JAXenter. Sie hat Germanistik und Europäische Ethnologie / Volkskunde an der Julius-Maximilians-Universität Würzburg studiert.
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.