Dem Anderen zuhören, sich für Neues öffnen
Das Bild, das die Entwickler des Teams auf das Thema DevOps hatten und das Bild, das die Techniker davon hatten, war zunächst einfach unterschiedlich. Deshalb bestand eine meiner Hauptaufgaben immer wieder darin, dafür zu sorgen, dass weder Entwickler noch Techniker ihr jeweiliges Bild "der Sache" als selbstverständlich und richtig betrachten. Beide dazu zu bringen, nichts für selbstverständlich oder gegeben zu halten und dem anderen Part zuzuhören und sich zu öffnen, war die Voraussetzung für die gegenseitige Befruchtung.
Wichtig war es, dafür eine Atmosphäre zu schaffen, in der es möglich ist, zu sagen, wenn man von etwas (noch) keine Ahnung hat, ohne das Gefühl dadurch den Respekt der Kollegen zu verlieren. Dafür war es grundsätzlich hilfreich, die Regeln der Zusammenarbeit schon früh im Projektverlauf zu klären und zu diskutieren (aber das würde man auch mit einem reinen Dev oder Ops-Team so machen).
Den Fokus halten
Nachdem die gegenseitige Befruchtung in Gang gekommen war, bestand die zweite Herausforderung, den Fokus zu halten. Neues begeistert, es will ausprobiert werden, auch wenn der Anwendungsfall (noch) nicht definiert ist.
Da wir uns als Team auf ein definiertes Ergebnis committed hatten, war es wichtig, immer wieder zu hinterfragen, welche Doings uns diesem Ergebnis näher bringen und welche Doings einen - wenn auch interessanten - Umweg darstellen würden. Daran, dass Tasks erst abgeschlossen werden, bevor neue angefangen werden, arbeiten wir noch :-)
Sorge tragen, dass die Mitarbeiter sich nicht übernehmen
Die Lernkurve ist sehr steil, wenn ein DevOps-Team initial zusammengesetzt wird. Das ist zwar spannend, aber auch sehr anstrengend. In Lernphasen ist es besonders wichtig, dass die notwendigen Ruhephasen eingehalten werden. Nach den ersten zwei Wochen wurde deutlich, dass wir insgesamt Tempo raus nehmen müssen, um das zu erreichen.
Persönliche Herausforderung: Bleibe neutral
Ich glaube, es war gut, dass ich selbst bereits länger nicht mehr aktiv entwickle und persönlich weder in Dev noch in Ops verhaftet bin. Wichtig ist, dass beide Seiten gleichermaßen zum Zug kommen können und sich gegenseitig wertschätzen, um einen Benefit von der Zusammenarbeit zu haben.
Natürlich ist die Retrospektive in einem agilen Umfeld eine Gelegenheit, immer wieder das Bild auf das Projekt im Team zu synchronisieren. Allerdings bin ich der Meinung, dass das in einem initial zusammengestellten DevOps-Team längst nicht ausreicht. Das Team hat oft als gesamtes Team am Beamer zusammen gearbeitet. Am Anfang hatten wir das Gefühl, dass uns das viel Zeit kostet, in der Zwischenzeit denken wir, dass es uns weiter gebracht hat als Parallelisierung, weil wir dadurch viel besser den Fokus halten konnten und unseren Status synchron halten.
Das unterscheidet sich nicht wesentlich von reinen Dev oder Ops-Teams, aber es ist teilweise eine sehr individuelle, personenbezogene Angelegenheit. Generell ist es wichtig, dass ein Team weder fachlich noch charakterlich zu homogen ist, weil sich dann zwar Positives, aber auch Negatives verstärkt und die Diversität fehlt. Auf der anderen Seite funktioniert ein Team auch nicht, wenn es zu divers ist. Daher gehört es zu den Aufgaben des Scrummasters, die Schnellen dazu zu bringen, die Langsameren abzuholen, die Konzentrierten dazu zu bewegen, die Zerstreuten einzusammeln, den Vorlauten zu verstehen zu geben, auch die Leisen zu Wort kommen zu lassen, usw. Am einfachsten ist das, wenn man ein Team-Klima hat, in dem man offen über Stärken und Schwächen reden kann und Kollegen um Unterstützung bitten kann, um die eigenen Schwächen auszugleichen. Im Pairing kann man dann sehr gute Lösungen finden. Ich glaube, es war aber auch einfach so, dass wir alle wirklich Bock hatten, miteinander zu arbeiten!
Selbstreflexion, zurücktreten und uns selbst, das Projekt, bzw. die Situation aus der Entfernung betrachten - auch das funktioniert nur so gut wie die Offenheit und Transparenz im Team ist. Was zählt, ist, sich als Team immer wieder darauf zu besinnen, dass Entscheidungen bewusst getroffen werden und wir uns nicht im Strom eines Arbeitsflusses einfach irgendwohin verrennen: Was ist für uns und unser Projekt die Entscheidung, die uns unserem Ziel näher bringt? Daran zu erinnern, war eine meiner Aufgaben als ScrumMasterin.
Habt ihr bereits ähnliche Erfahrungen gemacht oder musstet ihr bereits anderen Herausforderungen entgegentreten? Lass es mich in einem Kommentar wissen.
