Kolumne

DevOps Stories: Das kann doch nicht jeder anders machen!

Konstantin Diener

Sollte man zu funktionalen Expertenteams zurückkehren? Aufgrund der vielen Vorteile der crossfunktionalen Produktteams möchte das keiner so richtig. Ideal wäre es, wenn man bei crossfunktionalen Teams bleiben könnte, ohne die Vorteile der Expertenteams ganz zu verlieren.

Jeden Monat starten in Lukas’ Firma neue Kollegen, und beim gemeinsamen Mittagessen in der großen Küche wird es langsam eng. Julia hat den letzten Platz an einem der Tische ergattert. Sie sitzt neben einer Kollegin, die sie vorher noch nicht gesehen hat (Abb. 1).

  • Julia: Hallo, ich heiße Julia. Ich glaube, wir haben uns noch gar nicht kennengelernt.“
  • Su: Hallo Julia, ich bin Su. Ich habe letzten Monat angefangen.“
  • Julia: Freut mich dich kennenzulernen, Su. In welchem Team bist du? Woran arbeitest du?
  • Su: Ich arbeite am Frontend von Bookery, der neuen eBook-Plattform.“
  • Julia: Cool, ich bin Frontend-Entwicklerin im MusicStore-Team. Was setzt ihr für eine Frontend-Technologie ein?
  • Su: Angular 2. Vorher habe ich bei einer Agentur gearbeitet. Da habe ich eher Erfahrungen mit React gesammelt. Im Moment knabbere ich an einem Problem mit Angular …
  • Julia: Echt? Ich habe relativ viel Erfahrung mit Angular. Vielleicht kann ich dir helfen.
  • Su: Cool! Gut, dass wir uns zufällig kennengelernt haben.
  • Julia: Ja, früher habe ich mit allen Frontend-Entwicklern in einem Team zusammengearbeitet. Da kannte ich alle. Heute nicht mehr!

In einer anderen Ecke der Küche sitzen Lukas und Christian mit Lars und Jerome zusammen. Vor der Umstellung auf crossfunktionale Produktteams haben die vier im Backend-Team zusammengearbeitet.

  • Lars: Hallo Christian, hi Lukas, wie läuft’s bei euch?
  • Lukas: Hallo ihr beiden. Wir schlagen uns gerade mit unserer Spring-Boot-Konfiguration herum.“
  • Jerome: Deswegen haben wir Spring Boot rausgeworfen und bauen unsere Services jetzt mit Dropwizard.“
  • Christian: Dropwizard? Haben wir nicht Spring Boot bei uns als Standard? Wieso nehmt ihr einfach was anderes?
  • Lars: Wir haben bei uns im Team einen Workshop gemacht und uns für Dropwizard entschieden. Von Standards weiß ich nichts!
  • Jerome: Vor zwei Wochen haben wir auch endlich den ollen Jenkins rausgeworfen und durch GitLab CI ersetzt.“
  • Christian: Ernsthaft? Wir bauen doch alle mit Jenkins!
  • Jerome: Nee, wir haben gestern mit den Jungs von VideoRadar gesprochen. Die nehmen Concourse.“
  • Lars: … und MediaPortal setzt Travis ein.“
  • Christian: Aber das kann doch nicht jeder anders machen!
Abb. 1: Julia und Su lernen sich zufällig beim Mittagessen kennen

Abb. 1: Julia und Su lernen sich zufällig beim Mittagessen kennen

Wissen in Communitys teilen und Alltagsprobleme lösen

Vor der Umstellung auf crossfunktionale Produktteams kannte Julia alle anderen Frontend-Entwickler, weil sie mit ihnen in einem Team zusammengearbeitet hat. Genauso erging es Lukas und Christian mit ihren Kollegen im Backend. Das Wissen der anderen Entwickler war für das Team einfach zugänglich und die Kollegen konnten sich bei Alltagsproblemen gegenseitig helfen. Sie arbeiteten mit denselben Programmiersprachen, Frameworks und Werkzeugen – sprachen sozusagen die gleiche Sprache.

Julia fällt auf, dass dieser Austausch zwischen den Frontend-Entwicklern nach der Umstellung auf crossfunktionale Produktteams langsam weggefallen ist. Neue Frontend-Entwickler lernt sie nicht mehr kennen, und zu den ehemaligen Teamkollegen verliert sie den Kontakt. Die neue Kollegin Su hat niemanden in der Firma, mit dem sie über Probleme und Lösungen sprechen kann, da sie die einzige Frontend-Entwicklerin in ihrem Team ist.

Sollte die Firma also doch zu funktionalen Expertenteams zurückkehren? Aufgrund der vielen Vorteile der crossfuntionalen Produktteams möchte das keiner so richtig. Ideal wäre es, wenn man bei crossfunktionalen Teams bleiben könnte, ohne die Vorteile der Expertenteams ganz zu verlieren. Insbesondere wenn es darum geht, Wissen zu teilen und die Kollegen zu kennen, die einem bei Problemen helfen können. Dieses Ziel lässt sich mit Communitys erreichen. In den Communitys treffen sich Gleichgesinnte, die sich für dasselbe Thema interessieren und Wissen austauschen. Nebenbei lernen die Mitarbeiter auch die Kollegen kennen, die ihnen behilflich sein können. Diese Kollegen können auch bei Technologieentscheidungen mit Rat und Tat behilflich sein. Communitys, die aus Menschen mit gleichen Interessen bestehen, werden als Communities of Interest bezeichnet [1]. Außerhalb einzelner Firmen sind diese Communitys heute schon oft in Form von User Groups, Meetups, Agile Mondays oder Webmontagen gängige Praxis.

DevOps Stories

„Agilität“, „Management 3.0“, „New Work“ oder „DevOps“ – all diese Bewegungen verändern die Art und Weise, wie Softwareentwicklung organisiert wird. Und wenn man ihren Denkmustern und Ideen konsequent folgt, beeinflussen sie stark die Kultur des Unternehmens. Über solche Kulturveränderungen berichtet Konstantin Diener (CTO von cosee) in dieser Kolumne. Doch wie lassen sich Erfahrungen zu Veränderungen der Unternehmenskultur transportieren? Er ist der Meinung, so wie die Menschheit seit Jahrtausenden Erfahrungen transportiert: durch Geschichten, den DevOps Stories.

Gemeinsame Standards über mehrere Teams schaffen

Im Gespräch zwischen Lukas und Christian sowie Lars und Jerome geht es um einen anderen Aspekt. Vor einiger Zeit wurde den Teams die Verantwortung für ihre Technologieentscheidungen übertragen. Diese Entscheidungen werden jetzt nicht mehr vom CTO oder Architekten getroffen, sondern ausschließlich von den Teams selbst. Damit diese Entscheidungen nicht chaotisch ablaufen, gibt es einen unternehmensweiten Leitfaden für Technologieentscheidungen.

Die Diskussion beim Mittagessen zeigt, dass diese Veränderungen in der Unternehmensorganisation dazu geführt haben, dass die Teams jetzt in einigen Bereichen unterschiedliche Technologien einsetzen. Lars und Jerome erzählen Lukas und Christian von drei anderen Teams – inklusive ihres eigenen –, die alle unterschiedliche Build- und Deployment-Technologien einsetzen (Jenkins, GitLab, Concourse und Travis CI). Christian zeigt daraufhin eine Reaktion, die auch oft beim Management einer Firma zu beobachten ist: Wenn jedes Team andere Technologien einsetzt, fallen die Synergieeffekte weg. Wird das fürs Unternehmen zum Problem? Sind gemeinsame Standards sinnvoll? Wer definiert diese Standards?

DevOpsCon Whitepaper 2018

Free: BRAND NEW DevOps Whitepaper 2018

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.

Wenn im Unternehmen die gemeinsamen Standards ein CTO oder ein Architekten definiert, befinden wir uns wieder in der Situation, die durch die Verlagerung der Technologieentscheidungen ins Team aufgelöst werden sollte. Die Standards müssen zwischen den Teams gemeinsam ausgehandelt werden. Dafür bieten sich ebenfalls Communitys an. Dort sitzen z. B. die Experten für Build-Tools zusammen und können sich überlegen, welche Aspekte sie standardisieren möchten und welche in den Teams verbleiben. Durch die Definition gemeinsamer Standards wird aus einer Community of Interest eine Community of Practice [1] (siehe Kasten). Solche Standards sind zum Beispiel die folgenden:

  • Welches Versionskontrollsystem wird verwendet?
  • Welche Build- und Deployment-Technologie wird verwendet?
  • Wie wird Code dokumentiert?
  • Wie erfolgt das Logging und Monitoring von Microservices?
  • Wie wird getestet?

Generell sollten die Communitys immer möglichst wenig gemeinsame Standards festlegen, andernfalls wird die Autonomie der einzelnen Teams wieder unnötig eingeschränkt.

Community of Interest vs. Community of Practice

Die Begriffe Community of Interest und Community of Practice werden gelegentlich synonym verwendet, obwohl die Ergebnisse der beiden Formen sich unterscheiden. Bei einer Community of Interest steht im Vordergrund, sich zu informieren bzw. Informationen zu einem gemeinsamen Interesse auszutauschen (Rollenspiele, asiatisches Essen …). Die Community erzeugt kein direktes Ergebnis. Die Mitglieder einer Community of Practice kümmern sich um ihr gemeinsames Thema und entwickeln es weiter. Als Ergebnis entstehen Handlungsweisen für die tägliche Arbeit [1].

Innovationen treiben und Neues ausprobieren

Lukas und Christian sind davon ausgegangen, dass die anderen Backend-Entwickler genau wie sie nach der Aufteilung auf crossfunktionale Teams bei Jenkins als Build- und Deployment-Werkzeug geblieben sind. Im Gespräch mit Lars und Jerome erfahren sie, dass das nicht der Fall ist. Mittlerweile sind in den verschiedenen Teams sogar vier verschiedene Lösungen im Einsatz. Die anderen Teams werden sich nicht einfach aus einer Laune heraus für eine andere Technologie entschieden haben. Sie haben sich am Leitfaden für Technologieentscheidungen orientiert und für ihren Bedarf das richtige Werkzeug ausgewählt. Vielleicht wäre dieses Werkzeug auch etwas für die anderen Teams oder für Lukas und Christian.

Communities of Practice dienen nicht nur der teamübergreifenden Standardisierung des Status quo. Sind haben ebenfalls zum Zweck, Innovationen in dem jeweiligen Thema voranzubringen (Abb. 2). So könnten alle Backend-Entwickler in ihrer Community ein Projekt starten, das eine neue Build- und Deployment-Self-Service-Plattform für das Unternehmen aufbaut.

Abb. 2: Die Aufgaben von Communities of Practice

Abb. 2: Die Aufgaben von Communities of Practice

Communitys sind freiwillig und müssen wertvoll bleiben

Communities of Practice basieren auf Freiwilligkeit. Die einzelnen Mitarbeiter investieren ihre Zeit für die Arbeit in einer Community. Deshalb müssen sie selbst sich immer sicher sein, dass diese Zeit für sie persönlich sinnvoll investiert ist, ihnen hilft und sie stattdessen nicht Sinnvolleres hätten tun können. Für das Unternehmen ist es genauso wichtig, dass die Communitys Focus on Value [1] als Ziel haben. Die Zeit, welche die Mitarbeiter in die Communityarbeit einbringen, geht schließlich von ihrer direkten Arbeit im Projekt oder am Produkt ab.

Julia und Su sowie die vier Backend-Entwickler Lukas, Christian, Lars und Jerome haben die Idee von Communities of Practice aufgegriffen. Seit einer Woche gibt es die beiden Communitys Frontend Engineering und Service Build & Deployment. Vielleicht werden sich weitere Kollegen anschließen und ebenfalls Communitys gründen.

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin 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. Twitter: @onkelkodi
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: