Selbst ist das Team

Autonome Teams: Wie viel „Selbst“ steckt in einem selbstverantwortlichen Team?
Keine Kommentare

Selbstverantwortliche Teams klingen manchmal wie ein Traum: Man verbindet damit autonom agierende Gruppen mit der Kompetenz, eigenständige Entscheidungen zu treffen. In den meisten Fällen entspricht das allerdings nicht der Realität. Wir wollen uns in diesem Artikel anschauen, wie Architekten, Scrum Master und Product Owner den Kontext, in dem ihre Teams arbeiten, so gestalten können, dass selbstverantwortliche Teams möglich werden und nicht nur ein Traum bleiben.

Autonome Teams gelten im Kontext der aktuellen DevOps-Bewegung als ideal. Doch darf bei aller Euphorie über Selbstverantwortung und Selbstbestimmung nicht vergessen werden, dass Teams in Unternehmenskontexte eingebunden sind. Sie existieren in einem Managementumfeld, das unter Umständen noch sehr hierarchisch organisiert ist. Zudem können Teammitglieder nicht passend geschnitzt werden – anders als es einst Urfin mit seinen Holzsoldaten getan hat [1]. Sie sind Individuen, deren Fähigkeiten gezielt eingesetzt werden sollten.

Oftmals sind weder die technischen noch die methodischen Voraussetzungen gegeben, um selbstbestimmte Teams zu ermöglichen. Um diese Voraussetzungen soll es in diesem Artikel gehen. Um sie aufzuspüren, wollen wir zunächst zwei Negativbeispiele betrachten, in denen Teams in Kontexten arbeiten, die Selbstverantwortung erschweren. Es folgen Vorschläge, wie gewisse Hürden für eine effektive Selbstorganisation abgebaut werden können.

Vorab stellt sich die Frage, welche Entscheidungen ein Entwicklungsteam überhaupt treffen kann bzw. treffen will. Typischerweise bezieht sich die Selbstbestimmung auf einen oder mehrere der folgenden Punkte:

  • Technologien und Tools, mit denen das Team arbeiten möchte
  • Implementierung und Design der Software
  • Zeitpunkt, zu dem die durch das Team entwickelte Software in Produktivbetrieb genommen wird
  • Art und Weise des Betriebs der entwickelten Software
  • Priorisierung und Reihenfolge der zu implementierenden Leistungsmerkmale in Zusammenarbeit mit dem Produktverantwortlichen (je nach Vorgehensmethode der Produktmanager oder Product Owner).

Anhand dieser Liste wollen wir in den folgenden Beispielszenarien untersuchen, wie frei die Teams in ihren Entscheidungen tatsächlich sind.

Beispiel 1: Klassisches Enterprise-Team

Als erstes Beispiel dient uns ein Projekt im Enterprise-Umfeld. Es baut auf jahrelang entwickelte und stetig erweiterte Software auf. Die Teams arbeiten an einem großen Shoppingportal, das neben der eigentlichen Shoppingsoftware auch umfangreiche Module zur internen Verrechnung und zur Rechnungserstellung umfasst. Das Projekt setzt sich aus einem Datenbankteam, Businessdomänenteams zur Payment-Anbindung, Katalogverwaltung, externen Schnittstellen, Rechnungserstellung, Versendung und Logistik sowie einem operativen Team zusammen (Abb. 1).

Abb. 1: Beispiel für Teams in einem typischen Enterprise-Projekt

Abb. 1: Beispiel für Teams in einem typischen Enterprise-Projekt

Die Datenbank ist die zentrale Komponente des Projekts. Daher achtet das Datenbankteam penibel darauf, dass seine Vorgaben durch die Businessdomänenteams eingehalten werden. Die Teams haben naturgemäß unterschiedliche Anforderungen an die Datenbankstruktur: Ein Team will vorzugsweise schnell Daten schreiben, während ein anderes Team die gleichen Daten möglichst schnell lesen will. Das Datenbankteam dagegen braucht eine stabile und verlässliche Datenbank. Die Domänenteams würden gern die Datenbankstrukturen ihren Bedürfnissen anpassen, müssen sich aber mit den anderen Teams abstimmen. Letztlich bestimmt das Datenbankteam, wie die Datenbankstruktur aussieht. Allerdings führt das am Ende dazu, dass nur Kompromisse eingegangen werden, die niemanden überzeugen.

Die Domänenteams können einigermaßen unabhängig voneinander arbeiten. Sie entwickeln die Software für ihre Domäne und setzen sich sowohl aus Backend- als auch aus Frontend-Entwicklern zusammen. Die Backend-Entwickler implementieren klassische Businesslogik eines Enterprise-Systems. Sie verwenden alle möglichen Arten von Schnittstellen: von einfachen XML-Übergaben über mächtige SOAP-Schnittstellen bis hin zu zögerlich eingesetzten REST-Schnittstellen. Um eine möglichst hohe Entwicklungsgeschwindigkeit und ein hohes Maß an Wiederverwendbarkeit zu erreichen, verwenden die Backend-Entwickler Hilfsbibliotheken, die ständig an geänderte Bedingungen angepasst werden. Diese Bibliotheken werden durch alle Teams verwendet. Dadurch ergeben sich hohe Synchronisationsaufwände und fast nicht zu beherrschende Abhängigkeiten bei Produktivgängen.

Wenn die Backend-Entwickler eine Funktion fertiggestellt haben, übergeben sie diese an die Frontend-Entwickler innerhalb ihres Teams. Die Frontend-Entwickler setzen moderne Technologien ein, die für eine vollständige Überarbeitung der Weboberflächen und für mobile Applikationen eingeführt wurden. Sie erwarten asynchrone REST-Schnittstellen, die durch die Backend-Entwickler zur Verfügung gestellt werden. Allerdings sind diese Schnittstellen nur auf die vorhandene Architektur aufgesetzt. Das bedeutet, dass bei notwendigen Änderungen in der Oberfläche nicht nur die REST-Schnittstellen, sondern auch die mächtigen SOAP-Schnittstellen angepasst werden müssen.

DevOps Docker Camp

Sie lernen die Konzepte von Docker und bauen Schritt für Schritt eine eigene Infrastruktur für und mit Docker auf.

Das operative Team übernimmt die entwickelten Inkremente einige Wochen vor dem Produktivgang. Es bereitet die Produktionsübernahmen vor. Dazu gehören neben dem Enterprise-Code und seinen Frontend-Anteilen auch Datenbankskripte sowie weitere Skripte, um das System für den jeweiligen Entwicklungsstand anzupassen. Das operative Team versucht immer wieder, die Übernahmen zu automatisieren. Allerdings fehlen hierfür oftmals die notwendigen Ressourcen. Die Mitarbeiter sind in der Regel mit dem Support der produktiven Landschaft vollständig ausgelastet.

In diesem Szenario können die Teams die Technologie, die sie einsetzen wollen, nicht wählen. Selbst Interfacetechnologien werden durch das existierende System vorgegeben. Durch die Trennung der Frontend- und Backend-Technologien ergeben sich erhebliche Abstimmungsaufwände, die ein schnelles Arbeiten verhindern. Die Teams sind an das operative Team gebunden, um ihre Software live zu nehmen. Dadurch werden Initiativen in Richtung Automatisierung der Produktivnahmen stark behindert, wenn nicht sogar verhindert. Das operative Team betreut die laufende Software. Operative Schwierigkeiten erreichen die Entwicklungsteams nur gefiltert, was immer zu einer höheren Priorisierung von funktionalen Anforderungen gegenüber technischen, nichtfunktionalen Anforderungen führt. Obwohl die Entwicklungsteams in einem eingeschränkten Maße Implementierungs- und Designentscheidungen treffen dürfen, können sie über den Ablauf und den Zeitpunkt einer Produktivstellung nicht selbst entscheiden.

Was wäre nun architektonisch und organisatorisch zu tun, um den Teams mehr Selbstorganisation zu ermöglichen?

Aus architektonischer Sicht wäre es sinnvoller, die Datenbank in der Domäne zu implementieren. Die Domänenteams sollten ihre eigene Datenbank erzeugen, für die sie auch verantwortlich sind. Produktivgänge könnten durch die Implementierungsteams automatisiert werden. Die Hilfsbibliotheken sollten hierfür Schritt für Schritt abgelöst werden. Abhängigkeiten können über eine Versionierung der einzelnen Bibliotheksbestandteile behandelt werden.

Organisatorisch würde das bedeuten, dass das dezidierte Datenbankteam aufgelöst würde und die Datenbankexperten zu Teammitgliedern würden. Außerdem sollte die Trennung von Frontend- und Backend-Entwicklern aufgehoben werden. Entwickler erweitern ihre Fähigkeiten und decken beide Bereiche ab. Operations-Mitarbeiter treiben innerhalb der Teams die Automatisierung der Produktivgänge voran, während das Produktmanagement in den Teams die Product Ownership übernimmt.

Beispiel 2: Neuproduktentwicklung mit DDD

Teams in einer Produktneuentwicklung können ganz anders agieren. Als zweites Beispiel sollen hier Teams dienen, die eine Firmeneinkaufslösung entwickeln. Das Produktmanagement und verantwortliche Architekten starten mit einer Domänendefinition im Sinne eines domänengetriebenen Designs [2].

Abb. 2: Beispiel für Domänenteams mit separater Architektur und Management

Abb. 2: Beispiel für Domänenteams mit separater Architektur und Management

Auf dieser Basis werden Teams gebildet, die im weiteren Projektverlauf in ihren Domänen Microservices-Architekturen implementieren, die durch die lose Kopplung eine hochgradige Unabhängigkeit aufweisen. Die Teams sind als DevOps-Teams organisiert, sodass sie nicht nur die Verantwortung für die Softwareerstellung übernehmen, sondern auch die Verantwortung für die Produktivstellung. Alle Produktivnahmen und entsprechende Tests werden schon im Vorfeld automatisiert, sodass die gesamte Produktivstellung automatisch erfolgen kann. Alle Teams beginnen in ihren jeweiligen Domänen zu arbeiten und erzielen schnell Ergebnisse. Besonderes Expertenwissen wird im ersten Schritt nicht benötigt, da die Teams selbst über genügend Know-how verfügen. Fullstack Developer – also Entwickler, die sowohl Frontend- als auch Backend-Expertise mitbringen – können die Entwicklung schnell voranbringen. Entwickler, die Expertise in mehreren Bereichen mitbringen, sind in Abbildung 2 mit Verläufen gekennzeichnet (grün-blau für Front-Backend-Entwickler, dunkelblau-orange für Datenbank-Operations-Experten).

Allerdings sehen die Teammitglieder nach einer gewissen Zeit, dass die Domänen in ihren Entwicklungen auseinanderlaufen, da sie unterschiedliche Erfahrungen bezüglich ihrer Domäne und den entsprechenden Kundenanforderungen sammeln. Die Implementierung der Kataloganbindungen ist schon sehr weit vorangeschritten. Aber die qualifizierten Lieferanten können an der Oberfläche des „Call of Bids“ nicht angezeigt werden, da die Katalogimplementierung bei der Einbindung verschiedener Anbieter sehr viel Zeit gekostet hat und die Datenübergaben erst zu einem späteren Zeitpunkt implementiert werden können. Die am Anfang erstellten Kontextübersichten stimmen folglich nicht mehr und müssten aktualisiert werden (zum Begriff „Context Maps“ siehe [2] und [3]). Zudem nehmen Absprachen über Schnittstellen sehr viel Zeit in Anspruch, da prinzipielle Architekturvorgaben fehlen. Insgesamt fühlen sich die Teams ein wenig allein gelassen, sie werden für alles verantwortlich gemacht, ohne dass sie wirklich auf Anbieterentscheidungen und damit auf prinzipielle Technologieentscheidungen Einfluss haben. Die Idee des integrierten Produkts ist verloren gegangen – jede Domäne arbeitet für sich.

Lesen Sie auch: Der Scrum Master – ein agiler Fortsetzungsroman

Diese Teams können zwar die Technologie, mit der sie arbeiten möchten, selbst bestimmen. Aber oftmals vermissen sie die notwendige Unterstützung, da es einfach zu aufwendig und zu teuer ist, für jede denkbare Technologie Support zu organisieren. Die Teams können ihre Software selbst und zu jedem beliebigen Zeitpunkt produktiv nehmen. Aber sie können nicht bestimmen, wie die von ihnen entwickelten Features benutzt werden, da sie von anderen Teams und ihren Produktivgängen abhängig sind. Auch wenn die Teams selbst bestimmen, wie sie ihre Software betreiben, können sie nicht die Erwartungshaltung eines rund um die Uhr operativen Supports erfüllen. Die wesentlichen organisatorischen und arbeitsrechtlichen Vereinbarungen fehlen ihnen.

Was ist technisch und organisatorisch zu tun, um mehr Selbstorganisation zu ermöglichen?

Technische und organisatorische Voraussetzungen schaffen

In beiden Szenarien steckt in den Teams wenig „Selbst“ – wenig Selbstorganisation, wenig Selbstverantwortung. Auch wenn die Beispiele pointiert dargestellt sind, können die geschilderten Probleme jederzeit in der Projektarbeit real werden. Doch wie können selbstorganisierte Teams unabhängig agieren, wenn beide skizzierten Wege nicht funktionieren?

Teams sollten anhand einer ausführlichen Domänenanalyse aufgestellt werden. Die Entwickler- oder auch DevOps-Teams können dies nicht selbst tun, da sie ja zu dem Zeitpunkt noch nicht existieren. Die Domänenanalyse muss von einem breit aufgestellten Kollegium durchgeführt werden. Dieses Kollegium setzt sich aus Vertretern der Entwicklung mit Product Ownern, Architekten, Entwicklern und Qualitätsverantwortlichen, Vertretern des Betriebs, Vertretern des strategischen Managements mit Enterprise-Architektur, Business Development und Geschäftsleitung sowie aus Vertretern des operativen Geschäfts wie Verkauf und Marketing zusammen. Domäne heißt dann nicht, „wir von der Entwicklung“ oder „wir aus dem Marketing.“ Vielmehr geht es um die Frage, wie der Businessprozess aussieht und wo sinnvolle Unterdomänen auszumachen sind (Sub Domains und Bounded Context [3]).

Aus diesem Prozess ergeben sich Domänen, die durch voneinander unabhängige Teams besetzt werden müssen. Sie erstellen Kontextübersichten oder verfeinern bereits vorhandene Übersichten. Daraus ergeben sich inhaltliche Schnittstellen, die noch nicht unbedingt technologisch definiert sind. Im späteren Verlauf können die Teams verbrauchergetriebene Schnittstellentests implementieren (Consumer-driven Contracts and Tests [4]), die sicherstellen, dass Produktivgänge eines Teams die Funktion eines abhängigen Teams nicht brechen.

Das Architekturteam schlägt Technologieleitlinien vor, die durch das Management bestätigt werden müssen. Diese Leitlinien beinhalten die zu verwendenden Cloud- oder Rechenzentrumsanbieter, Entwicklungssprachen, Datenbanken und Ähnliches. Neben technisch-funktionalen und Kostenaspekten umfassen sie auch weiche Aspekte wie vorhandenes Wissen und Fähigkeiten im Unternehmen, eingesetzte Technologien bei Kunden oder bereits vorhandene Verträge mit Anbietern. Letztlich müssen auch Konzernentscheidungen beachtet werden, die die Auswahl von Technologie einschränkt. Diese Vorgaben gelten für alle Teams. Allerdings kann es zu Ausnahmen kommen, die durch Architekturteam und Management bestätigt werden müssen. In der Regel führen solche Ausnahmen zu erhöhten Kosten, die begründet sein müssen.

Neben den technologischen Vorgaben müssen für die Teams Architekturvorgaben erarbeitet werden. Diese Vorgaben enthalten Unterstützung insbesondere für die nichtfunktionalen Anforderungen, die durch alle Teams erfüllt werden müssen: Sicherheit, Pflegbarkeit der Software, Monitoring, Robustheit im Betrieb, Erweiterbarkeit und ähnliche nichtfunktionale Anforderungen. Insbesondere die Widerstandsfähigkeit gegen Fehler im Betrieb betrifft alle Teams. Vorgaben helfen den Teams, stabile Gesamtsysteme zu schaffen. Diese Arbeiten sind sehr umfangreich und können nicht alle im Vorfeld erbracht werden. Daher müssen sowohl Teammitglieder als auch Architekten weiter an den Vorgaben arbeiten und diese dann auch in den Teams bekannt machen. Das heißt, Architekten werden als Experten gefragt sein, aber auch innerhalb der Teams als Teammitglieder arbeiten. Technische Lösungen existieren dann in der Regel als Blueprints, die von anderen Teams kopiert werden können.

Eine wichtige Forderung für die Teams besteht in der Management- und Marketingvorgabe, dem Benutzer ein einheitliches Produkterlebnis zu ermöglichen. Daher können die Teams die Benutzeroberfläche nicht einfach nach ihren Wünschen gestalten, sondern brauchen vielmehr genaue Vorgaben, wie die Oberfläche aussehen muss und wie ein Benutzer sich durch die Anwendungen bewegen können soll. Diese Vorgaben müssen von Spezialisten im Bereich Benutzerschnittstellen und Benutzererfahrungen kreiert werden und können dann in den Teams umgesetzt werden. Gerade im Bereich Benutzerführung und Benutzerschnittstellen brauchen die Teams in der Regel Unterstützung. Sie kann ihnen durch einen Pool von Experten zur Verfügung gestellt werden. Diese Expertengruppe stellt dann nicht nur die Expertise bereit, sondern liefert auch die entsprechende technische Lösung wie zum Beispiel ein Frontend-Toolkit.

In der Regel sind die DevOps-Teams mit im Durchschnitt sechs Teammitgliedern und einem Product Owner zu klein, um selbst einen vollständigen Rund-um-die-Uhr-Betrieb zu gewährleisten. Um dies zu erreichen, ist ein hoher Grad an Automatisierung sowohl beim Produktionsgang als auch beim Testen und im Betrieb notwendig. Ein spezialisiertes Operations-Team kann die Teams bei solchen Automatisierungsaufgaben unterstützen. Zum Beispiel haben sie bereits sogenannte Health-Checks für Cluster implementiert (automatische Überprüfung des Serverstatus), die in anderen Teams bei Bedarf wiederverwendet werden können. Außerdem beraten sie die Teams, wie bestimmte Prozesse gemäß den Architekturvorgaben implementiert werden können.

Aber auch die Operations-Experten können arbeitsrechtliche und organisatorische Fragestellungen nicht lösen. Allerdings können diese Fragen durch das Management aufgegriffen und bearbeitet werden. Managementexperten beraten die Teams dabei, wie sie zum Beispiel Bereitschafts- und Ruhezeiten gemäß arbeitszeitrechtlichen Regelungen organisieren können. Das Management sollte sogar einen Schritt weiter gehen und Teams bei ihrer Selbstorganisation begleiten, ohne dass es den Teams als Eskalationseinrichtung und Moderator in Konflikten verloren geht.

Insgesamt sollte in den vier Bereichen Architektur, Benutzerschnittstelle, Betrieb und Management ein reger Austausch mit den Teams stattfinden. Experten müssen den Teams in Kompetenzpools zur Verfügung stehen (Abb. 3).

Abbildung 3: Kompetenzpools für Teams

Abbildung 3: Kompetenzpools für Teams

Voraussetzungen für selbstorganisierte Teams schaffen

Um erfolgreich selbstverantwortliche Teams zu etablieren, brauchen die Teams gute und verlässliche Vorgaben. Diese Vorgaben werden durch Experten wie Architekten und Spezialisten für Benutzerschnittstellen gemeinsam mit den Teams erarbeitet und anschließend in die Teams getragen. In der Regel werden die Experten dann eine Zeitlang in den Teams arbeiten. Auf diese Art und Weise fließen beispielhafte Lösungen als Blueprints aus den Teams zurück in den Expertenpool und können durch andere Teams verwendet werden. Im letzten Schritt nimmt auch das Management eine Expertenrolle ein und berät die Teams in ihrer Organisation. Dabei sollten folgende technische Maßnahmen ergriffen werden:

  • Entwicklung unabhängiger, in Domänen organisierter Microservices
  • Benutzung eines übergreifenden Frontend-Toolkits
  • Blueprint-Implementierungen für nichtfunktionale Anforderungen wie Robustheit im Betrieb
  • 100-Prozent-Automatisierung von Tests und Produktivgängen
  • Absicherung der Schnittstellen durch verbrauchergetriebene Tests

Diese technischen Maßnahmen müssen durch organisatorische Maßnahmen flankiert werden:

  • Teams werden anhand der Domänen organisiert
  • Schnittstellen werden durch Verträge abgesichert
  • Expertise in verschiedenen Bereichen steht auf Abruf (on Demand) zur Verfügung: Operations, Benutzerschnittstelle, Architektur und Management

Durch einen solchen multifunktionalen Expertenpool können technische und organisatorische Fragestellungen gut gelöst werden. Die Teams wären selbstbestimmt und könnten die Technologie, mit der sie arbeiten wollen, selbst wählen. Im Rahmen der Vorgaben könnten sie ebenfalls eigenständig festlegen, wann und wie Features in die Produktion übernommen werden, ihre Software selbst betreiben und letztendlich selbst bestimmen, wie sie was entwickeln.

Die hier beschriebenen Möglichkeiten, einen Kontext für selbstorganisierte Teams zu schaffen, können sicherlich keinen Anspruch auf Allgemeingültigkeit erheben. Auch hier gilt: ausprobieren, bewerten, besser machen. Letztlich muss jede Organisation ihren eigenen Weg finden.

Links & Literatur

[1] Wolkow, Alexander: „Der schlaue Urfin und seine Holzsoldaten“, FISCHER KJB; 5 edition

[2] Evans, Eric: „Domain-Driven Design: Tackling Complexity in the Heart of Software“, Addison Wesley

[3] Vernon, Vaughn: „Implementing Domain-Driven Design“, Addison Wesley

[4] Robinson, Ian: „Consumer-Driven Contracts: A Service Evolution Pattern“: https://martinfowler.com/articles/consumerDrivenContracts.html

Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -