Wringing two Necks – Ein Plädoyer für die Redundanz

Wenn BWLer* von redundanten Ressourcen hören, stellen sich instinktiv die Nackenhaare auf. Kein Wunder, schließlich stellt das für viele ein Synonym für „Geldverschwendung“ dar. Auch „Restrukturierungen“ werden häufig mit der Begründung durchgeführt, dass „redundante Ressourcen“ reduziert werden sollen.

Weil sie so ein schlechtes Image genießt, möchte ich hier eine Lanze für die Redundanz brechen.

* als BWLer darf ich das einfach so sagen

Eigentlich ist Scrum vom Start aus auf Redundanz ausgelegt. Schließlich soll das Entwicklungsteam in Scrum möglichst cross-funktional aufgestellt sein, Teammitglieder sollen in Richtung „T-shaped people“ entwickelt werden (also Personen mit einem breiten Allgemeinwissen und mindestens einer tiefergehenden Spezialisierung). Informationen sollen möglichst breit gestreut werden, um Wissensinseln zu vermeiden. Teile des Teams sollen sich Urlaub nehmen können, ohne dass die ganze Produktentwicklung zum Stehen kommt.

Warum sieht das Scrum-Framework dann aber nur einen Product Owner vor?

Natürlich ist es manchmal einfacher, wenn ein „single wringable neck“ im Zweifel das letzte Sagen über die Priorisierung des Backlogs hat. Gerade in großen Unternehmen mit komplexen Matrixorganisationen sorgt die Ermächtigung des Product Owners im Zweifel dafür, dass ein Product Backlog – und damit ein Produkt – überhaupt zustande kommt.

Doch dieselben Vorteile, die durch Redundanzen im Team entstehen, gehen im Fall eines einzigen Product Owners verloren.

So spricht vieles dafür, den Prozess es auch mal mit zwei Product Ownern auszuprobieren.

Wie an anderer Stelle erwähnt, arbeiten wir in meinem Team erfolgreich mit zwei (Proxy) Product Ownern. Das hat aus meiner Sicht mehrere Gründe.

Zum einen handelt es sich um ein relativ komplexes Projekt, bei dem wir von fachlichen Konzepten abhängig sind, die in ein Wireframe umgesetzt werden, bevor wir die benötigten Schnittstellen bei einem anderen Dienstleister umsetzen lassen können. Erst dann kann eine User Story bei uns in die Entwicklung.

Diese lange Reise einer User Story von der ersten Idee bis zu dem Punkt, an dem die „Definition of Ready“ erfüllt ist, dauert mindestens drei Sprints. Dadurch entstehen komplexe Abhängigkeiten, die es gilt, im Blick zu behalten.

Hier ein Detail zu übersehen, kostet also richtig viel Zeit. Um dafür zu sorgen, dass das nicht passiert, eignen sich vier Augen wesentlich besser als zwei – zumal Urlaube und Krankheiten alleine schon häufig genug dafür sorgen, dass der Product Owner zum Bottleneck wird. Dieses Risiko konnten wir durch die doppelte Rollenverteilung wesentlich reduzieren.

Darüber hinaus ist unser Team (für ein Scrum-Team), sehr groß. Wir könnten problemlos zwei noch immer relativ große Scrum-Teams aus dem einen Team machen und bräuchten dann also so oder so zwei Product Owner.

Um den Entwicklungsprozess nicht aufzublähen, haben wir uns aber dafür entschieden, das Team nicht zu splitten. Das hat zur Konsequenz, dass aus dem einen Team nun auch wesentlich mehr Unklarheiten und Rückfragen entstehen, die sich mit zwei Product Ownern ebenfalls viel einfacher handhaben lassen.

Insgesamt bedeutet also „single wringeable neck“ auch gleichzeitig „single bottleneck“. Wenn Cycle und Lead Times – also die Durchlaufzeit einer Aufgabe durch die gesamte oder Teile der Prozesskette – Werte sind, die optimiert werden sollen, darf es in einem Prozess auch keine Einzelpersonen geben, die zu Informations-Staus und Wissensinseln führen können.

Gerade Lead und Cycle Time sind Faktoren, die das Maß an Agilität eines Prozesses massiv bestimmen. Insofern profitieren von Redundanz nicht nur Scrum-Teams.

In jeglicher Aufbauorganisation sollten Bottlenecks identifiziert und Wege gefunden werden, diese zu eliminieren – Abbau von Redundanzen kann hier nur der falsche Ansatz sein.

Wenn ich darüber nachdenke, worauf ich in meiner Berufslaufbahn am längsten warten musste, dann waren das mit Sicherheit Entscheidungen.

Klassische Aufbauorganisationen neigen aber dazu Entscheidungen, je wichtiger sie werden, umso stärker an Einzelpersonen zu hängen. Aus Systemsicht ist das aber kontraproduktiv. Vielmehr kann auch hier das Schaffen von Redundanzen die Lösung sein. Eine andere: Reduzieren der Auslastung (ein anderes Stichwort, bei dem es BWLer schüttelt). Fraglich ist aber, ob es nicht sinnvoller ist, die Gesamtproduktivität eines Systems durch eine zusätzliche Person massiv zu erhöhen, als sie dadurch zu senken, dass sie an einem einzigen Engpass angepasst werden muss.

Ein funktionierendes System braucht also einen Weg, Entscheidungen effizient zu fällen, am besten dort, wo sie benötigt werden. Und so landen wir schließlich bei agilen Organisationen und einem der Gründe dafür, warum sie so gut funktionieren.

Agile Organisationen leben gerade davon, dass Entscheidungskompetenz nicht gebündelt wird, indem Redundanzen jeglicher Art vermieden werden. Vielmehr werden Redundanzen aktiv geschaffen und Mitarbeiter ermächtigt, um das Gesamtsystem zu optimieren.

Oma sagte ja auch schon: Doppelt gemoppelt hält besser.