© VectorMine/Shutterstock.com
Wie viel „Selbst“ steckt in einem selbstverantwortlichen Team?

Selbst ist das Team


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 – andes 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, Versand und Logistik sowie einem operativen Team zusammen (Abb. 1).

junker_selbstorganisation_1.tif_fmt1.jpgAbb. 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 verwenden alle Teams. 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 der Oberfläche nicht nu...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang