Scrum – What’s new Pussycat?

Kaum einer hat es gemerkt, aber Scrum ist im vergangenen Jahr glatt 25 Jahre alt geworden. Und um so ein Jubiläum gebührend zu feiern, wurde dem Scrum Guide ein entsprechendes Update verpasst, nachdem die letzte Version aus dem Jahr 2017 stammt. Man merke also: Eine Sprintlänge bei Scrum beträgt 3 Jahre ?. Nun kann man (fast) überall nachlesen, welche Neuerungen es gibt – wer sie wirklich noch nicht kennt, kann sie sich schnell mal auf der Scrum.org-Webseite anschauen. Ich habe die Änderungen für mich sacken lassen und will zu den Unterschieden mal Stellung beziehen und sie aus meiner Sicht bewerten.

Product und Sprint Goal – I like

 Der neue Fokus auf Product und Sprint Goal ist aus meiner Sicht eine der besten Neuerungen bei Scrum. Hier wird endlich mal der Blick auf das aktive Management eines Softwareproduktes gerichtet. Höre ich die alten Produktmanager-Hasen hier sagen: „Mache ich schon seit 20 Jahren“? Exakt – aber während bislang das Softwareprodukt in der agilen Welt ausschließlich über die Priorisierung der Anforderungen gemanagt wurde, liegt nunmehr der Fokus auf einem strategischen Management der Software, wie man im Beratersprech sagen würde. Endlich wurden hier mal die klassischen Elemente eines Softwarelebenszyklus berücksichtigt, die sich über Jahrzehnte bewährt haben und absolut sinnvoll sind.

Jedes Softwareprodukt bekommt nun ein strategisches Ziel, welches es erfüllen soll. Das führt zum einen dazu, dass neue Anforderungen in Bezug auf dieses Ziel genauer bewertet werden können. Und zugleich macht es aber auch dem kompletten Scrum-Team transparent, was das lang- bis mittelfristige Ziel der Software sein soll. Etwas, was man in der täglichen Routine der Sprints schnell aus dem Auge verlieren kann. Damit gebe ich zugleich den Entwicklern einen Rahmen vor, wohin die Reise gehen soll und Fortschritte sind klarer zu identifizieren. Entsprechend bekommt nun auch jeder Sprint ein Ziel, welches auf das Product Goal einzahlt. Ich glaube, dass hiermit die Fragestellung „Was mache ich im nächsten Sprint?“ im Rahmen des Plannings viel transparenter wird.

Commitments – da lege ich mich fest, die sind gut

Commitments sind ebenso neu in Scrum. Sie sind Zusagen des gesamten Scrum-Teams auf das Product Goal, das Sprint Goal und die Definition of Done. Commitments kennt man aus dem klassischen Projektmanagement, dort werden diese aber anders verwendet. Im klassischen Projekt lässt man sich als Projektmanager beispielsweise von den auszuführenden Personen bestätigen, dass sie ihre Aufgaben im gegebenen Zeitraum und Aufwand umsetzen werden. Das wäre in der agilen Welt in dieser Form nicht anwendbar. Der Grundgedanke ist aber ähnlich, nur ohne den Kontrollgedanken.
Das komplette Scrum-Team verpflichtet sich, das Product Goal, die jeweiligen Sprint Goals sowie die Einhaltung der Definition of Done umzusetzen. Während solche Zusagen beim Product Goal eher die Transparenz fördern, das Ziel in Bezug auf das Softwareprodukt zu verstehen und einzuhalten, wird es beim Sprint Goal und der Definition of Done schon konkreter. Das Team legt sich fest, beide Artefakte verstanden zu haben und deren Inhalte zu berücksichtigen. Das betrifft insbesondere das Sprint Planning, bei dem sich das Team festlegt, das Sprint Goal mit den ausgewählten User Stories zu erreichen und die User Stories gemäß Definition of Done im Sprint fertig zu stellen. Das geschah bislang nur implizit oder auf Nachfrage. Als Scrum Master kennt man die schon gebetsmühlenartige Abfrage bei der Aufwandschätzung, ob die Anforderungen aus der Definition of Done für die jeweilige User Story berücksichtigt wurden. Dieser Part wurde nun formalisiert und wird als Commitment entsprechend dokumentiert.

Commitments schaffen aus meiner Sicht mehr Verbindlichkeit aber auch Transparenz, da durch die Formalisierung explizit auf die Artefakte Bezug genommen wird. Späteres Zurückrudern, im Sinne von: „Ach, ich wusste gar nicht, dass die Definition of Done als Anforderung umzusetzen ist“ gilt damit nicht mehr. Ebenso finde ich aber gut, dass die Commitments das komplette Scrum-Team betreffen, sodass weder Kontrollwahn oder eben auch Finger Pointing („Du hast aber gesagt, Du schaffst es, die Story im Sprint umzusetzen“) entstehen können.

Self-managing Scrum Team – Der Manager ist tot, lang lebe der Manager

Im neuen Scrum Guide ist der Begriff „self-organizing Teams“ durch „self-managing Teams“ ersetzt worden. Das klingt erstmal nicht spektakulär. Laut Wikipedia steht Organisation „auch für den Prozess des Organisierens, „durch den fortlaufende unabhängige Handlungen zu vernünftigen Folgen“ zusammengefügt werden, „sodass vernünftige Ergebnisse erzielt werden“ bzw. so zusammengefügt werden, dass sie zu gewünschten Zielen bzw. Ergebnissen führen.“ Und über Management ist dort zu lesen: „Management ([‘mænɪdʒmənt]; lateinisch manus, „Hand“ und lateinisch agere, „führen“, „an der Hand führen“), zu Deutsch Verwaltung, ist ein Anglizismus für jede zielgerichtete und nach ökonomischen Prinzipien ausgerichtete menschliche Handlungsweise der Leitung, Organisation und Planung in allen Lebensbereichen.“ Ich denke, aus diesen Definitionen wird der kleine, aber feine Unterschied klar: Zur eigentlichen Selbstorganisierung sind nun auch die Themen Leitung und Planung hinzugekommen.

Heißt das nun, dass Manager in der agilen Welt nicht mehr existieren? Natürlich nicht. Scrum definiert nicht die Organisations- und Managementstruktur von Unternehmen. Allerdings liegt der Fokus auf der Arbeitsweise des Scrum-Teams, die selbst entscheiden sollen, wie was wann am Produkt verändert wird. Heißt eben auch, dass das Scrum-Team Leitung, Organisation und Planung selbst erledigt und eben nicht nur die tägliche Organisation der Tätigkeiten.

Accountabilities – Scrum ist von der Rolle

Bislang war im Scrum immer von Rollen die Rede, also Scrum Master, Product Owner und Entwicklungsteam. Das führte leider in der Vergangenheit oft zu Verwirrung. So schufen Personalabteilungen neue Jobbeschreibungen, die es vielleicht in dieser Form gar nicht für das Unternehmen gab und die sich in der Organisationsstruktur auch nicht wiederfanden. Viele Mitarbeiter werden beispielsweise mal als Scrum Master und mal als Entwickler eingesetzt – müssten daher, formal gesehen, jeweils eine neue Jobbeschreibung bekommen, was schlicht nicht praktikabel ist. Daher wurde der Begriff ‚Rolle‘ durch den Begriff ‚Accountability‘, also Verantwortlichkeit, ersetzt, um klar zu stellen, wer welche Verantwortlichkeit in einem Scrum-Team hat. Wie das Ganze dann in einem Unternehmen in eine Jobbeschreibung mündet, ist nicht das Thema von Scrum, daher begrüße ich diese Begriffsschärfung, da sie klarer macht, wer was im Rahmen von Scrum zu machen hat. Der Begriff ‚Rolle‘ war hier schon historisch zu sehr vorbelastet und führte mehr zur Verwirrung als zu Transparenz.
In der neuen Ausprägung gibt es nun drei Accountabilities:

• Scrum Master
• Product Owner
• Entwickler

Das Entwicklungsteam wurde entsprechend durch die Accountability eines Entwicklers ersetzt, worüber ich nicht glücklich bin. Der Begriff wird aus meiner Sicht zu sehr mit einem Software-Entwickler gleichgesetzt, was ja an der Realität vorbei geht. Ich benötige ebenso Spezialisten aller Couleur, welche das entsprechende Inkrement implementieren. Selbst neben „Full-Stack-Entwicklern“, welche in der Realität rar gesät sind, benötige ich immer noch Tester, Administratoren etc.

Ja ist denn schon Weihnachten? – Meine Wunschliste für Scrum

Insgesamt finde ich die Änderungen sehr gut, sie sind ein Schritt in die richtige Richtung. Und auch wenn Weihnachten gerade vorbei ist, ich hätte da noch ein paar Punkte für meine Wunschliste an Scrum:

1. Mehr Fokus auf das strategische Management eines Softwareproduktes legen! Klassische Produktmanager machen seit Jahren vor, wie man Softwareprodukte erfolgreich managt. Hier wünsche ich mir von Scrum mehr Input. Man muss das Rad ja nicht neu erfinden, es würde ja auch reichen, auf bestehende Standards zu verweisen. Aber wir reden hier von dem Brot-und-Butter-Geschäft eines Product Owners, den Scrum hier leider ziemlich im Regen stehen lässt. Etwas mehr zu Themen wir Produkt Vision, Produktstrategie, Produkt Roadmap würde sehr hilfreich sein, die Accountabilities von Product Ownern besser zu verstehen und sie im Sinne einer guten Softwareentwicklung einzusetzen.
2. Self-managing Teams sind in fast jedem agilen Projekt die Sollbruchstelle. Ich kann nicht einerseits fordern, dass Scrum Teams sich selbst verwalten, aber das Thema agile Führung dabei vernachlässigen. Hier wünsche ich mir dringend von Scrum, mehr Fokus auf die Scrum Teams und das Führen von Scrum Teams im agilen Kontext zu legen. Ansonsten sehe ich schwarz, Scrum in großen hierarchischen Unternehmen einzuführen.
3. Entwickler statt Entwicklungsteam ist zwar im Sinne der Accountabilities korrekt, aber der Begriff ist sehr schlecht gewählt. Ich würde mir für den nächsten Scrum Guide wünschen, diesen Terminus durch einen neutraleren zu ersetzen – wie wäre es zum Beispiel mit Implementierer?

#agil #scrum #rollen #newscrumguide #scrum #whatsnew #productgoal #produktmanagement #sprintgoal #commitments #entwickler #accountabilities

Andreas Milanese