Flexibilität, verteilte Führungsverantwortung und schlanke Strukturen: Das Netz ist voller Informationen zum agilen Arbeiten. Dabei werden häufig Erkenntnisse aus dem Umfeld des Software-Engineerings geteilt.

Wenige Erfahrungswerte gibt es dagegen aus dem „klassischen“ IT-Operations. Doch warum eigentlich? Auch hier sind Wasserfall-, V-Modell-Projekte und dergleichen nicht mehr das alleinige Credo. Es ist umso wichtiger, enger und wertsteigernder mit agilen Engineering Teams zu interagieren.

Wir möchten Euch einladen an unseren Erfahrungen teilzuhaben. Begleitet uns auf dem Weg unserer IT-Operations-Teams hin zu mehr Agilität und Teamwork. In unserem Digital Blog erfahrt ihr, was uns vorangebracht hat und welche Maßnahmen bei uns keine Wirkung zeigten.

Es ist unser Erfahrungsbericht zur Reise des Clans Application Technology. Noch stehen wir ganz am Anfang des Weges.

Vom IT-Betrieb zum agilen Projektmanagement: Wo kommen wir her?

Wir kommen aus einem IT-Betrieb mit funktional organisierten Teams. Dieses Modell bündelt gleichartige Fähigkeiten und Fertigkeiten in einzelnen Einheiten und ermöglicht so eine eingehende Spezialisierung im jeweiligen Fachgebiet (vgl. T-Shaped vs I-Shaped). Der Fokus auf Spezialwissen fördert unweigerlich Silos und Abhängigkeiten zwischen diesen.

Das folgende Organigramm zeigt unseren funktional aufgestellten Bereich vor der Reorganisation.

Ihre Arbeit organisierten unsere Teams über das zentrale Service-Managementsystem und zusätzlichen Kanban Boards. Dabei pflegte jedes Teammitglied überwiegend seine eigenen Todos. Wir sahen fachspezifische Zusammenarbeit innerhalb des Teams, stießen bei Abhängigkeiten/ Zulieferungen von anderen Teams jedoch schnell an die vorherrschenden Außengrenzen. Anderer Fokus, andere Priorisierungen – all das waren Faktoren, die echte Zusammenarbeit erschwerten.

Auch unsere Interaktionen mit den Software Engineering Teams beschränkten sich überwiegend auf personenspezifischen Austausch. Oft nach persönlichen Präferenzen („Nasenfaktor“) und auf Zuruf („Hey Joe“), jedoch mit wenig Systematik. Es gab ein „wir“ und „die“.

Zusammenarbeit ungleich Ticketing: Wie wir unterschiedliche Arbeitskulturen zusammenführen

Es ist unser erklärtes Ziel, unsere IT-Operations und Software Engineering Teams kulturell zusammenzubringen, dabei alte Verhaltensweisen zwischen Operations und Engineering aufzubrechen und bisherige Grenzen zu überwinden.

Was bedeutet das?

• Wir fördern die Zusammenarbeit,
• erhöhen so die Wirksamkeit unserer Arbeit
• und verbessern den Wertstrom.

Ein wichtiger Schritt für die Erreichung dieser Ziele ist, dass unsere Teams mehr Eigenverantwortung übernehmen. Ebenso relevant ist Transparenz bei allen Arbeitsschritten und der konsequente Fokus auf Mehrwert, der am Ende messbar ist.

Insbesondere, in dem wir uns gemeinsame Ziele setzen und Erfolge gemeinsam erreichen, fördern wir die Kollaboration und so letztendlich das Zusammenwachsen der Kulturen über alle Teams hinweg. „Über den Zaun werfen“ war gestern.

Was haben wir dazu strukturell geändert?

• Die Bereiche Digital Products (Software Engineering) und IT-Infrastructure (IT-Operations) sind jetzt „OneTeam“: Digital Products & Technology („DPT“)
  • Unsere Abteilungen Application Technology und Platform Technology werden innerhalb DPT zu einer Abteilung (Clan) Application Technology verschmolzen. Damit ist der gesamte Plattformbetrieb in einem Bereich gebündelt.
  • Aus den zwei Teams Linux Platform und Application Services (DevOps) wird das Squad DevOps Platform geformt.
  • Die Folge: Weniger Schnittstellen und ein gemeinsamer Aufbruch in ein neues Technologie-Zeitalter.
• Eine Doppelspitze teilt sich die Verantwortung für den Clan Application Technology. Die gemeinsame Führung stärkt die Team-Arbeit.

Auf dem Weg zum agilen Arbeiten: Was wir bisher gelernt haben

• Ausarbeitung unserer Clan sowie Squad Visionen und Missionen im Zug der Reorganisation synchronisiert die gemeinsame Ausrichtung, die Planung und unser Handeln
• Wir haben uns in vielen agilen Spritzen versucht (z.B. Daily Stand-Up, anlassbezogene Retrospektiven)
• Mit unserem agile Coach konnten wir unsere ersten Ansätze verfeinern und nachhaltig umsetzen.
• Erste Gehversuche im DevOps probierten wir mit einem sogenannten Flying DevOps Team: DevOps Engineers werden nach Bedarf in Software Engineering Squads entsendet
• Kanban ist für die Arbeitsweise in Operations-Teams gut geeignet und hilft uns, zu fokussieren und Kräfte zu bündeln. Hier sind wir auf einem guten Weg die Methodik in unseren Teams zu etablieren.
• Das regelmäßige Format „Retrospektive“ hilft uns, aktuelle Herausforderungen anzusprechen und aktiv mit dem Team zu verfolgen. Stichwort: kontinuierlicher Verbesserungsprozess
• Die Clan Leads binden das Team aktiv in Entscheidungsprozesse ein.  Formate wie Delegation Poker helfen bei der Klärung der Erwartungshaltung zwischen Leads und Team.
• Multiplikatoren schulen wir in agile Project Management und SCRUM. Dies fördert Akzeptanz für Agile Coaches und neue Methoden, ist förderlich für deren Umsetzung und strahlt auf die übrige Mannschaft aus
• Operations sind beim „Admin of the Day“ gebündelt, um planbare Aufgaben des Kanbans von unvorhersehbarer Arbeit (Incidents, „Hey Joe“) zu trennen. Hierdurch wird dem restlichen Team der Rücken freigehalten

Im nächsten Artikel wollen wir mit Euch unsere ersten Erfahrungen, Haken und Ösen teilen. Bis dahin würde uns interessieren, welche Erfahrungen Ihr gemacht habt. Seid Ihr schon agil? Oder auf dem Weg dahin? Vielleicht sogar wieder weg vom agilen Ansatz?

Wir freuen uns auf Euer Feedback!

Stay tuned!

Willi, Olli und Normann