Seit November gibt es eine neue Version des Scrum Guides und seit dieser Woche auch die offizielle deutsche Übersetzung. Aber was bringen die Veränderungen? Und wie sind sie eigentlich gemeint? Im heutigen Chat-Blog unterhalten sich zwei unserer Certified Scrum Trainer über ihre Sicht auf die Änderungen.

Jens: Hallo Sabine, Ihr habt gestern schon mal kräftig Champagner getrunken! Was war der Anlass?

Sabine: Ooh, merkt man mir das noch an? Na, so wild war es nicht, bei mir ein Gläschen Rotwein, bei anderen nur Tee oder Wasser. Anlass war die erfolgreiche Übersetzung des Scrum Guides 2020. Daran haben wir mit einem kleinen Team gearbeitet und uns besonders gern Sonntag nachmittags dazu getroffen.

Jens: Der neue Scrum Guide hat ja drei Jahre auf sich warten lassen. Ich habe so meine eigenen Gedanken zu den Veränderungen, aber mich interessiert erstmal Deine Meinung: Champagner, oder doch eher Leitungswassser?

Sabine: Ob der neue Guide die Welt erheblich verbessern wird, wird sich zeigen. Unterm Strich halte ich die Version 2020 für eine Verbesserung. Es gibt ein paar Neuerungen, die aus meiner Sicht in die richtige Richtung gehen. Ganz oben auf meinem persönlichen Wunschzettel stand die Produkt-Vision. Diese Wunschliste existiert übrigens wirklich, jeder kann dort was eintragen. Die Vision gibt es zwar jetzt nicht, dafür aber immerhin ein Produkt-Ziel.

Was bringt das Produkt-Ziel?

Jens: Gerade beim Produkt-Ziel bin ich mir gar nicht so sicher! Der PO war ja bisher eher so die Schnittstelle in die “böse” Business-Welt. Jetzt hat Scrum damit gebrochen und angefangen, sich auch nach “vorne” in der Wertschöpfungskette zu orientieren. Geht dadurch nicht eher ein wenig Gestaltungsspielraum verloren? Und wenn ja, was gewinnt man dadurch?

Sabine: Man gewinnt Alignment. Es entsteht der Blick auf das “Große Ganze”, der dem gesamten Scrum Team hilft, gemeinsam dafür Verantwortung zu übernehmen. Und zu erkennen, welchen Beitrag jede:r einzelne Developer:in dazu leistet. Die Einführung der Accountabilities anstelle der Rollen ist eine weitere Änderung, die in diese Richtung geht: Kein Development Team mehr, das Aufträge vom PO ausführt, sondern gemeinsame Accountability (Ergebnisverantwortung) des Scrum Teams, jeden Sprint ein wertvolles Increment zu erzeugen.

Jens: Da bin ich absolut bei Dir: Die Gesamtverantwortung des Teams halte ich auch für eine Kernidee bei Scrum, und wenn die Einführung der Accountabilities dazu beiträgt, finde ich das toll. Aber lass uns noch ein wenig bei dem Produkt-Ziel bleiben. Mein Problem ist: Ich habe viele Produkt-Visionen gesehen und viele Storymaps, Business Model Canvasses und ähnliches, die die Aufgabe erfüllen sollen, einen Business-Kontext herzustellen. Aber wer oder was ist ein Produkt-Ziel?

Sabine: Ein Produkt-Ziel ist ein Business-Ziel, SMART. Im Gegensatz zu einer Produkt-Vision, die eher un-SMART und fuzzy sein kann. 

Jens: Oder sein sollte. 😉 Ist ein Produkt-Ziel dann so etwas wie ein Objective plus Key Result?

Sabine: Ja, so könnte man das übersetzen. Ich habe das Fehlen eines übergeordneten Ziels immer als Manko gesehen. Es sah so aus, als ob das Product Backlog aus dem Nichts entsteht. Diese Lücke haben wir ja dann in unseren PO-Trainings mit unterschiedlichen Tools gefüllt, wie du ja schon geschrieben hast. Jetzt ist dieses übergeordnete Ziel auch im Guide verankert. So ergibt auch das Sprint-Ziel mehr Sinn, als Schritt in Richtung des Produkt-Ziel. 

Die Rückkehr der Commitments

Jens: Das führt uns zu meinem persönlichen Highlight: Der Einführung von Commitments, die jeweils Artefakten zugeordnet sind. Also dem Product Backlog das Produkt-Ziel, dem Sprint Backlog das Sprint-Ziel und dem Increment die Definition of Done. Das finde ich einfach sehr elegant!

Sabine: Ja, das ist eine schöne Struktur, die man sich leicht merken kann. Das Commitment war ja früher (vor 2017) schon mal drin als Teil des Sprint Plannings. Es ist rausgeflogen bzw. durch “Forecast” ersetzt worden. Viele (ich nicht) haben das bedauert, weil dadurch Verbindlichkeit verloren gegangen sei. Die können sich jetzt besonders freuen.

Jens: Da gehöre ich eher Deiner Fraktion an: Ich kann mich erinnern, schon Mitte der Nullerjahre mit Simon Roberts über das Commitment auf die Sprint-Planung gestritten zu haben – und dabei von ihm gelernt zu haben, dass es ja schon damals um das Sprint-Ziel ging, nicht um die ausgewählten Items. Ich halte aber Mangel an Verbindlichkeit für kein praktisch relevantes Problem – nach meiner Erfahrung wollen gute Teams liefern.

Für mich ist der zentrale Gewinn die zusätzliche Bedeutung, die drei Commitments nun bekommen. Nach meiner Erfahrung sind Sprint-Ziel und Definition of Done die Stiefkinder in den meisten Teams.

Nicht mehr nur Software

Sabine: Das bringt mich zu der grundsätzlichen Frage, welche Auswirkungen Änderungen im Scrum Guide auf die Praxis haben. Die Definition of Done war schon immer da, trotzdem wurde sie in der Praxis oft nicht streng eingehalten. 

Zur praktischen Anwendung habe ich den Eindruck, dass der neue Guide noch weniger konkrete Anleitung gibt, als es beim letzten der Fall war. Hinweise, wie etwas umzusetzen ist, sind kaum noch vorhanden. Die Interpretation erfordert aus meiner Sicht einiges an Erfahrung.

Jens: Hm, ein wichtiger Punkt! Der Erfolg von Scrum beruhte meines Erachtens auf seiner relativen Einfachheit und der praktischen Umsetzbarkeit, gerade im Vergleich zu Extreme Programming (da musste man schon eine Menge können, um mitspielen zu dürfen). Also nicht dass XP nicht praktisch umsetzbar gewesen wäre, aber eben nur mit technischem Können. Wenn Scrum sich jetzt Richtung “eleganter akademischer Methodik” bewegt, könnte das schwierig werden. Aber sind dafür nicht auch wir Trainer:innen da?

Sabine: Zum einen sollte durch den neuen Guide Scrum noch unabhängiger von Software-Entwicklung werden. Schon in der 2017-Version war nicht von Software die Rede. Dass man ohne solide technische Kenntnisse wie XP mit Scrum gute Software entwickeln könne, war und ist ein gefährlicher Irrglaube. Das schlanke Framework verführt zu diesem Irrglauben. Ich lasse in meinen Trainings die Teilnehmer:innen brainstormen, was zu Scrum gehört, was nicht, und was sie zusätzlich noch können und wissen sollten, damit am Schluss was Wertvolles herauskommt. Und ja, genau darauf hinzuweisen, welche Lücken es gibt und wie man die agil füllt, ist eine der Aufgaben von uns als Trainer:innen bzw. Coaches.

Jens: Die Öffnung Richtung Hardware (back to the roots…) und auch Organisationsentwicklung ist offensichtlich und auch für mich ein echter Gewinn. Wir machen ja zum Teil schon spezifische Scrum-Master und Product-Owner-Kurse für Hardwareentwicklung.

Noch ein anderes Thema, wo ich Bauchweh habe: Es gibt keine Selbstorganisation mehr (schnüff!). Stattdessen wird nur noch von Selbst-Management gesprochen. Warum das denn?

Abschied von der Selbstorganisation?

Sabine: Die offizielle Begründung ist, dass Selbstorganisation bedeutet: das Scrum Team entscheidet das Wer und das Wie. Bei Selbstmanagement entscheidet es das Wer, Wie und auch das Was. Selbstmanagement ist also mehr Entscheidungsfreiheit im Scrum Team. Ich persönlich finde Selbstmanagement klarer, vielleicht auch weil er nicht so inflationär gebraucht wird wie Selbstorganisation. Den Begriff trifft man an unterschiedlichsten Stellen, in biologischen, sozialen und anderen Systemen, und immer ist die Bedeutung etwas unterschiedlich.

Jens: Da kommen wir jetzt in eine Grundsatzdiskussion rein. Ich sehe gerade den Reiz von Selbstorganisation darin, dass es ein universelles Prinzip unserer Welt ist, das überall Anwendung finden kann. Aber Du hast natürlich recht, dass es gerade im agilen Bereich sehr inflationär – ich möchte fast sagen – missbraucht wird. Es wird mit Autonomie, Demokratie, Anarchie oder Managementfeindlichkeit verwechselt. Da haben wir offensichtlich die letzten zwanzig Jahre keine gute Arbeit geleistet, das zu erklären.

Sabine: Selbstorganisation findet als Default-Verhalten halt immer statt, wenn niemand sie verbietet oder einschränkt. Ist es wirklich das, was Organisationen wollen? Wir sprechen in unseren Leadership-Trainings ja ausführlich darüber, dass Selbstorganisation Führung benötigt, um Fokus zu setzen und Alignment zu gewährleisten. 

Jens: Und deshalb bin ich sehr glücklich: Endlich ist der “Servant Leader” gestorben! Juhu!

Sabine: Ja, es ist für mich ein weiteres Highlight, dass der:die Scrum Master:in jetzt ein:e echter Leader:in mit Accountability für die Effektivität des Scrum Teams ist und nicht “nur” ein Servant Leader! Damit wird die Rolle aufgewertet, und das wird auch Zeit.Viele Organisationen zweifeln an, dass ein:e Scrum Master:in überhaupt notwendig ist. Die Frage für mich ist, wie wir die Notwendigkeit noch klarer machen können.

Jens: Ein wenig Sorge habe ich ja, dass jetzt die “Scrum Faschisten” übernehmen, aber vielleicht hilft es ja auch, dass Scrum Master:innen mehr wertgeschätzt werden. Ich habe mit dem Servant Leader immer Probleme gehabt, weil ich ihn außerhalb der Scrum-Welt nicht gefunden habe und mir damit der Anknüpfungspunkt zu modernen Führungsansätzen gefehlt hat.

Der Punkt mit den Doppelpunkten

Eine letzte Frage: Warum hast Du mir beim Schreiben eigentlich immer Doppelpunkte:innen eingefügt?

Sabine: Jaaa, das ist das wirklich revolutionär Neue zumindest in der deutschen Übersetzung. Sie ist jetzt gegendert. Wir hatten im Übersetzungsteam eine Gender-Beauftragte und stehen geschlossen hinter diesem Ansatz. Am Anfang erschien es uns noch etwas aufgesetzt, aber mittlerweile haben wir uns komplett daran gewöhnt, und es ist mir, wie du merkst, bereits in Fleisch und Blut übergegangen. Ich hoffe, dass das für meine Kolleg:innen bald auch zur Selbstverständlichkeit wird :-). 

Jens: Also gefühlt habe ich in meinen öffentlichen Trainings mittlerweile fast so viele Frauen, wie Männer. Auch da tut sich was.

Sabine: Dann besteht ja die Hoffnung, dass wir bald endlich eine weitere weibliche Certified Scrum Trainerin im deutschsprachigen Raum bekommen. (Ceterum Censeo…)