Die agile Software-Entwicklung forciert selbst-organisierte, autonome Teams. Diese Organisationsform steht im Widerspruch zu den klassischen Methoden für Technologieentscheidungen: Entscheidet ein CTO oder ein außenstehender Architekt über die eingesetzten Programmiersprachen, Frameworks und Werkzeuge, werden die Autonomie und Selbstorganisation der Entwicklungsteams erheblich eingeschränkt. Wie lassen sich Technologieentscheidungen ohne diese Einschränkungen organisieren? Welche typischen Probleme treten dabei auf? Wie schaffen mehrere Teams gemeinsame Standards?
Die vier Leitsätze des agilen Manifests sind weithin bekannt (z.B. „Individuals and interactions over processes and tools“). Darüber hinaus enthält das Manifest noch zwölf Prinzipien [1], die oft weniger bekannt sind. Das zwölfte dieser Prinzipien lautet „The best architectures, requirements, and designs emerge from self-organizing teams”.
Die meisten agilen Teams organisieren ihre Arbeit nach Scrum. Auch der Scrum Guide [2] hebt den Aspekt „Selbstorganisation“ für das Entwicklungs-Team hervor („They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality“).
Die Autoren des Scrum Guides legen so viel Wert auf die Selbstorganisation und Autonomie des Teams, damit es seiner wichtigsten Aufgabe nachgehen kann: der kontinuierlichen Lieferung von lauffähigen Software-Produktinkrementen. Jede externe Abhängigkeit führt in der Regel zu Behinderungen und Verzögerungen. Warum ist das so? Im Gegensatz zu den Entwicklern des Scrum-Teams fehlen dem externen Entscheider der Kontext und die für die Entscheidung notwendigen Informationen (siehe Abb. 1). Das Team muss den Entscheider also erst mit den passenden Informationen versorgen, damit dieser eine Entscheidung treffen kann. Es lässt sich leicht ersehen, dass dies ein sehr aufwändiger Prozess zur Entscheidungsfindung ist – vor allem, weil das Entwicklungsteam selbst alle notwendigen Informationen bereits hat. Fällt der Entscheider aus (Krankheit) oder ist überlastet, führt das automatisch zur Blockade des Entwicklungsteams. In Zeiten von robustem bzw. resilientem Service Design erscheint dieser Prozess sehr anachronistisch [3].
Abb. 1: Kreislauf für Technologieentscheidungen durch einen externen Entscheider
Der Scrum Guide hebt weiter unten hervor, dass das Entwicklungs-Team gemeinsam die Verantwortung für das Produkt und den Code trägt. Es kann die Verantwortung aber nur übernehmen, wenn es auch die maßgeblichen Entscheidungen trifft. Werner Vogels, der CTO von Amazon, hat diese Verantwortung treffend in dem Satz „You build it, you run it“ [4] zusammengefasst. Das Entwicklungs-Team wird die Verantwortung von sich weisen, wenn es die Technologieentscheidungen anderer ausbaden muss.
Was sind die häufigsten Probleme im Hinblick auf Technologieentscheidungen?
Es gibt also gute Gründe, warum Entwicklungs-Teams selbst für ihre Technologieentscheidungen verantwortlich sein sollten. Immer mehr Organisationen geben aus diesem Grund zentrale Entscheider auf und übergeben die Verantwortung an die Entwicklungs-Teams.
Wenn es vorher jemanden gab, der für die Technologieentscheidungen verantwortlich war, entsteht zunächst einmal ein Vakuum. Nicht selten versuchen einzelne Entwickler, dieses Vakuum zu füllen, indem sie auf eigene Faust Technologieentscheidungen treffen, ohne mit dem Team Rücksprache zu halten. Ich bezeichne dieses Muster gerne als einsamen Wolf. Dabei handeln die einsamen Wölfe noch nicht einmal unbedingt böswillig. Bei ihnen ist angekommen, dass die Entscheidungen jetzt im Team stattfinden, obwohl gemeint war, dass das Team jetzt gemeinsam die Entscheidungen trifft. Ein anderer Grund für das Verhalten des einsamen Wolfes kann sein, dass er die Entscheidung als zu profan betrachtet, als dass sie mit den anderen gemeinsam getroffen werden müsste.
Mit dem Muster des einsamen Wolfes geht meist außerdem einher, dass jeder Entwickler beginnt, seine Lieblingstechnologien einzusetzen („Bring your own pet technology“). Alle Sprachen, Frameworks und Werkzeuge, mit denen man gerade zu Hause in seinen Bastelprojekten experimentiert oder über die man einen interessanten Blog Post gelesen hat, werden unreflektiert ins Unternehmen getragen. Dadurch entsteht mit der Zeit ein unüberschaubarer und schwer wartbarer Technologiezoo.
Dieser Zoo wird zusammen mit Murphy’s Law richtig gefährlich: Im Produktivsystem tritt ein Fehler auf – und just in diesem Moment ist der Entwickler, der die Technologie eingeführt hat, im Urlaub, krank oder hat das Unternehmen verlassen. Die übrigen Entwickler sprechen die altbekannten Worte: „Damit kennen wir uns nicht aus!“ Das entspricht vermutlich sogar der Wahrheit und ist kein purer Abwehrreflex.
Wenn Entwicklungs-Teams Technologieentscheidungen in die eigene Hand nehmen, kommt es aber oft nicht nur zu Alleingängen. Es passiert immer wieder, dass die Technologieoptionen in großen Gruppen diskutiert werden. Diese Diskussionen, bei denen jeder in der Firma eine Meinung hat, dauern meist sehr lange und sind nicht selten derart verfahren, dass es zu keiner sinnvollen Lösung kommt. Sie sind nicht immer sachlich und oft wird dort sehr emotional diskutiert.
Nicht selten sehnen sich die Team-Mitglieder deshalb bald wieder nach jemandem, der bei Technologieentscheidungen die Richtung vorgibt und so entstehen implizite Technologieentscheider („Schatten-CTOs“). Diese Personen haben offiziell keine andere Stellung als die übrigen Entwickler, möchten aber bei allen Entscheidungen eingebunden werden, getreu dem Motto: „Hättet ihr mich mal vorher gefragt. Jetzt seht selbst, wie ihr mit dem Problem fertig werdet!“ Dieses Phänomen ist noch gefährlicher als offizielle Entscheider, die außerhalb des Teams stehen. Zusätzlich zu den Problemen, die die offizielle Entscheider verursachen, kommt hier noch dazu, dass die Teams sich oft gar nicht bewusst sind, dass es diese inoffiziellen Entscheider gibt.
Dabei ist es durchaus wichtig, dass das Entwicklungs-Team Rat von externen Experten einholt, wenn es seine Technologieentscheidungen fundiert treffen möchte. Sich bei Außenstehenden Rat einzuholen, wird aber immer wieder als Einmischung betrachtet, weshalb die Teams lieber gar nicht erst fragen. Wenn die Experten nicht gehört werden und das Team nicht auf das in der Firma vorhandene Wissen zugreift, werden wichtige Aspekte nicht berücksichtigt, es kommt zu suboptimalen Entscheidungen und schlussendlich lernt die Organisation nichts hinzu.
Mittelweg zwischen Stillstand und Chaos
Der letzte Abschnitt hat gezeigt, dass Technologieentscheidungen in selbstorganisierten Teams Regeln brauchen, damit sie sinnvoll funktionieren.
Hinsichtlich des Umfangs und der Weiterentwicklung des Technologieportfolios gibt es zwei Extreme. Das eine Extrem ist der bereits beschriebene Technologiezoo. Es existiert ein großer Umfang an Technologien, die in der Regel nur maximal eine Person ausreichend gut beherrscht, um Probleme im Produktivsystem zu beheben. In diesem Fall sind weite Teile der Software schnell nicht mehr wartbar und jeder Urlaub oder Krankheitsfall ist ein operatives Risiko. Außerdem können die Entwickler nicht voneinander lernen und sich gegenseitig helfen. Das andere Extrem sind rigide Unternehmensstandards. Alle Software wird mit einer oder sehr wenigen Programmiersprachen, Frameworks und Werkzeugen entwickelt, die über einen langen Zeitraum stabil sind. In diesem Fall verpassen die Entwickler in der Regel den Anschluss an den technologischen Fortschritt und die Organisation ist irgendwann mit dem Problem konfrontiert, dass die verwendeten Technologien aus dem Support laufen und es immer schwieriger wird, Nachwuchs zu finden, der mit diesen Technologien entwickeln möchte.
Es braucht ein auf Selbstorganisation basierendes Verfahren zur Technologieauswahl, das einen gesunden Mittelweg zwischen den beiden beschriebenen Extremen darstellt. Die Drei-Personen-Regel ist ein solches Verfahren. Sie lautet:
„Es darf jede neue Programmiersprache ins Unternehmen eingeführt werden, solange es mindestens drei Personen gibt, die sowohl in der Lage, als auch bereit sind, Produktionsfehler in dieser Sprache zu beheben.“
Damit ist die Firma neuen Technologieansätzen gegenüber grundsätzlich aufgeschlossen. Auf der anderen Seite ist sichergestellt, dass immer eine ausreichende Anzahl von Personen über entsprechende Kenntnisse verfügt. Möchte ein Entwickler eine neue Programmiersprache einführen, muss er mindestens zwei Mitstreiter überzeugen, die bereit sind, diese Sprache in einem ausreichenden Maße zu lernen (siehe Abb. 2). Verlässt einer der drei das Unternehmen, haben die anderen beiden die Aufgabe, mindestens einen neuen Mitstreiter zu finden.
Abb. 2: Jede Programmiersprache muss mindestens drei Supporter haben
Größere Unternehmen können auch eine höhere Mindestanforderung (n-Personen-Regel) definieren, sollten aber drauf achten, dass dadurch nicht wieder eine Barriere für die Einführung neuer Technologien entsteht.
Ein Leitfaden hilft bei der Technologieauswahl
Die Drei-Personen-Regel hilft vor allem bei größeren Technologieentscheidungen – z.B. der Auswahl einer neuen Programmiersprache oder einer neuen Datenbank- bzw. NoSQL-Technologie. Sieht behebt aber nicht alle der in diesem Artikel bereits beschriebenen Probleme.
Um die Entwicklungsteams bei der Technologieauswahl zu unterstützen, ist es sinnvoll, einen Leitfaden zu definieren, der aus den folgenden Punkten besteht:
- Was entscheiden wir? Oft ist den Teammitgliedern gar nicht klar, dass sie sich in einem Meeting befinden, in dem eine Technologieentscheidung getroffen werden soll. Dementsprechend sind sie vermutlich auch nicht vorbereitet. Der erste Punkt des Leitfadens macht explizit klar, dass eine solche Entscheidung ansteht. Die Mitglieder können sich sinnvoll vorbereiten. Hat das Team z.B. in seinem Teamvertrag [5] festgelegt, dass zu solchen Entscheidungen immer alle Mitglieder anwesend sein sollen, muss ein entsprechender Termin gefunden werden.
- Nach welchen Kriterien entscheiden wir? Damit in der Diskussion nicht ständig neue Anforderungen entstehen, legt das Team vorab die Anforderungen bzw. Kriterien für die neue Technologie fest. Hierzu gehören z.B. auch Betriebs- und Sicherheitsaspekte oder der Support durch die Community sowie der grobe Einarbeitungsaufwand für das Team.
- Was sind die Optionen? An dieser Stelle darf jeder der Entwickler seine Lieblingstechnologie vorschlagen.
- Wer gehört zum Team? In diesem Schritt geht es um die entscheidende Frage, wer sozusagen stimmberechtigt ist, damit nicht wieder die gesamte Firma an der Technologieentscheidung teilnimmt. Aus dem Prinzip „You build it, you run it“ folgt, dass die Entscheidung von den Entwicklern getroffen wird, die nachts aufstehen müssen, wenn es zu Problemen kommt.
- Wer sind maßgebliche Experten? Im Rahmen der Technologieentscheidung überlegt sich das Team auch, bei welchen Personen im Unternehmen sie sich eine Expertenmeinung oder zumindest einen Rat einholen können. Die Schatten-CTOs dürfen gerne beratend zur Seite stehen, sind allerdings nicht stimmberechtigt.
Der Leitfaden ist zum einen eine Hilfestellung während der Entscheidungsfindung. Zum anderen handelt es sich dabei auch um einen guten Ausgangspunkt zur Dokumentation der wichtigsten Architekturentscheidungen eines Projekts oder Produkts (z.B. basierend auf dem arc42-Template [6]).
Team-übergreifende Entscheidungen in Communities of Practice
In der Regel besteht eine Firma aus mehr als einem selbstorganisierten Team. Das beschriebene Verfahren hält diese Teams nicht davon ab, im Extremfall jeweils eine andere Programmiersprache, eine eigene Datenbanktechnologie usw. einzusetzen. Damit haben die Teams die maximale Autonomie und ein Minimum an Abhängigkeiten erreicht. Aber hat es nicht Sinn, für die Teams gemeinsame Standards zu definieren, um „Synergien zu heben“, wie es so schön heißt?
Tatsächlich überwiegen die tatsächlichen Synergien in den seltensten Fällen die Vorteile, die autonome Teams mit sich bringen. Andererseits gibt es immer wieder Situationen, in denen teamübergreifende Standards sinnvoll sein können. Würde ein zentraler externer Entscheider zum einen festlegen, welche Themen standardisiert werden und wie die Standards aussehen, stellte das wieder einen Eingriff in die Selbstorganisation und Autonomie der Teams dar. Damit tauchen die am Anfang des Artikels beschriebenen Probleme wieder auf. Der selbstorgansierte Weg über Standards zu entscheiden sind teamübergreifende Arbeitsgruppen. Jedes Team entsendet einen oder mehrere Vertreter in diese Arbeitsgruppe. Dort entscheiden die Teilnehmer, welche Themen standardisiert werden sollen, und wie entsprechende Standards aussehen können. Es bietet sich an, diese Arbeitsgruppen als Communities of Practice zu organisieren [7][8].
Diese Communities lösen noch weitere Probleme, die in der Regel auftreten, wenn die Teams hochgradig autonom arbeiten. In den Communities arbeiten die Software-Entwickler mit Kollegen zusammen, die in einem ähnlichen Themengebiet unterwegs sind, wie sie selbst. Dadurch wird das teamübergreifende Lernen unterstützt und die Entwickler können sich gegenseitig bei Alltagsproblemen unterstützen. Außerdem kennen die Entwickler dann ganz automatisch entsprechende Experten, deren Meinung sie für Technologieentscheidungen im Team einholen können.
Fazit
Dieser Artikel begann mit einer Motivation, warum Entwicklungsteams selbstorganisiert und autonom über die von ihnen verwendeten Programmiersprachen, Frameworks und Werkzeuge entscheiden sollten. Damit diese Entscheidung sinnvoll funktionieren, ist es wichtig, einige wenige Grundregeln wie die Drei-Personen-Regel sowie einen Leitfaden aufzustellen. Damit sind die Teams gut gerüstet.
Entscheidungen, die über ein Team hinausgehen, sollten nicht von zentralen Entscheidern, sondern in Communities of Practice getroffen werden. Die Arbeit in diesen Communities dient außerdem der Wissensverteilung im Unternehmen.
Die beschriebenen Konzepte haben gezeigt, dass Technologieentscheidungen vollständig ohne zentrale Entscheider möglich sind. Damit haben die Entwicklungsteams so wenig externe Abhängigkeiten wie möglich und können sich vornehmlich auf ihre wichtigste Aufgabe konzentrieren – funktionierende Produktinkremente auszuliefern.
Konstantin Diener ist CTO bei cosee. cosee entwickelt digitale Produkte für und mit Kunden und setzt dabei auf selbstorganisierte, autonome Teams (cosee.biz, @coseeaner). In seiner Rolle als CTO ist Konstantin schon seit einigen Jahren nicht mehr in konkrete Technologieentscheidungen eingebunden, sondern hilft den Teams dabei, sich an die selbstdefinierten Regeln zu halten. Er spricht gerne und oft auf Konferenzen und schreibt Fachartikel.
@onkelkodi
[1] http://agilemanifesto.org/principles.html [2] https://www.scrumguides.org/scrum-guide.html#team-dev [3] „Technologieentscheidungen an der Basis“; Kolumne „DevOps Stories“; JavaMagazin 5.2017; https://jaxenter.de/devops-stories-56632 [4] http://queue.acm.org/detail.cfm?id=1142065 [5] „So wird hier gearbeitet!“; Kolumne „DevOps Stories“; JavaMagazin 7.2017; https://jaxenter.de/devops-stories-teamvertrag-59168 [6] http://www.arc42.de/ [7] „Das kann doch nicht jeder anders machen!“; Kolumne „DevOps Stories“; JavaMagazin 9.2017; https://jaxenter.de/devops-stories-crossfunktionale-teams-61602 [8] „Gleichgesinnte zusammenbringen – Kollaboration zwischen crossfunktionalen, selbstorganisierten Teams“; Business Technology 4.2017; https://jaxenter.de/devops-community-of-practice-64592
