© Liashko/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 umfangreich...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang