Kolumne

DevOps Stories: Das haben wir entschieden?

Konstantin Diener

Entscheidungen im Team zu treffen ist komplizierter als es auf den ersten Blick oft aussieht, denn es lauern einsame Wölfe, Technologieverliebte, zu viele Köche und Schatten-CTOs. Auch hier helfen klare Regeln, die gemeinsam aufgestellt und eingehalten werden.

Lukas arbeitet seit einigen Monaten mit seinen Kollegen in einem crossfunktionalen Produktteam. Nach anfänglichen Schwierigkeiten hat das Team die Zusammenarbeit in einem Teamvertrag geregelt. Seitdem können die Kollegen immer flüssiger zusammenarbeiten. Im Teamvertrag ist unter anderem festgelegt, dass das Team wichtige Entscheidungen immer gemeinsam trifft.

Die ersten Versionen des Produkts von Lukas’ Team hatten durchschlagenden Erfolg. Deshalb hat der Kunde große Pläne für die nächsten zwölf Monate. Außerdem wurde das Team mit Martin um einen weiteren Backend-Entwickler verstärkt. Ruben unterstützt das Team als Scrum Master. Martin hat im Stand-up angekündigt, dass er heute mit einem Prototyp für die MongoDB-Persistenz beginnen wird. Daraus entwickelt sich eine Diskussion (Abb. 1):

Christian: „MongoDB ist deine bevorzugte Lösung! Wann haben wir denn entschieden, dass wir MongoDB für die Persistenz einsetzen wollen?“

Martin: „Letzte Woche Dienstag.“

Christian: „Das war mir nicht klar. Ich dachte, wir sprechen einfach nur über ein paar Themen.“

Lukas: „Mir war das auch nicht klar. Ich wusste auch nicht, was die Optionen sind … und die Vor- und Nachteile.“

Julia: „Ich hatte Dienstag Urlaub. Jörg ist zwei Wochen weg! Solche Entscheidungen wollten wir doch alle gemeinsam treffen, oder? Außerdem finde ich es wichtig, dass wir Magnus mit dazunehmen!“

Lukas: „Du hast Recht. Bei einer Entscheidung hättest du dabei sein sollen.“

Christian: „Wir wussten ja aber gar nicht, dass wir etwas entscheiden. Wie hätten wir da wissen sollen, dass Julia und Jörg uns dazu fehlen?“

Lukas: „Wieso willst du Magnus dazunehmen, Julia, der gehört doch gar nicht zum Team?“

Julia: „Ja, aber er hat die meisten Erfahrungen mit NoSQL-Datenbanken – auch was den Betrieb in der Cloud angeht. Außerdem stimmen wir doch alle Technologieentscheidungen immer mit ihm ab.“

Martin: „Er hat auf jeden Fall die meisten Erfahrungen und kann uns gerne mit Infos versorgen. Ich möchte aber nicht, dass er mitentscheidet.“

Lukas: „Aber findest du es nicht schwierig, dass keiner von uns Ahnung von MongoDB hat?“

Christian: „Wir müssen das Ding dann schließlich warten und betreiben. Gibt es einen Mongo as a Service oder müssen wir das selbst machen? Was kostet uns der Spaß monatlich?“

Martin: „Keine Ahnung! Damit habe ich mich noch nicht beschäftigt …“

Ruben: „Lasst uns in unserer Retrospektive morgen noch einmal den Ablauf der Technologieentscheidung unter die Lupe nehmen.“

Abb. 1: Das Team diskutiert den Einsatz einer NoSQL-Datenbank

Welche Probleme gibt es mit Technologieentscheidungen im Team?

So oder in einer ähnlichen Form wird mancher Entwickler solche Diskussionen auch schon erlebt haben. Oft trifft ein einzelner Entwickler alleine eine Technologieentscheidung, ohne mit den anderen im Team Rücksprache zu halten. Dieses Verhalten muss nicht unbedingt absichtlich passieren. Vielleicht findet der Entwickler die Entscheidung auch zu profan, um sie zu diskutieren. Diese Ein-Mann-Entscheider werden auch einsamer Wolf genannt. Zusammen mit dem einsamen Wolf tritt oft das Muster „Bring your own pet technology“ auf. Entwickler setzen oft stillschweigend die Tools, Sprachen oder Frameworks ein, die ihnen am meisten liegen. Auch Christian hat Martin im Daily Stand-up unterstellt, dass er einfach nur seine Lieblingstechnologie einsetzen möchte.

Wenn dann der einsame Wolf seine Lieblingstechnologie im Softwareprojekt platziert hat und im Urlaub oder krank ist, schlägt just in diesem Moment Murphys Gesetz zu. Es treten Fehler auf – meist im Produktivsystem. Die anderen Teammitglieder kennen sich mit dieser Technologie nicht aus und können die Fehler im Extremfall nicht beheben. Diesen Punkt hatte offensichtlich auch Martin nicht bedacht. Da sich seine Kollegen nicht mit MongoDB auskennen, müsste er immer für Problembehebungen zur Verfügung stehen. Wenn sich das Team gemeinsam für eine neue Technologie entscheidet, kann es auch die Einarbeitung entsprechend planen.

Aber nicht nur ein einsamer Wolf ist ein Problem, auch zu viele Köche verderben den Brei. Noch vor ein paar Monaten wollten alle in der Firma bei jeder Technologieentscheidung dabei sein. Das hat zu keinen sinnvollen Ergebnissen geführt. Jeder hatte eine Meinung und es wurde endlos diskutiert. Bei solchen Diskussionen kann es schnell dazu kommen, dass jeder der Beteiligten während der Diskussion ständig neu Kriterien findet, die für seine bevorzugte Lösung sprechen. Diese Gespräche verlaufen nicht immer sachlich. Bisweilen sprechen sich die Entwickler sogar gegenseitig die Kompetenz ab. Nur wer direkt von der Entscheidung betroffen ist, sollte ein Mitspracherecht an ihr haben.

Das Gegenteil zu den vielen Köchen ist der ungehörte Experte. Das Team hat keine ausreichenden Erfahrungen für eine sinnvolle Technologieentscheidung, und obwohl es in anderen Teams entsprechende Erfahrungen gäbe, spricht niemand mit diesen Experten. Hier ist es wichtig, den Blick über den eigenen Teamtellerrand zu bewahren und zu wissen oder nachzufragen, womit sich andere Teams bereits beschäftigt haben.

Ebenfalls eine Gefahr sind unbewusste Entscheidungen. Martin war der Meinung, dass das Team im Dienstagstermin vor einer Woche nicht nur nett über Technologien geplaudert hat. Aus seiner Sicht wurde MongoDB als Kandidat für den Prototyp ausgewählt. Seine Teamkollegen sind da anderer Meinung. Eine solche Situation kann ungewollt eintreten oder aber bewusst provoziert werden, um dem Team eine Entscheidung unterzujubeln. Wann also eine Entscheidung getroffen und nicht nur diskutiert wird, sollte klar kommuniziert werden.

Julia möchte die Entscheidung gerne zusätzlich mit Magnus abstimmen. Sie ist der Meinung, dass das immer so gemacht wird. Dieses Verhalten lässt darauf schließen, dass die Teams nicht vollständig autonom in ihren Entscheidungen sind. Offiziell müssen sie sich ihre Entscheidungen nicht freigeben lassen. Magnus nimmt aber eine inoffizielle Freigabe- oder Entscheiderrolle ein. Er ist ein Schatten-CTO. Als Experte darf eine solche Person gerne zur Diskussion eingeladen werden. Mit entscheiden sollte er aber nicht.

Und zu guter Letzt hat Martin wie so oft bei Technologieentscheidungen die Betriebsaspekte und die möglichen laufenden Kosten der Entscheidung nicht bedacht. Diese Aspekte sollten aber fester Teil jeder Technologieentscheidung sein.

Alle in Lukas’ Firma sind von den Vorteilen von Technologieentscheidungen in den Teams überzeugt und wollen die Entscheidungen nicht wieder zentralisieren, nur weil ein paar Probleme auftreten. Also müssen ein paar neue Regeln her.

DevOps Docker Camp 2017

Das neue DevOps Docker Camp – mit Erkan Yanar

Lernen Sie die Konzepte von Docker und die darauf aufbauende Infrastrukturen umfassend kennen. Bauen Sie Schritt für Schritt eine eigene Infrastruktur für und mit Docker auf!

Drei-Personen-Regel schützt vor Murphys Gesetz

Dem CTO ist es wichtig, eine Umgebung für kontinuierliche technische Innovation im Unternehmen zu schaffen, z. B. durch den Einsatz moderner Programmiersprachen. Andererseits dürfen die Lösungen auch nicht von Einzelpersonen abhängig sein. Als Lösung hat er die Drei-Personen-Regel festgelegt. Zu jeder Programmiersprache muss es im Unternehmen – idealerweise im Team – mindestens drei Personen geben, die diese Sprache gut genug beherrschen, um Bugfixes oder kleine Features entwickeln zu können (Abb. 2). Möchte ein Entwickler eine neue Programmiersprache einsetzen, ist er dafür verantwortlich, zwei weitere Kollegen zu überzeugen. Später müssen diese drei immer sicherstellen, dass es Ersatz gibt, wenn beispielsweise einer die Firma verlässt.

Abb. 2: Zu jeder Programmiersprache muss es mindestens drei Supporter geben

Ein Leitfaden für Technologieentscheidungen

Lukas’ Team hat in einer Retrospektive Leitlinien für die Technologieauswahl erarbeitet und in fünf Fragen gegliedert:

  1. Was entschieden wir? Entscheidungen werden in Zukunft explizit bekannt gegeben: „Ich habe euch für Dienstag zu einem Termin eingeladen. Ich möchte mit euch gemeinsam entscheiden, welche Datenbank wir einsetzen.“
  2. Nach welchen Kriterien entscheiden wir? Das Team legt gemeinsam Kriterien für die Technologieauswahl fest. Dazu gehören Betriebsaspekte, Kosten, fachliche Anforderungen, Security und Performance. Lukas’ Team möchte auch beurteilen, wie viel Erfahrung das Team mit der jeweiligen Technologie hat und wie umfangreich die notwendige Einarbeitung wäre. Damit die Festlegung der Kriterien konstruktiv bleibt, wollen sich die Kollegen bei ihren Terminen an der Prime Directive für Retrospektiven orientieren.
  3. Was sind die Optionen? Welche Frameworks, Technologien oder Programmiersprachen wollen wir als Team bei der Auswahl berücksichtigen? Hier ist jedes Teammitglied eingeladen, seine Lieblingstechnologie vorzuschlagen.
  4. Wer gehört zum Team? Die Teams in der Firma arbeiten nach dem DevOps-Prinzip „You build it, you run it“. Daraus abgeleitet hat der CTO die folgende Leitlinie definiert: „Es entscheidet, wer nachts aufsteht, wenn es kaputtgeht“. Für den konkreten Fall sind das die Entwickler aus Lukas’ Team. Zu einem Entscheidungstermin müssen alle anwesend sein. In diesem Zuge hat das Team beschlossen, dass Magnus keine Stimme bei der Technologieentscheidung hat.
  5. Wer sind maßgebliche Experten? Dass Magnus keine Stimme bei der konkreten Auswahl hat, heißt aber nicht, dass das Team ihn nicht als Experten einbinden sollte. Lukas und seine Kollegen beschließen, dass sie bei jeder Technologieentscheidung nach Kollegen im Unternehmen suchen, die mit dieser oder einer ähnlichen Technologie bereits Erfahrung haben. Zur Vorbereitung der Entscheidung holen sie von den entsprechenden Kollegen Ratschläge ein und lassen diese in ihre Entscheidung einfließen.

Damit sie selbst und die anderen Teams die Entscheidung und deren Entstehung später sinnvoll nachvollziehen können, haben sich die vier Entwickler entschieden, sie im Wiki zu dokumentieren. Die Struktur orientiert sich am Kapitel „Entwurfsentscheidungen“ aus dem arc42-Template. Wie Lukas’ Team die maßgeblichen Experten ausfindig macht und wie Technologieentscheidungen teamübergreifend organisiert werden können, wird Thema einer der nächsten Folgen der DevOps Stories sein.

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

Schreibe einen Kommentar

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