Die 4 C's: Das Wesen von Scrum - Agile Transformation & Training für Startups und KMUs – scagile.work Blog (2024)

Das Wesen von Scrum

• Klaus Riedel
• März 29, 2024

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.

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.

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.

Kurzgesagt:

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!

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

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.

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.

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.

Scrum Master
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.

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.

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.

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.

Interessanterweise haben die Autoren vonSAFediese Perspektive mit ihremWert #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.

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.

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.

Die App für skalierte agile Teams ist endlich da!

Klicke hier, um Artikel mir demselben Tags zu sehen:

• Agile Coaching, Agile Mindset, Scrum Master

Weitere interessante artikel für dich:

• Tools
• Methoden
• Best-Practices