Wer mit Scrum arbeitet, kennt ihn in der Regel: Der Scrum Guide von Scrum.org ist die kurze Beschreibung der Regeln zu Scrum. Regelmäßig alle paar Jahre arbeiten Jeff Sutherland und Ken Schwaber, zwei der “Väter” des Scrum, die Erfahrungen aus der praktischen Umsetzung und das Feedback aus der Community in einen neuen Scrum Guide ein. Seit Juni diesen Jahres ist nun eine neue, aktualisierte Version verfügbar.
Wie in jeder Version gibt es Ergänzungen, aber auch Änderungen am bestehenden Vorgehen. Die wichtigsten haben wir uns genauer angeschaut.
Es gibt eine komplett neuen Bereich, der sich ausschließlich mit der Transparenz von Artefakten beschäftigt, und deren Wichtigkeit betont. Konkret: Product Backlog und Sprint Backlog, vor allem aber auch die Definition of Done sollten für alle Beteiligten offen und verstehbar sein. Damit werden klare und zügige Entscheidungen ermöglicht, Risiko gemindern und die Wertschöpfung erhöht.
Während wohl in den meisten Fällen das Team selbst, der Product Owner und Scrum Master einen guten Einblick in die Artefakte haben, scheint das gegenüber der Stakeholder stark abzunehmen. Diese ausdrückliche Forderung der Transparenz kann somit helfen, das gegenseitige Verständnis und die Einbettung des Entwicklungsteams in das gesamte Gefüge zu fördern.
Das Sprint Planning besteht nicht mehr aus zwei getrennten Teilen (Planning 1 und 2), sondern wird zu einem Meeting zusammen gefasst, das jedoch zwei Phasen umfasst: Erstens die Prognose, was innerhalb des kommenden Sprints fertig gestellt werden kann, die mit der Formulierung des Sprint-Ziels endet. Zweitens die Erstellung eines Plans, wie das avisierte Ziel unter den gegebenen Umständen erreicht werden kann, d.h. welche konkreten Aufgaben dafür zu erledigen sind,
Betont wird dabei erneut die Rolle des Sprint-Ziels, das vom Entwicklungsteam selbst, basierend auf dem Selected Backlog des Product Owners, formuliert wird. Selbst, wenn das Sprintziel lautet “Macht einen Haufen Kleinzeugs”, sollte dieses Sprint-Ziel im eigenen Interesse des Teams im Fokus stehen.
Gab es bisher das Backlog Grooming, also die Pflege des Backlogs, ist jetzt vom Refinement die Rede, also der Verfeinerung. Die Idee dahinter ist, dass Stories in ihrer Beschreibung immer feingranularer ausgearbeitet, werden, bis sie detailgenug sind, um so umgesetzt zu werden. Dieser Zusatnd der Stories wird dann als “ready” bezeichnet.
Dies spielt unseres Erachtens klar zusammen mit der Zusammenführung von Planning 1 und 2, da die Analyse der Anforderungen syetematisch nach vorne verlagert wird. In wiefern diese Neuformulierung eine tatsächliche Änderung im agilen Alltag, oder viel mehr eine neue Beschreibung der gelebten Praxis ist, kann nur jedes Team selbst beurteulen.
Waren bisher “Zeitfenster” für alle Ereignisse formuliert, gelten jetzt klare zeitliche Obergrenzen für alle Ereignisse. Während die angegeben Zeiten von Meetings und anderen Ereignissen Maximalwerte darstellen, also beendet werden können, sobald sie ihren Zweck erfüllt haben, gilt die Länge des Sprint selbst als fest und darf nicht gekürzt oder verlängert werden.
In der Praxis dürfte dies keinen nennenswerten Unterschied machen. Die Neuformulierung betont aber die Notwendigkeit der zeitlichen Begrenzung und damit die Einhaltung der gesetzten Timeboxes.
Um im Daily noch stärker als bisher zu fokussieren und an Stelle von Statusreports ein Planungsmeeting zu gestalten, wurden die Formulierung der drei Fragen ( - Was hat man gestern erreicht? Was will man heute erreichen? Was behindert einen? - ) erweitert und auf das Sprintziel bezogen: “Was habe ich gestern erreicht, das dem Entwicklungsteam hilft, das Sprint-Ziel zu erreichen?” oder auch “Sehe ich irgendwelche Hindernisse [Impediments], die mich oder das Entwicklungsteam vom Erreichen des Ziels abhalten?”
Mit dieser Formulierung soll stärker auf das gemeinsame Ziel wie auch das Team fokussiert werden, und die Verbindung zum Planning wie auch zur Transparenz innerhalb und außerhalb des Teams gestärkt werden.
Als Teilnehmer des Review werden nun, neben Team, Scrum Master und Product Owner, explizit auch die wichtigsten Stakeholder genannt. Zudem steht im Mittelpunkt des Reviews nicht mehr allein die Demonstration des geschaffenen Produktwertes, sondern auch die Prüfung, ob neue Markt- oder Produktentwicklungen eine Umpriorisierung des Backlogs erfordern und ob Zeitplan, Budget und Produkteigenschaften des kommenden Sprints den übergeordneten Erwartungen entsprechen.
Dieser stärkere Einbezug der Stakeholder, wie auch die Aufforderung zum regelmäßigen Abgleich mit Markt und Produkt stärkt, zusammen mit dem gestärkten Sprint-Ziel, klar die strategische Ausrichtung, die sich so bis in die Arbeit der Teams hinein widerspiegelt.
Und insgesamt? Neben oder gerade mit seinen vielen kleinen Änderungen betont der Scrum Guide unserem Eindruck nach die Integration des Scrum Teams in die Organisation und deren Ziele. Die Stärkung von Sprint-Zielen und strategischer Ausrichtung bereits im Review wie auch die Transparenz der Artefakte schlagen eine klare und deutlich sichtbare Brücke zwischen Teamzielen und Unternehmenszielen und damit die Aufforderung zur Annäherung zwischen Team und Management. Weil agil, und das ist keine ganz neue Erkenntnis, eben immer alle betrifft.
Hier gibts den Scrum Guide zum Download,
Video von Schwaber und Sutherland zum Scrum Guide.
Rufen Sie uns an: 030 – 555 74 70 0
