Die 4 C’s: Das Wesen von Scrum

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 Effizient: 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.

Inhalt dieses Artikels
  1. Wie funktioniert Scrum und warum?
  2. Die 4 C’s
  3. Commitment & Common Sense in Scrum
  4. Completion & Common Sense in Scrum
  5. Communication in Scrum

Wie aber funktioniert Scrum und warum?

Es genügt mir nicht – wie häufig in der einschlägigen Literatur geschehen – zu beschreiben, wie die Artefakte (Rollen, Sprints, Daily Scrum, 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 4 C’s

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 anderen 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 Grundwerte und zwei Techniken, mehr braucht es eigentlich nicht. Jesus brauchte immerhin schon mal zehn Gebote und unsere Verfassung hat deutlich über hundert Artikel, welche unsere Grundwerte repräsentieren.

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 Methodik mit allen Artefakten, Prozessen etc. Probieren Sie es doch gleich mal aus!

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.
Scrum Team trainieren
In 4 Schritten zum erfolgreichen Scrum Team
Wie Sie ihr Scrum Team dazu bringen Commitment- und Completion fähig zu werden und welche Rolle Scrum Master, Daily Standups und Plannings dabei spielen.

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 Refinement und Planning vorangestellt wird, um dieses Commitment zu kreieren.

Scrum Sprint Länge
Scrum Sprint: Warum 1 Woche effektiver ist
Warum ein 1-wöchiger Sprint viel effektiver ist und die Velocity Ihres Teams enorm steigern kann, erfahren Sie hier.

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 Arbeits- und Commitment-fähig zu halten.

Denn das Commitment wurde auf der Prämisse gegeben, 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 organisatorischen- oder administrativen Artefakte direkt vom Paradigma Commitment ableiten lassen.

Sollten Sie also irgendetwas an Ihrer Methodik 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.

Scope-Changes in der Mitte eines Sprints sind zweifellos der größte Feind des Commitments, denn sie bringen vor allem die im Planning aufwendig hergerichtete Balance des Sprints durcheinander.

Scrum Training

Agile in a Day

Wir trainieren Ihr Team, coachen Ihre Stakeholder und führen Ihr Projekt zum Erfolg!

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.

Der Zweck ist, das Team Arbeits- und Commitment-fähig zu halten.

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‘. So um die zweihundert. Und wir haben sie auch bestimmt alle schon mal gehört.

  • „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.

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

Dies setzt natürlich voraus, dass Acceptance Criteria ü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. Ein Commitment ist also immer ein Team-Commitment. Nur als solches macht es in Scrum wirklich Sinn.

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‘.

Interessanterweise haben die Autoren von SAFe diese Perspektive mit ihrem Wert #1 „Take an economical View“ noch einmal deutlich und aus gutem Grund unterstrichen.

Und diese Perspektive zieht sich durch die gesamte Methodik 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 Storys 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 Dev-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 Storys müssen genauso beschrieben werden, dass Entwickler sie verstehen und unmittelbar mit der Implementierung beginnen können.

Stories spiegeln also den Stand der Teamkultur wider, die sich über Kommunikation manifestiert.

Scrum Story
Die Story in Scrum und warum sich die Mühe lohnt
Eine schlecht aber vor allem unvollständig geschriebene Story ist eines der häufigsten Gründe für das Scheitern von SCRUM Projekten. Lesen Sie hier, wie eine gute Story aussehen muss.

Extrem gut harmonisierende Teams brauchen in den Storys 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 Methodik 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.

Leave a Comment

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.