15 Jun
das wesen von scrum

Das Wesen von Scrum: die 4 C’s

SCRUM ist eine Software-Implementierungs-Methodologie innerhalb eines Software-Entwicklungsprojektes, welche besonders auf die Effektivität der Implementierung fokussiert und daher eine streng Feature-orientierte Entwicklung nahelegt. Warum das so ist habe ich in meinem Beitrag „EFFEKTIVITÄT STATT EFFIZIENZ: DER KOMPROMISS SCRUM“ begründet. Und ein Projekt sollte gute Gründe haben, diese Methodologie einer anderen vorzuziehen, denn sie ist nicht per se die allerbeste und immer einzusetzende Methodologie.

Wie aber funktioniert sie und warum? Es genügt mir nicht – wie häufig in der einschlägigen Literatur geschehen – zu beschreiben, wie die Artefakte (Rollen, Sprints, Daily SCRUMS, etc.) implementiert werden und wie sie anzuwenden sind. Es ist vielmehr zunächst wichtig zu verstehen, warum es sie überhaupt gibt bzw. warum sie zwangsläufig erforderlich sind, um erfolgreich zu sein. Sie werden es sich dann nämlich zweimal überlegen, ob sie hier oder da gewisse Dinge ‚customizen‘, bzw. werden sie abschätzen können, ob das überhaupt sinnvoll oder möglich ist und welchen Impact sie erwarten dürfen.

Damit die ganze Sache kurz, pointiert und halbwegs unterhaltsam bleibt, habe ich das Modell der 4 C’s entworfen. Keine Angst, es ist immer noch pures SCRUM und nicht meine persönliche Variante. Es ist nur eine bestimmte Art, SCRUM zu vermitteln und ich hoffe, Sie finden sie ebenso einleuchtend wie logisch.

Die ersten beiden C’s stehen für Commitment und Completion. Sie bilden die statischen Säulen, das Paradigma auf das SCRUM aufsetzt. Die zwei anderes C’s stehen für Communication und Common Sense. Common Sense, ja Sie haben richtig gelesen. Die Anwendung gesunden Menschenverstandes ist bei der Durchführung schon die halbe Miete! Communication und Common Sense sind die dynamischen Komponenten und beschreiben wie SCRUM implementiert wird. Zwei Paradigmen und zwei Techniken, mehr braucht es eigentlich nicht.

Kurz gesagt: Wenn wir in einem Software-Entwicklungsprojekt die Werte Commitment und Completion als höchstes Gut setzen und dann gesunden Menschenverstand (common sense) und eine bestimmte Art der Kommunikation einsetzen, dann kommen wir ganz automatisch auf die SCRUM Methodologie mit allen Artefakten, Prozessen etc..

COMMITMENT & COMMON SENSE IN SCRUM

Scrum Team

Wenn es mir in meinem Projekt darauf ankommt, ein klares Commitment zu erhalten, dann wäre es vernünftig, z.B. den Entwicklungsaufwand von denjenigen bestimmen zu lassen, die die Entwicklung durchführen. Und diejenigen müssen dabei selbst entscheiden dürfen, wie sie die Anforderungen umsetzen. So sind die selbstbestimmten SCRUM-Teams geboren.

Commitment

Natürlich macht es am meisten Sinn, diese Commitments auf möglichst kleine Einheiten zu beschränken, die von einem Team gut zu überblicken sind. Also führen wir besser kurze Sprints durch, denen jeweils ein Grooming und Planning vorangestellt wird, um dieses Commitment zu kreieren.

Daily Scrums

Dann wiederum wollen wir sicherstellen, dass dieses Commitment während eines Sprints auch gehalten wird. Daily Scrums, also kurze tägliche Standup Meetings sind nicht dafür da, dass sich Teams täglich guten Morgen sagen oder ein Wir-Gefühl erzeugen, oder sich erzählen, was sie gestern so getan haben oder heute tun wollen. Das passiert zwar, ist aber nicht der Zweck. Der Zweck ist, das am Sprint-Anfang gegebene Commitment täglich zu erneuern. Sind wir noch im Plan oder droht Gefahr durch Verzug und falls ja, wie kommen wir wieder zurück auf die Bahn und stellen das Commitment sicher. Damit ein Projektleiter das verfolgen kann, sind Sprint-Burndown Charts nützlich. Und ich brauche natürlich einen Moderator für diesen Prozess. Nennen wir ihn mal:

Scrum Master

Er ist nicht dafür verantwortlich, dass das Team Prozess-konform arbeitet. Das tut er zwar, aber das ist nicht der Zweck. Prozesskonformes Arbeiten ist ja kein Selbstzweck. Der Zweck ist, das Team Commitment-fähig zu halten. Denn das Commitment wurde auf der Prämisse erteilt, dass für den Sprint die Ressourcen verfügbar sind und nicht gestört werden und diese ohne Störung von äußeren Einflüssen arbeiten können.

Wir sehen also, dass sich nahezu alle Rollen und orgnisatorischen- oder administrativen Artefakte direkt vom Paradigma Commitment ableiten lassen. Sollten Sie also irgendetwas an Ihrer Methodologie customizen wollen, fragen Sie sich zuerst, ob das Team dann noch Commitment-fähig bleibt. Das gilt insbesondere für all die Fälle, wo Ressourcen temporär aus einem Sprint abgezogen werden, in der Regel für irgendwelche ungeplanten Workshops, Fehlerbeseitigungen, Präsentationen, Wartungsarbeiten, etc.

COMPLETION & COMMON SENSE IN SCRUM

Nun ist es auch wichtig, dass ein Commitment nicht nur gehalten wird, sondern auch überprüft werden kann. Damit ich etwas überprüfen kann wäre es vernünftig, wenn etwas fertig gestellt ist. Aus meiner Projektmanagement Praxis weiß ich natürlich, dass es bei Entwicklern circa ebenso viele Definitionen für den Begriff ‚fertig‘ gibt, wie bei den Eskimos für den Begriff ‚Schnee‘.

„Ich bin fertig, muss nur doch dokumentieren“

„Ich bin fertig, muss da morgen aber noch mal was nachsehen“

„ich bin im Prinzip fertig“ – was oft bedeutet, dass noch gar nicht angefangen wurde

„ich wäre fertig, wenn nicht… (was jetzt kommt, können Sie sich aussuchen)“

„ich bin fertig, aber der letzte Test schlug leider fehl“. Die Liste ist fast endlos.

 

Wenn Sie eine STORY beschreiben, dann sind vier Informationen wichtig:

1. Motivation

Die ‚Motivation‘ sagt, warum dieses Feature überhaupt gebraucht wird. Diese Information ist wichtig, um den Entwicklern eine Vision zu vermitteln, es hilft ihnen den Stellenwert des Features zu beurteilen und daraufhin grundlegende Architekturentscheidungen zu treffen.

2. Description

Die darauf folgende ‚Description‘ sagt, was hier eigentlich gebaut werden soll und ist wichtig, um den Scope einzugrenzen. Grober Leitfaden: IT im ganz Allgemeinen besteht aus 3 Elementen: Daten, Prozessen und Interfaces. Beschreiben Sie also welche Daten über welche Interfaces in welchen Prozessschritten verarbeitet werden. Dann liegen Sie bestimmt nicht ganz falsch bei der Beschreibung der Story.

3. Acceptance Criterias

Die ‚Acceptance Criterias‘ sagen, wann es gut ist, was da gebaut werden soll. Sie legen fest, wann das Feature fertig entwickelt ist, sie sind also die einzig gültige Definition des Begriffs ‚fertig‘.

4. Testcases

Und schließlich die ‚Testcases‘. Sie sagen, wie Sie denn überprüfen, ob es auch wirklich gut ist und damit fertig, was da gebaut wurde.
Und da haben wir auch gleich eine valide Definition des Begriffs fertig.

Eine Story ist dann fertig, wenn ihre Implementierung den Acceptance Criterias entspricht und alle dafür erstellten Testfälle bestanden wurden.

Dies setzt natürlich voraus, dass Acceptance Criterias überhaupt beschrieben wurden sowie ausreichend und aussagefähige Testfälle vorliegen. Oft große Probleme für den Product Owner.

Nur über den Begriff ‚Completion‘ können Sie das Commitment überprüfen. Und daher gilt im Scrum die Regel, dass es nicht ok ist, Stories am Ende eines Sprints offen zu lassen. Das heißt, wenn Sie im Sprint 5 Stories haben und nicht fertig werden können, dann schließen Sie besser so viele wie möglich vollständig ab und andere bleiben dafür ganz offen, als dass Sie alle Stories ‚fast fertig‘ machen. Und damit das getan werden kann, brauchen wir in SCRUM natürlich crossfunktionale Teams und priorisierte Stories, damit in einem solchen Fall der Umpriorisierung andere Teammitglieder daran weiterarbeiten können. Das ist dann übrigens auch der Grund, warum im Sprint-Planning jede Story von jedem Teammitglied geschätzt wird, und sich das ganze Team einig sein muss. Das ist keine teambildende Maßnahme, sondern eine notwendige Voraussetzung, um später das Commitment halten zu können.

Wir sehen also, auch die Artefakte ‚Story‘, ‚Crossfunktionalität‘, ‚Planning Poker‘ und ‚Review‘ leiten sich direkt aus den Paradigmen Commitment und Completion ab, nur durch Anwendung gesunden Menschenverstandes.

COMMUNICATION

Nun haben wir noch nicht über das dritte C gesprochen, dabei ist es der Schlüssel zu allem. Und gleichzeitig macht es auch die meisten Probleme weil es am schwierigsten zu fassen ist. Communication meint hier nicht, dass viel miteinander kommuniziert wird und dass Kommunikation über Dokumentation steht. Das stimmt zwar und passiert auch so, ist hier aber so nicht gemeint. Es geht vielmehr um die Art der Kommunikation, um die Perspektive und den Rhythmus. Und diese reflektiert und gleichzeitig definiert den Unterschied einer vertikalen, feature-orientierten zu einer horizontalen, layer-orientierten Entwicklung, wie in meinem oben erwähnten Beitrag beschrieben. SCRUM führt in die Kommunikation für viele Software-Experten einen Perspektivwechsel ein.

Im Zentrum der Kommunikation steht der Begriff ‚Business Value‘.

Und diese Perspektive zieht sich durch die gesamte Methodologie vom zentralen feature-orientierten Ansatz, der sich aus dem Paradigma Effektivität herleitet bis runter zur Beschreibung und Priorisierung von Stories, die sich aus der Beschreibung der ‚Motivation‘ herleiten. Wenn SCRUM gut eingeführt ist, verändert sich nach zwei bis drei Sprints die Kommunikation in genau diese Richtung. Wir möchten, dass alles was wir in SCRUM tun, aus dieser Perspektive betrachtet wird, wenn wir eine Story erstellen, wenn wir eine Architekturentscheidung treffen müssen, wenn wir Kompromisse bei der Umpriorisierung von Stories eingehen müssen, etc. Diese Perspektive ist in einer horizontalen, layer-orientierten Entwicklung praktisch unmöglich, hier wird dem Grundgedanken der Effizienz entlang viel technischer kommuniziert, es geht dabei mehr um technische Machbarkeiten und Risiken, etc. Sehr oft (nicht immer und auch nicht notwendiger Weise) tritt der Zweck dabei in den Hintergrund bzw. bleibt implizit.

SCRUM funktioniert nur, wenn alle Akteure bereit sind, sich auf diese Art der Kommunikation einzulassen und sie einzuüben.

Wenn Sie bemerken, dass Product Owner und SCRUM Team komplett aneinander vorbeireden, dann wissen Sie, dass dieser Perspektivwechsel schlicht noch nicht stattgefunden hat. Darüber hinaus brauchen Product Owner und Scrum Team eine gewisse Zeit, sich zu verstehen.

Die Stories müssen genauso beschrieben werden, dass Entwickler sie verstehen und unmittelbar mit der Implementierung beginnen können.

Stories spiegeln also den Stand der Teamkultur wieder, die sich über Kommunikation manifestiert. Extrem gut harmonisierende Teams brauchen in den Stories nicht viel Text, untrainierte Teams brauchen viel ausführlichere Beschreibungen. Das hat oft mit der Komplexität des Gegenstandes gar nichts zu tun, sondern spiegelt vielmehr den Stand der Kommunikation des Teams wider. Retrospektiven helfen, um kommunikative Schwachstellen aufzudecken und genau diese zu verbessern. Auch dieser Prozess dauert etwas und ist der Grund dafür, dass oft die ersten paar Sprints noch nicht so erfolgreich sind. Da darf der Projektleiter nicht die Nerven verlieren sondern muss auch mal geduldig bleiben.

Sie können nun die 4 C’s quasi als Leitfaden für die Implementierung der Methodologie in Ihrem Projekt oder bei der Lösung praktischer Probleme verwenden.

Denken Sie bei Ihren Entscheidungen nur daran welches der C’s betroffen ist und es wird Ihnen leichter fallen, die Auswirkungen abzuschätzen und bessere Entscheidungen zu treffen.

[…] und completion-fähig sind. Was es genau mit Commitment und Completion auf sich hat, können SieHIER in meinem Artikel über das Wesen von SCRUM nachlesen. Als Software Implementierungs Methode (SIM) […]

Leave a Reply

Your email address will not be published. Required fields are marked *