Das ist doch kein Scrum

10. Klasse. Geschichtsunterricht. Wir durften eine Prüfung schreiben. An das Thema kann ich mich nicht mehr erinnern, aber ich weiß noch, dass unser Geschichtslehrer reproduziertes Wissen – und das gerne in vielen Worten – mochte. 12 Seiten gab ich nach 45 Minuten ab. 15 Punkte bekam ich dafür.

Warum ich diesen Beitrag mit dieser Anekdote beginne? Weil es das letzte Mal war, dass ich für das pure Wiedergeben von Informationen “belohnt” wurde. Heute kommt sie mir in den Sinn, wenn ich höre und lese, warum Scrum in Organisationen nicht funktioniert, wenn es nicht genutzt wird, wie es im Buch steht. “Das ist doch gar kein Scrum, was Ihr da macht!” Oder: “Das kann ja gar nicht funktionieren, wenn Du das Daily Scrum nicht täglich durchführst!” Oder: “Wirf doch einen Blick in den Scrum Guide, da steht doch alles Wichtige drin!” Na, dann werfen wir doch einfach mal einen Blick in den Scrum Guide.

Der Scrum Guide

Scrum ist ein Framework, das wesentliche Konzepte für das Management von Produktentwicklungen und Projekten beschreibt. Die Spielregeln von Scrum werden im Scrum Guide erläutert. Dieser wird immer mal wieder überarbeitet, zuletzt 2017.¹

Framework, wesentliche Konzepte, aktuelle Fassung – vermutlich haben Sie bis jetzt noch nichts Neues gelesen. Das ist auch wenig verwunderlich, schließlich ist es lediglich eine Wiedergabe von bekannten Informationen. Dennoch möchte ich kurz auf die drei Punkte eingehen:

• Scrum ist ein Framework. Darüber gibt es immer wieder Diskussionen. Ist es nicht doch eine Methode? “Nein, es ist keine Methode. Im Scrum Guide steht nirgends, wie man etwas macht.” Wenn aber “Methoden als planmäßiges Vorgehen zur Erreichung eines Ziels bzw. Weg zur Erlangung von Erkenntnissen verstanden werden, dann ist Scrum auch eine Methode. Und natürlich steht im Scrum Guide sehr wohl, wie Dinge zu tun sind.”²
• Der Scrum Guide beschreibt wesentliche Konzepte. Das entscheidende Wort heißt jedoch nicht Konzepte, sondern WESENTLICH. An sich ist es naheliegend, dass im Scrum Guide mit seinen 22 Seiten nicht alle Konzepte beschrieben werden, die im Zuge einer agilen Entwicklung sinnvoll sind oder unter Umständen sinnvoll sein können.  Zum Vergleich: als das V-Modell XT – ein Vorgehensmodell zur Entwicklung von Software und Systemen – vor mehr als 15 Jahren veröffentlicht wurde, hatte es einen Umfang von mehr als 600 Seiten. Natürlich lassen sich auf 600 Seiten mehr Inhalte thematisieren als auf 22 Seiten. Auf diesen Punkt gehe ich gleich im Detail ein. (Keine Sorge, ich werde Ihnen nicht empfehlen, 600 Seiten zu lesen, aber ein Appell folgt noch.)
• Warum gibt es Überarbeitungen des Scrum Guides? Ein Grund liegt sicherlich in der Klarstellung von Inhalten. “Der Scrum Master ist dafür verantwortlich, Scrum entsprechend des Scrum Guides zu fördern und zu unterstützen.” oder: “Scrum wird verwendet, um Software, Hardware, Embedded Software, Netzwerke von interagierenden Funktionen und autonome Fahrzeuge zu entwickeln.” sind solche Klarstellungen. Auch auf diese beiden Beispiele gehe ich noch ein.

Was nicht im Scrum Guide steht

Wie erwähnt werden im Scrum Guide wesentliche Konzepte beschrieben:

• das Scrum Team (bestehend aus Product Owner, Scrum Master und Entwicklern) mit definierten Verantwortlichkeiten,
• die Events (Sprint, Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospektive) und
• die Artefakte (Product Backlog, Sprint Backlog und Inkrement).

Schätzen Sie mal, wie häufig das Wort “agil” im Scrum Guide vorkommt? 0 Mal. Nicht ein einziges Mal wird “agil” verwendet. Der Begriff “Agilität” taucht genau einmal auf. Überraschend, oder? Es gibt eine Reihe von Konzepten und Begriffen, die viele Unternehmen im Zuge ihrer Entwicklungen mit Scrum tagein und tagaus verwenden, die aber nicht im Scrum Guide erwähnt werden. Hier eine kleine Auswahl:

• User Story
• Akzeptanzkriterien
• Story Points
• Definition of Ready
• Taskboard
• Velocity
• Standup Meeting
• Traceability
• Skalierung bzw. Scrum of Scrums

Die Liste lässt sich leicht fortsetzen: Prototypen, Minimum Viable Products, Pretotyping, Klickdummys – sehr viele Begriffe werden nicht verwendet. Doch was bedeutet diese Abwesenheit der Begriffe? Aus meiner Sicht: Nichts. Tatsächlich finde ich es clever, dass Ken Schwaber und Jeff Sutherland nicht versuchen, diese Begriffe zu verwenden oder sogar zu erläutern. Es ist schlicht nicht notwendig, denn Scrum ist vor allem ein Framework (oder eine Methode … 😉)

Niemand gibt Ihnen 15 Punkte …

Wenn die Abwesenheit von Begriffen nichts bedeutet, wie verhält es sich dann mit den Begriffen, die beschrieben werden? Aus meiner Sicht haben sie eine große Bedeutung, jedoch wird Ihnen niemand 15 Punkte geben, nur weil Sie Scrum nutzen, wie es im Scrum Guide beschrieben ist.

Natürlich ist es wichtig zu wissen, wie die Konzepte funktionieren und welche Empfehlungen ausgesprochen werden. Sicherlich würde auch ich vielen Organisationen raten, die Konzepte ernsthaft auszuprobieren und eigene Erfahrungen damit zu sammeln. Dazu brauchen diese

• Geduld und einen langen Atem,
• ein passendes Mindset (auch wenn dieses kein einziges Mal im Scrum Guide erwähnt wird) und
• vermutlich auch externe Unterstützung.

Für mich liegt der Fokus von Scrum aber nicht auf den Konzepten, sondern auf dem Framework an sich. Scrum ist nicht gleichbedeutend mit den Worten im Scrum Guide. Für mich entfaltet Scrum seinen Wert für Organisationen durch die  Überprüfung – sprich die Inspektion – und die Anpassung – die Adaptation – einer jeweiligen Vorgehensweise. Genau so wie es im Scrum Guide beschrieben ist.

An dieser Stelle möchte ich Ihnen die Beitragsserie von Heiko Bartlog Agilität? Haben wir probiert! Funktioniert nicht! empfehlen. Vielleicht arbeiten manche Bereiche in Ihrem Unternehmen bereits Subversiv agil, so wie es Oliver Buhr beschreibt, und von entsprechenden Erfahrungen können andere Bereiche profitieren? Viele nützliche Tipps finden Sie auch im Inspect & Adapt Blog von Daniel Dubbel.

Mein Appell

Ich hatte Ihnen noch einen Appell “versprochen” und ich wollte noch auf zwei Aussagen im Scrum Guide eingehen. “Der Scrum Master ist dafür verantwortlich, Scrum entsprechend des Scrum Guides zu fördern und zu unterstützen.“ und “Scrum wird verwendet, um Software, Hardware, Embedded Software, Netzwerke von interagierenden Funktionen und autonome Fahrzeuge zu entwickeln.“

Warum wurde der 2. Satz als Klarstellung in der aktuellen Fassung des Scrum Guides aufgenommen? Liegt es nicht auf der Hand, dass sich Scrum als Framework für die Entwicklung von Produkten, unabhängig von der Art der Produkte, eignen kann? Scrum ist ein Framework, ein Rahmen, nicht mehr und auch nicht weniger. Abgesehen von der werblichen Botschaft dieser Aussage, vermute ich, dass viele Menschen genau die Worte lesen, die im Scrum Guide stehen, aber nicht auf den Kontext achten. Ehrlich gesagt: solche Sätze irritieren mich. Nicht weil sie unklar und unvollständig, sondern weil sie so offensichtlich sind, dass sie eigentlich nicht benötigt werden.

“Der Scrum Master ist dafür verantwortlich, Scrum entsprechend des Scrum Guides zu fördern und zu unterstützen.” In anderen Worten: Es ist die Aufgabe des Scrum Masters, Scrum im Sinne des Scrum Guides umzusetzen. Nicht wortwörtlich, sondern im Sinne von Scrum und somit im Sinne von Inspektion und Adaption. Ich wünschte, der Satz würde lauten: “… im Sinne Ihrer Organisation”, aber ich möchte mich nicht an einzelnen Formulierungen aufhängen.

Und wie lautet mein Appell?

• Lesen Sie zwischen den Zeilen im Scrum Guide und achten Sie auf kleine Formulierungen wie bspw. “Spielregeln”.
• Lösen Sie sich von einzelnen Formulierungen und versuchen Sie, das gesamte Bild zu sehen.
• Nutzen Sie die Informationen als Rahmen, als Startpunkt oder als Leitidee. Behalten Sie aber immer Ihre konkrete Situation im Blick.
• Entwickeln Sie Ihr Vorgehen weiter: “Inspektion und Adaption” lautet die Zauberformel.
• Meiden Sie Diskussionen, ob es sich bei Scrum um ein Framework, eine Methode oder ein Vorgehensmodell handelt. Der Mehrwert solcher Diskussionen ist oft überschaubar.

Und machen Sie einen Bogen um Menschen, die Ihnen vorwerfen, dass Sie gar kein Scrum machen, oder Scrum bei Ihnen scheitert, nur weil Sie sich nicht an die Empfehlungen im Scrum Guide halten. Idealerweise arbeiten Sie so, wie es zu Ihnen und für Ihre Produktentwicklung passt.

 

PS: Erinnern Sie sich noch an meine Anekdote? Tatsächlich war ich nie in der Lage, 12 Seiten in 45 Minuten zu schreiben. Ich hatte die Aufgabe vorhergesehen, die Arbeit vorgeschrieben und eine Zeile für die Aufgabenstellung freigelassen, die ich über meine vorbereiteten Inhalte schreiben wollte. Als unser Geschichtslehrer die Prüfungsaufgabe präsentierte, war ich geschockt. Ich hatte keine Ahnung, worum es ging. Doch was sollte ich tun? Ich notierte die Aufgabenstellung über meinen “falschen” Inhalt und gab mein Werk nach 45 Minuten ab. Manchmal sind sogar 15 Punkte nichts wert!

 

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

[1] Im November 2020 kam eine neue Version des Scrum Guides auf den Markt.
[2] Die Aussage stammt von Kai-Marian Pukall, der einen großartigen Beitrag über Modern Agile Principles bei uns geschrieben hat.

Diesen Beitrag finden Sie auch im kostenlosen Blogpaper Scrum – Sieben Perspektiven zu Scrum.

Michael Schenkel hat im t2informatik Blog weitere Beiträge veröffentlicht, u. a.:

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.