Warum die Gewaltenteilung in Scrum so wichtig ist

Das Konzept hinter Scrum ist ziemlich simpel: Es gibt Scrum Teams und mit ihnen verbundene Rollen (Product Owner, Scrum Master und Entwicklungsteam), Ereignisse, Artefakte und bewährte agile Praktiken. Es herrscht also eine klare Aufteilung der Verantwortlichkeiten zwischen den einzelnen Rollen.

Zudem gibt ein Element in Scrum, das ich wirklich schätze: die Gewaltenteilung.
Was genau meine ich damit?

Demokratien basieren auf der Gewaltenteilung und benötigen:

• Legislative
• Exekutive
• Judikative

Jede dieser drei Säulen hat seine Rechte und Pflichten. Die anderen zwei überwachen, dass die Dritte ihre Macht nicht missbraucht. In totalitären Regierungen ist dies nicht gegeben. Eine Einheit regiert über alle drei. Üblicherweise bedeutet dies, dass einige wenige profitieren und viele leiden – von Einzelpersonen bis zu ganzen Ökonomien.

Doch was hat das mit Scrum zu tun? Nichts – zumindest nicht auf den ersten Blick.

Wenn wir das Prinzip des Totalitarismus auf das klassische Management anwenden, hat der Projektmanager die Möglichkeit, als Diktator zu agieren. Er oder sie kann über alle drei Elemente entscheiden: Scope, Schedule, People.

Die obige Skizze ist das unvollständige «Iron triangle of quality» («Das eiserne Dreieck der Qualität»). Es besagt, dass wir zwei der drei Elemente auswählen können, das Dritte muss nachgeben. Wenn wir zum Beispiel eine gewisse Menge an Funktionalität (Scope) zu einem gewissen Termin (Schedule) liefern müssen, dann müssen wir die Anzahl der Personen, die daran arbeiten, anpassen.

Wenn die Qualität leidet …

Wenn alle drei Elemente festgelegt werden, dann wird die Qualität des zu entwickelnden Produkts geopfert, wenn die Lage kritisch werden sollte. Qualität ist das vierte versteckte Element. Oft versuchen die Manager das Team über die Erreichbarkeit des Ziels mit Sprüchen wie «Das ist ein sportliches Ziel, aber …», «Du bist kein Teamplayer …» und einige mehr zu überzeugen.

In einem Softwareprojekt stirbt die Qualität immer als Erstes. Sie ist oft nicht erkennbar und wenn, dann erst in einer späten Projektphase oder gar erst, wenn das Produkt veröffentlicht wurde. Dies offenbart sich mit einer sehr hohen TCO (Total Cost of Ownership). Schliesslich wollen die Entwickler die mangelhafte Software neu und richtig schreiben.

… greift der Scrum Master ein!

Wie wird dies mit Scrum gehandhabt? Die «Definition of Done» (DoD) in Scrum legt gewisse Attribute und Aktivitäten fest, die vorhanden sein müssen, um eine hohe Produktqualität und ein releasbares Produkt zu garantieren. Die Einhaltung der DoD ist von höchster Bedeutung für ein hochwertiges Produkt, glückliche Kunden und niedrige Total Cost of Ownership (TCO). Scrum ist nicht vor kritischen Zeiten gefeit, in denen der Product Owner (PO) versucht, das Development Team etwas mehr anzutreiben. In solchen Situationen wäre es verlockend, die DoD aufzugeben und die Qualität zu reduzieren, um den Termin einzuhalten und den PO glücklich zu machen. Das ist der Moment, wenn der Scrum Master ins Spiel kommt. Er wird den PO abfangen und sicherstellen, dass die DoD weiterhin eingehalten wird. Im Wesentlichen schützt er das Development Team und ermöglicht ihm, in der vereinbarten Art und Weise zu arbeiten und somit ein qualitativ hochwertiges Produkt zu entwickeln.

In Scrum hat der Product Owner das Recht zu entscheiden, welche Features in welcher Reihenfolge entwickelt werden. Das Werkzeug dafür ist der Product Backlog.

Die Pflicht des Scrum Masters ist es, sicherzustellen, dass das Development Team das Recht hat, den Arbeitsaufwand im Einklang mit der Definition of Done zu schätzen und zu implementieren.

Fazit

Die Gewaltenteilung schützt das Development Team und erlaubt ihm, qualitativ hochwertige Produktinkremente während der kompletten Projektdauer zu liefern. Dieses nachhaltige Vorgehen garantiert qualitativ hochwertige Software mit hohem Return on Investment (ROI) und niedrigem Total Cost of Ownership; Software, die für viele lange Jahre einfach zu warten, zu erhalten und zu erweitern sein wird. Noch besser, Sie sollten zufriedene, engagierte Entwickler sehen.

Am Ende gewinnen alle.