Dann isses halt kein Scrum

Ist es schlimm, wenn man von Scrum abweicht oder sind die sogenannten ScrumButs sogar Notwendigkeit? Das möchte ich im heutigen Artikel mal etwas näher beleuchten.

Wir setzen auf Scrum, aber …

Die Einen hören diesen Satzanfang, schnauben verächtlich und denken sich „Wieder jemand, der Scrum nicht verstanden hat und nur die Rosinen rauspickt“, während Andere wiederum die genau entgegen gesetzte These vertreten und so etwas sagen wie: Hey, am Ende des Tages geht es doch um das Ergebnis und wenn wir dafür alles an Scrum verändern müssen, dann ist es halt so.

Manche sagen sogar, dass die sogenannten ScrumButs das Beste an Scrum sind.

Wer hat Recht?

Ich tendiere sehr stark zur Position, dass auch an Scrum alles verändert werden darf und sollte, wenn es nützt.

Schließlich geht es ja tatsächlich mehr um das Ergebnis als um das Folgen eines Plans und vor allem mehr um Individuen und Interaktionen als um Prozesse und Werkzeuge. Unter diesem Gesichtspunkt kann Scrum gar nicht der heilige Gral sein, der um keinen Preis verändert werden darf. Doch gibt es natürlich einen Knackpunkt, der hin und wieder übersehen wird obwohl es eigentlich so naheliegend und wichtig ist:

Vor allem geht es darum, was überhaupt funktioniert.

Es geht nicht um das, was für die Scrum-Erfinder Ken Schwaber und Jeff Sutherland oder die Dozenten bei der ScrumMaster-Schulung funktioniert. Sondern darum was für unser Team, unsere Leute, unseren speziellen Kontext und unsere Aufgabe funktioniert.

Scrum darf verändert werden, wenn das Ergebnis funktioniert.

Ganz sicher ist es aber nicht verkehrt, wenn wir zunächst mal einen Blick darauf werfen, was für Andere funktioniert.

Im Scrum-Guide heißt es dass die Rollen, Events und Artifakte unveränderlich seien und dass man zwar auch nur Teile der Methode umsetzen könne, das Resultat dann eben kein Scrum mehr sei. Manche wollen in dieser Aussage in der Schlussnotiz im Scrum Guide Fanatismus erkennen (und diese Leute haben Scrum wahrscheinlich tatsächlich nicht verstanden), aber eigentlich gibt es für diese Aussage einen einfachen Grund: genau so ist es.

Jedes Event, jedes Artifikat und jede Rolle in Scrum erfüllt einen Zweck in dem Vorgehensmodell, wie es sich die Scrum-Erfinder ausgedacht haben. Immer geht es um ein empirisches Vorgehen, bei dem man im Unklaren startet und auf dem Weg nach und nach neue Erkenntnisse gewinnt, mit denen man am Team, am Prozess und auf ein möglichst gutes Ergebnis hinarbeiten kann.

Dabei helfen die vielen, oft gescholtenen Meetings genau wie die verschiedenen Rollen:

  • ein Product Owner, der sich auf die Kunden und deren Anforderungen fokussiert und fokussieren kann und so auch dem Team hilft, indem er sie mit den nötigen Informationen versorgen kann

  • ein Team von Entwicklern/Machern, die sich auf ein möglichst gutes Ergebnis fokussieren statt über Anforderungen und Prioritäten orakeln zu müssen

  • ein ScrumMaster, der die Interaktionen zwischen den Beteiligten beobachten und das gesamte Team darin unterstützen kann, besser zusammenzuarbeiten

Die Sprints schaffen Rhythmus und begrenzen das Risiko, während die Meetings zu den nötigen Erkenntnissen verhelfen, indem sie wie Checkpoints zwischen die Sprints eingestreut werden und überhaupt erst die Chance eröffnen, von Dingen zu erfahren, die einen Kurswechsel rechtfertigen oder sogar nötig machen.

Die Idee von Lernen auf allen Ebenen findet sich darin wieder genau wie der Gedanke, dass man nicht auf zufällige Gelegenheiten warten muss, wenn man sie selbst schafft.

Wenn’s funktioniert, wen interessiert es dann, ob es Scrum ist oder nicht?

Nehmen wir an, ein Team ist erfolgreich: das Team glücklich, der oder die Kunden sind glücklich und der Ertrag stimmt auch.

Vielleicht gibt es in dem Team keinen dedizierten ScrumMaster, weil verschiedene Personen im Team diese Rolle hin und wieder wahrnehmen und vielleicht funktioniert das, weil das Team schon so lange zusammenarbeitet. Oder aber es gibt gerade niemanden, der die Aufgabe wahrnehmen kann, und es funktioniert trotzdem.

Vielleicht sind im Team nicht alle Skills vorhanden, wie es in einem optimalen cross-funktionalen Team sein sollte, und man greift für bestimmte Aufgaben doch auf andere Fachabteilungen zurück.

Vielleicht macht man auch kein Daily, weil die Mitglieder des Teams über den Globus und unterschiedliche Zeitzonen verstreut sind und es deshalb einfach nicht praktikabel ist.

Dann isses halt kein Scrum.

Wahrscheinlich gibt es noch andere Punkte, in denen man von Scrum abweicht und logische Erklärungen für jeden einzelnen Punkt – und das ist auch okay so.

Der springende Punkt ist nicht, ob ich Scrum nach Lehrbuch praktiziere: die Annahme, dass sich ein universelles und damit für jedes Team passendes Vorgehen im Voraus festlegen lässt, ergibt einfach keinen Sinn. Schließlich geht es bei (vorgefertigten) Prozessen ja gewissermaßen um eine Gebrauchsanleitung für Situationen: so oder so sollte ich mich verhalten, um ein bestimmtes Ergebnis zu erzielen. Nur kenne ich die Situation noch gar nicht (sie hat ja noch nicht stattgefunden) und sie entzieht sich auch der Vorhersagbarkeit: zu komplex ist die Welt, in der wir leben und arbeiten.

Wir können das richtige Vorgehen nur aus der Situation heraus entwickeln, weil komplexe Situationen eben emergente Praktiken erfordern.

Wenn wir dann bei einem iterativen Vorgehen wie Scrum festellen, dass einzelne Praktiken von Scrum nicht oder andere Praktiken eben besser funktionieren, dann hat Scrum seinen Zweck erfüllt. Entscheidend ist dabei, dass wir uns bewusst für oder gegen bestimmte Praktiken entscheiden, weil die Werkzeuge und Prozesse ja nun mal uns unterstützen sollen und nicht umgekehrt.

Finden wir dabei gemeinsam ein Vorgehen, das für uns eine Zeit lang funktioniert: dann ist schon viel gewonnen.

Wenn wir uns also dann auch noch regelmäßig davon vergewissern, dass unser Vorgehen auch mit anderen Leuten, geänderten Marktbedingungen oder bei einer Anpassung unserer Prioritäten funktioniert und ansonsten unser Vorgehen anpassen, dann können wir über eine Aussage wie der im Scrum-Guide nur mit den Schultern zucken. Wenn wir wissen, dass unsere Zusammenarbeit funktioniert und wir auftretende Probleme zügig aus dem Weg räumen – was sollte es uns kümmern, was im Scrum-Guide steht?

Ausprobieren und Entdecken

Das sollten wir eben nur sicherstellen, indem wir ausprobieren und entdecken, was für uns wirklich funktioniert.

Wenn wir dann noch neugierig bleiben, regelmäßig reflektieren und uns mit dem Gedanken vertraut machen, dass wir früher oder später unser Vorgehen anpassen müssen, weil Veränderung eben unausweichlich und deshalb noch lange nichts Schlechtes ist: dann sind wir auf dem richtigen Weg.

Dann isses halt kein Scrum, kann uns aber auch egal sein.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.