Suche
DevOps in der echten Welt - Teil 5

DevOps mal ganz praktisch: Cooperation, Initiative, Responsibility, Respect & Craftsmanship

Redaktion JAXenter

(c) Shutterstock / Artishok

In der Serie “DevOps mal ganz praktisch” geben Experten ihre Praxis-Erfahrungen bei der Umsetzung von DevOps-Prinzipien weiter. Heute: Konstantin Diener von cosee.

Im Gespräch mit JAXenter gibt Konstantin Diener Einblicke in die Umsetzung von DevOps-Prinzipien bei cosee.

Das Interview

DevOps in der Praxis: “Agilität muss vom Management vorgelebt werden, indem sich das gesamte Unternehmen ständig in Form von „Inspect & Adapt“ hinterfragt und verbessert.”

JAXenter: Beginnen wir einmal rein organisatorisch. Wie ist bei euch die Zusammenarbeit zwischen Devs und Ops organisiert?

Konstantin Diener: Wir verfolgen das Prinzip „You built it, you run it“ und haben eigentlich keine expliziten Ops-Mitarbeiter.

JAXenter: Wie ist üblicherweise die Team-Struktur in eurer IT? 

Konstantin Diener: Da wir zu über 80 Prozent aus IT bestehen, kann die Frage bei uns lauten, wie generell ein Produktteam bei uns aussieht ;-). Unsere Teams sind in der Regel zwischen fünf und sieben Personen groß. Wenn wir ein neues oder spezielleres Thema beginnen, sind die Teams manchmal zu Beginn erst kleiner (zwei bis drei Personen). In einem Team sind alle Rollen vertreten, die für die Arbeit am Produkt notwendig sind. Das sind in der Mehrzahl Software-Entwickler (Frontend/Backend/Mobile), aber auch UX Designer. Demnächst wird in einem unserer Teams auch eine Kollegin mit Marketing-Schwerpunkt eingebunden sein. Da wir eine relativ junge Belegschaft haben, sind die Mitarbeiter i.d.R. zwischen Anfang 20 und Anfang 30. In allen Teams sind verschiedene Alters- und Erfahrungsstufen relativ gleichmäßig verteilt. Im Moment haben wir in der Hauptsache männliche Mitarbeiter. An dieser Stelle tut sich aber gerade etwas …

JAXenter: Wie autonom können diese Teams agieren?

Konstantin Diener: Die Teams treffen sämtliche Technologieentscheidungen autark. Haben die Entscheidungen kaufmännische Auswirkungen, wie Lizenzkosten oder stark steigende laufende Kosten, stimmen die Teams die Entscheidung mit dem Kunden (externe Produkte) oder mit dem Product Owner ab (interne Produkte). Bei internen Produkten werden fachliche Produktentscheidungen, wie die Ziele, ebenfalls mit dem Product Owner gemeinsam entwickelt. Die Ergebnisse werden in Retrospektiven bewertet.
Wir haben vor einigen Monaten festgestellt, dass die Teams das Gefühl hatten, manche Dinge müssten möglicherweise einheitlich in allen Teams geregelt werden, wie das Deployment, Craftsmanship oder Testvorgehen. Diese Punkte werden mittlerweile von den Teams in verschiedenen Communities of Practice ausgehandelt, die ohne Management-Beteiligung stattfinden.

JAXenter: Bei DevOps ist auch immer von „Unternehmenskultur“ die Rede. Das ist sicherlich kein leicht zu fassender Begriff. Würdest du sagen, bei euch gibt es so etwas wie eine einheitliche Kultur – oder vielleicht mehrere Kulturen? 

Konstantin Diener: Sicherlich hat jedes unserer Teams eine eigene Kultur, die aber immer so etwas wie ein „Dialekt“ der Firmenkultur ist. Wir haben vor einiger Zeit als gesamtes Team erarbeitet, welche Werte uns für unsere Arbeit wichtig sind: Cooperation, Initiative, Responsibility, Respect & Craftsmanship. Was diese Werte konkret in der Praxis bedeutet, loten wir immer wieder in Retrospektiven oder in den Communities of Practice aus. Außerdem interpretiert jedes Team diese Werte leicht anders und dokumentiert sein Verständnis in einem Teamvertrag. Der Wert, der uns allen am wichtigsten ist, ist aber, dass wir Spaß bei der Arbeit haben. Das darf bei allen Definitionen, Regeln, Werten und Verträgen nie vergessen werden ;-).

JAXenter: Irgendwie geht es bei DevOps ja um Dinge wie den Geist der Zusammenarbeit, Experimentalkultur, Agilität, Mitarbeiterzufriedenheit. Was kann ein Unternehmen tun, um diese Dinge zu fördern?

Konstantin Diener: Behandelt eure Mitarbeiter wie erwachsene Menschen, schenkt ihnen Vertrauen und Raum, um sich zu entfalten, eigene Entscheidungen zu treffen und auch Fehler zu machen! Das ist aus meiner Sicht die wichtigste Regel, um Zufriedenheit und Experimentalkultur zu etablieren. Agilität muss vom Management vorgelebt werden, indem sich das gesamte Unternehmen ständig in Form von „Inspect & Adapt“ hinterfragt und durch Feedback-Schleifen verbessert. Diese Verbesserungen lassen sich gut in Form von Prozessexperimenten durchführen.

Rethink-IT-Survey-300x180DevOps – Wie sieht es bei Euch aus?
In unserer großen Umfrage zur DevOps-Kultur habt Ihr die Gelegenheit klarzustellen, ob und wie DevOps in euren Unternehmen umgesetzt wird. Macht mit!

Umfrage: Rethink IT

Bitte vervollständige die folgenden Sätze!

DevOps-Erfahrungen aus meiner Praxis

Meiner Erfahrung nach arbeiten Devs und Ops am besten zusammen, wenn …

… sie Probleme und Erfolge teilen und dieselben Ziele (Produkterfolg) haben.

Das größte Hindernis für DevOps ist meiner Erfahrung nach …

… ein durch das Management kultiviertes Silo-Denken, insbesondere indem beide Gruppen unterschiedliche/diametrale Ziele haben.

Was die Mitarbeiterzufriedenheit am meisten fördert, ist …

…, wenn sie IHR Produkt gestalten, das Management ihnen vertraut und sie arbeiten lässt.

Der Vorteil autonom arbeitender Teams liegt darin, dass …

… die relevanten technischen Entscheidungen von denen getroffen werden, die mit den Auswirkungen auch jeden Tag leben müssen. Das führt zu besseren, weil „informierteren“ Entscheidungen.

Wichtig für eine positive Unternehmenskultur ist, …

… dass es auf allen Ebenen Feedback-Schleifen gibt, beispielsweise in Form von Retrospektiven, um Probleme aufzudecken und zu lösen, so lange sie klein sind.

dienerKonstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software.

.

Unsere Experten-Tipps im Überblick

Geschrieben von
Kommentare

Schreibe einen Kommentar

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