Kolumne: DevOps Stories

Nichts als Experimente: Wie agile Change-Prozesse funktionieren (können)

Konstantin Diener

© SuS_Media

Lukas hat sich mit seinem alten Studienkollegen Arne getroffen. Wie früher in ihrer Studenten-WG haben sie schon eine ganze Zeit die Spielkonsole traktiert. Jetzt machen sie eine Pause, weil der Pizzalieferant gerade ihr Abendessen gebracht hat.

DevOps Stories: Wie agile Change-Prozesse funktionieren (können)

Lukas: „Das war richtig cool, mal wieder in Ruhe gegen dich Konsole zu zocken!“

Arne: „Ja, finde ich auch. Das machen wir eigentlich viel zu selten.“

Lukas: „Stimmt! Aber als Studenten hatten wir auch noch mehr Zeit.“

Arne: „Auf jeden Fall! Wenn ich nur dran denke, was uns nächste Woche so alles bevorsteht …“

Lukas: „Du hast lange nichts von deiner Arbeit erzählt, Arne.“

Arne: „Weißt du, ich komme mir ab und zu vor wie in einem Jump ’n’ Run. Mit dem Unterschied, dass die Dinge, die dir helfen sollen, dich meist eher behindern.“

Lukas: „Das verstehe ich nicht.“

Arne: „Unser CTO und das Culture-Team haben so viele neue Sachen eingeführt, dass ich manchmal den Überblick verliere. Irgendwie weiß ich auch nicht mehr, wann ich noch Softwareentwicklung machen soll.“

Lukas: „Hast du ein Beispiel?“

Arne: „Unser CTO war auf einer Konferenz. Danach meinte er, Betrieb und Entwicklung müssten enger zusammenarbeiten. Jetzt haben wir seit zwei Wochen die Jungs vom Betrieb bei uns sitzen – und können nichts miteinander anfangen.“

Lukas: „Komisch, die Zusammenarbeit mit den Ops-Jungs funktioniert bei uns super. Was möchte der CTO denn mit der Umstellung erreichen?“

Arne: „Keine Ahnung. Genauso wie sich das Culture Team ausgedacht hat, dass wir jetzt wie bei Spotify in Chapters und Gilden zusammenarbeiten sollen …“

Lukas: „Was ist das?“

Arne: „In Chapters sind zum Beispiel alle Frontend-Entwickler zusammengefasst. Ich bin in einem Chapter für Backend-Entwickler. Ich habe aber keine Ahnung, was ich da soll!“

Lukas: „Das klingt wie unsere Communities of Practice.“

Arne: „Hat die bei euch auch das Culture-Team aufgesetzt?“

Lukas: „Nein. Die haben wir gegründet, weil wir die übrigen Backend-Entwickler kennen, uns gegenseitig helfen und gemeinsame Standards schaffen wollten.“

Arne: „Das klingt gar nicht so blöd. Aber ich sitze doch sowieso mit den anderen Backend-Entwicklern in derselben Abteilung.“

Lukas: „Ach so, bei uns sind die auf verschiedene Produktteams verteilt. Wir nennen das cross-funktional.“

Arne: „Irgendwas mit cross-funktionalen Teams haben sich der CTO und das Culture-Team für das nächste Quartal vorgenommen – stand zumindest auf einer Folie, die sie uns letztens per Mail geschickt haben.“

Lukas: „Gibt es eine Veranstaltung, in der ihr diese Ideen mit dem Culture-Team und dem CTO diskutieren könnt?“

Arne: „Die Entwickler? Nein!“

Abb. 1: Lukas und Arne kommen über die Arbeit ins Gespräch

Abb. 1: Lukas und Arne kommen über die Arbeit ins Gespräch

Nur vermeintliche agile Best Practices zu kopieren, hilft in der Regel nicht

Agilität ist kein Nischenthema mehr. Immer mehr Firmen wollen zumindest einmal sehen, was es mit dieser Philosophie auf sich hat. Unternehmen wie Spotify haben es geschafft, agile Prinzipien auch in einer größeren Organisation zu etablieren [1], [2], [3].

Viele Firmen sehen solche Organisationsansätze – egal ob von Google, Spotify, Netflix oder anderen – als Best Practices an und versuchen, sie in ihren Organisationen nachzuahmen. Frei nach dem Motto: „Wenn das bei Spotify funktioniert, wird es auch hier funktionieren!“ Dabei wird oft vergessen, dass es das Spotify-Modell nicht gibt. Es ist eine Momentaufnahme, wie Spotify sich 2014/15 organisiert hat. Außerdem ist diese Organisationsform in einem bestimmten Kontext, einer bestimmten Branche und vor dem Hintergrund konkreter Probleme entstanden – und hat sich seitdem weiterentwickelt.

Arne beschreibt ähnliche Erfahrungen aus seiner Firma. Der CTO hat auf einer Konferenz ganz offensichtlich etwas darüber gehört, wie Teams und die Zusammenarbeit zwischen diesen Teams bei Spotify organisiert sind (Chapters und Gilden) und welche Vorteile DevOps-Teams haben können. Er scheint begeistert von diesen Ideen gewesen zu sein – immerhin hat er seiner Firma direkt ähnliche Konzepte verordnet. Da sie aus dem Kontext gerissen sind, kann in der Firma allerdings niemand etwas damit anfangen und sieht keinen besonderen Sinn in dieser Form von Cargo Cult.

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.

Welches Problem lösen wir eigentlich?

Kent Beck fasst es in einem seiner Tweets wie folgt zusammen: „Spotify didn’t implement the Spotify model by copying Spotify. Why do folks at other companies think they can implement the Spotify model by copying Spotify?”. Er möchte damit nicht sagen, dass Spotify bei der Evolution seiner Organisationstruktur keine Vorbilder hatte. Das Unternehmen hat nur kein bestehendes Modell eins zu eins kopiert. Es entwickelte und entwickelt ein Modell für sich, das seine jeweils aktuellen Probleme löst.

Lukas erkennt in den Chapters die Communities of Practice aus seiner eigenen Firma wieder und ist erstaunt, dass Arne diesem Konzept nichts abgewinnen kann. Der Unterschied ist, dass Lukas’ Firma erkannt hatte, dass sich mit der Einführung von cross-funktionalen Teams neue Probleme ergeben. Zum Beispiel, dass die Frontend-Entwickler aus den verschiedenen Teams einander nicht mehr bei Problemen helfen können, weil sie sich schlicht und ergreifend nicht kennen [4]. Jemand in der Organisation hatte davon gehört, dass Communities of Practice in diesem Fall helfen könnten. Deshalb haben Lukas und seine Kollegen es ausprobiert. In Arnes Firma gab es, salopp gesprochen, gar kein passendes Problem!

Veränderung hin zur agileren Organisation – meist klassischer Ablauf

Lukas’ Firma geht bei der Einführung neuer Organisationselemente oder Verfahren sehr problemorientiert vor – wie Spotify auch. Das Verfahren funktioniert etwa wie folgt:

  1. Welches sind die aktuell wichtigsten Probleme in unserer Organisation?
  2. Gibt es bestehende Ansätze, um diese Probleme beziehungsweise eins dieser Probleme zu lösen? Das Konzept der Communities of Practice oder Gilden wurde ebenfalls weder von Spotify noch von Lukas’ Firma erfunden.
  3. Wie könnte (basierend auf einem dieser bestehenden Ansätze) eine Veränderung an unserer Organisationsstruktur aussehen, die das Problem möglicherweise löst? Im Idealfall ist diese Änderung möglichst klein, damit wir sie möglichst einfach ausprobieren können.
  4. Wir setzen die Veränderung um und analysieren regelmäßig, ob sie die beabsichtigten Ergebnisse bringt, indem sie die identifizierten Probleme löst. Bleiben die gewünschten Ergebnisse ganz oder teilweise aus, überlegen wir, ob wir unsere Lösungsidee modifizieren oder ganz verwerfen sollten.
  5. Sind die aktuellen Probleme gelöst, entstehen neue und wir beginnen wieder bei Schritt 1.

Dieser Ansatz ähnelt nicht zufällig dem Vorgehen agiler Produktentwicklung: Das Produktteam stellt Hypothesen darüber auf, welches die aktuell dringendsten Kundenbedürfnisse und mögliche Lösungen dafür sind. Dann führt es das kleinstmögliche Experiment durch (zum Beispiel durch die Entwicklung eines neuen Produktfeatures) und misst, ob seine Hypothese zutrifft beziehungsweise die Problemlösung funktioniert.

Leider gibt es immer wieder Beispiele, bei denen die Einführung agiler Elemente wie in Arnes Firma auf der Organisationsebene passiert. Der agile Lern- und Entwicklungsprozess gerät in Vergessenheit und die organisatorischen Veränderungen entstehen am Reißbrett. Die Arbeit am Reißbrett ist dem Management und dem Culture-Team vorbehalten. Lukas fragt Arne, ob es eine Veranstaltung in der Firma gibt, in der Management, Culture-Team und die restlichen Mitarbeiter sich austauschen. Er ist gewohnt, Probleme in Retrospektiven zu identifizieren und kann sich deshalb nicht vorstellen, wie Management und Culture-Team auf andere Art von den wichtigsten Problemen erfahren sollten [5].

Veränderung in Form von Retrospektiven und Experimenten durchführen

Wie aber kann ein agiler Veränderungsprozess auf Unternehmensebene konkret aussehen?

In regelmäßigen Retrospektiven stellen das Team, die Abteilung oder die gesamte Organisation fest, was ihre aktuell dringendsten Probleme sind.

Für die wichtigsten drei Probleme stellen die Teilnehmer dieser Retrospektive Hypothesen bezüglich der Ursachen auf. Außerdem definieren sie (möglichst kleine, einfache) Experimente zu deren Lösung. Zu guter Letzt überlegen sie, wie man den Erfolg des Experiments messen könnte. All diese Informationen werden auf einer Experiment-Card zusammengefasst (Abb. 2).

Abb. 2: Experiment-Card

Abb. 2: Experiment-Card

Nun sammeln die Teilnehmer alle Experiment-Cards an einem zentralen Kanban-Board (Abb. 3) gesammelt. So kann die Organisation regelmäßig in Retrospektiven überprüfen, ob die Experimente erfolgreich sind oder nicht. Zu diesem Zweck existiert eine Spalte am Board, in der sich bereits umgesetzte Experimente befinden, deren Erfolg im Moment gemessen wird. Neben der regelmäßigen Überprüfung aller Maßnahmen hat die Visualisierung in Form eines Kanban-Boards einen weiteren Vorteil: Sie kann dabei helfen, dass sich die Organisation nicht zu viele Veränderungen gleichzeitig vornimmt (Stichwort: WIP-Limit).

Abb. 3: Company-Change-Board

Abb. 3: Company-Change-Board

Durch das Gespräch mit Lukas hat Arne erkannt, dass das Vorgehen in seiner Firma bislang wenig problemorientiert ist. Deshalb nimmt er bislang kaum Verbesserungen wahr. Er hat sich vorgenommen, in den nächsten Tagen mit dem Culture-Team über die Einführung regelmäßiger Retrospektiven und über Experimente zu sprechen.

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: