Was Selbstmanagement wirklich bedeutet, zeigt sich in der Antwort auf diese Frage:
„Wie kannst du 100 Entwickler am besten in Scrum Teams organisieren und sicherstellen, dass sie die richtigen Product-Backlog-Einträge auswählen?“
Diese Frage stammt von Ken Schwaber. Sie ist ein zentraler Bestandteil des „Professional Scrum Master“-Trainings und eine Prüfungsfrage im PSM-1.
Laut Ken gibt es nur eine richtige Antwort:
„Lass die Entwickler sich selbst in Scrum Teams organisieren.“
Ich finde, es gibt keine bessere Frage, die zeigt, was Selbstmanagement in Scrum wirklich bedeutet. Selbstmanagement kann nur in der Abwesenheit eines vorgegebenen Prozesses entstehen, und der Scrum Guide verzichtet absichtlich darauf, viele Dinge vorzuschreiben. Dadurch ermöglicht Scrum erst wahres Selbstmanagement.
In meiner Arbeit mit Scrum Teams und Scrum Mastern stoße ich immer wieder auf Missverständnisse, die Selbstmanagement sabotieren. Es werden Regeln mit Scrum in Verbindung gebracht, die es so nie in Scrum gab.
Hier die fünf häufigsten Missverständnisse:
Missverständnis 1: Der Scrum Master weist Arbeit im Sprint Planning zu
Ich treffe oft auf dieses Missverständnis:
- Der Product Owner legt vor dem Sprint Planning fest, welche Einträge im Sprint Backlog für die Entwickler vorgesehen sind.
- Der Scrum Master weist den Entwicklern im Sprint Planning die Arbeit direkt zu.
- Es gibt keinen Sprint Backlog und jedem Entwickler wird ein Eintrag aus dem Product Backlog zugewiesen.
Wenn wir den Scrum Guide zur Hand nehmen, sehen wir sofort, dass es sich hierbei um ein Missverständnis handelt. Er besagt:
„Im Dialog mit dem Product Owner wählen die Entwickler Einträge aus dem Product Backlog aus, die in den aktuellen Sprint aufgenommen werden sollen.“
Wie wir lesen können, kommt der Scrum Master darin gar nicht vor. Die Auswahl, welche Einträge in den Sprint Backlog übernommen werden, treffen die Entwickler. Dies geschieht in einem Dialog mit dem Product Owner.
Findet dieser Dialog nicht statt, wird das Selbstmanagement des Scrum Teams untergraben.
Missverständnis 2: Der Fortschritt wird an der Velocity des Teams festgemacht
Wie viele Einträge ein Scrum Team in den letzten Sprints erledigt hat, ist nur für das Scrum Team selbst von Bedeutung.
Diese „Velocity“ sollte ausschließlich den Entwicklern des Scrum Teams dienen, ihr Sprint Planning effizient zu gestalten. Sie gibt Auskunft darüber, wie viele Einträge des Product Backlogs die Entwickler in Absprache mit dem Product Owner in ihren Sprint Backlog übernehmen sollten. Der Scrum Guide warnt davor, den Fortschritt des Scrum Teams bei der Arbeit am Produkt ausschließlich mithilfe solcher Metriken zu messen:
„Es gibt verschiedene Vorgehensweisen, um den Fortschritt vorherzusagen, wie Burn-down-Charts, Burn-up-Charts oder Cumulative-Flow-Diagramme. Obwohl diese sich als nützlich erwiesen haben, ersetzen sie nicht die Bedeutung der Empirie.“
Wir sollten nie vergessen, dass der Fortschritt in der Entwicklung von Produkten niemals linear verläuft. Zwei Features im Produkt bedeuten nicht, dass das Produkt jetzt doppelt so wertvoll ist. Der Erfolg eines Scrum Teams wird nicht durch die Menge an abgeschlossenen Einträgen des Product Backlogs bestimmt. Vielmehr entscheidet die Zufriedenheit der Kunden über den Erfolg eines Scrum Teams.
Missverständnis 3: Das Daily Scrum ist ein Statusbericht
Ob ein Scrum Master die Selbstorganisation von 100 Entwicklern in mehreren Scrum Teams wirklich zulässt, zeigt sich häufig schon im Daily Scrum.
Nicht selten erlebe ich, wie das Daily Scrum einem Statusbericht der Entwickler an den Scrum Master gleicht. Die Entwickler werden einzeln befragt. Sie sollen erklären, woran sie am Vortag gearbeitet haben. Ihre Antworten nimmt der Scrum Master mit einem kurzen Nicken zur Kenntnis. Diese „Scrum Master“ missverstehen ihre Rolle im Scrum Rahmenwerk. Sie verwechseln sie mit der eines Managers oder Projektleiters. Der Scrum Guide ist hier jedoch sehr eindeutig:
„Das Daily Scrum ist ein 15-minütiges Event für die Entwickler des Scrum Teams.“
Weiterhin beschreibt er auch die Rolle des Scrum Masters im Daily Scrum:
„Die Entwickler können Struktur und Techniken beliebig wählen, solange ihr Daily Scrum sich auf den Fortschritt in Richtung des Sprint-Ziels konzentriert und einen umsetzbaren Plan für den nächsten Arbeitstag erstellt. Das schafft Fokus und fördert Selbstmanagement.“
Wie wir lesen können, hat der Scrum Master keine aktive Aufgabe im Daily Scrum, solange sich das Daily Scrum auf den Fortschritt in Richtung des Sprint-Ziels konzentriert.
Missverständnis 4: Technische Aufgaben im Product Backlog
In Scrum herrschen keine Hierarchien, aber es gibt eine Aufgabenteilung.
Es existieren zwei Verantwortungsbereiche: Der Product Owner verwaltet den Product Backlog. Die Liste der für die Produktverbesserung notwendigen Dinge. Er ist für das „Was“ verantwortlich. Die Entwickler hingegen verwalten den Sprint Backlog, sie definieren das „Wie“. Der Scrum Guide formuliert es so:
„Das Sprint Backlog besteht aus dem Sprint-Ziel (Wofür), den für den Sprint ausgewählten Product-Backlog-Einträgen (Was) sowie einem umsetzbaren Plan für die Lieferung des Increments (Wie).“
Die Entwickler sind somit für das „Wie“ verantwortlich. Im Scrum Team herrscht also eine klare Aufgabenteilung: Die Entwickler definieren das „Wie“ im Sprint Backlog und der Product Owner das „Was“ im Product Backlog, ohne dass es hierarchische Unterschiede gibt.
Sobald jedoch Einträge im Product Backlog existieren, die mal das „Was“ und mal das „Wie“ beschreiben, entsteht eine implizite Hierarchie. Muss der Product Owner die Einträge im Product Backlog ordnen, entscheidet er damit über die Wichtigkeit von „Was“ und „Wie“.
Ein Beispiel:
- „Was“-Eintrag: „Ein Benutzer kann sich im System mit seiner E-Mail und seinem Passwort anmelden.“
- „Wie“-Eintrag: „Unittests müssen geschrieben werden.“
Genau diese Entscheidung, wie die Entwickler vorgehen sollen, sollte ein Product Owner nie treffen müssen, um die Autonomie der Entwickler nicht zu untergraben.
Missverständnis 5: Neben Product Owner, Scrum Master und Entwicklern gibt es noch weitere Rollen
Nicht wenige Unternehmen versuchen Komplexität zu beherrschen, indem sie weitere Elemente hinzufügen.
Beispiele hierfür sind Rollen wie „Release Train Engineer“, „Delivery Manager“ oder „Chief Product Owner“. Dies ist ein Missverständnis, da sich Komplexität nicht durch die Schaffung weiterer Rollen, Regeln oder Prozesse beherrschen lässt. Die Einfachheit ist der Schlüssel zum Erfolg, denn nur die Reduktion auf das Wesentliche ermöglicht es uns, schnell auf veränderte Bedingungen zu reagieren. Weniger Rollen, Regeln und Prozesse bedeuten weniger Anpassungsbedarf, was eine schnelle Reaktion ermöglicht.
Aus diesem Grund beschreibt der Scrum Guide nur das absolut Notwendige für die Produktentwicklung in komplexen Situationen:
„Der Kern von Scrum besteht aus einem kleinen Team von Personen, dem Scrum Team. Das Scrum Team setzt sich zusammen aus einem Scrum Master, einem Product Owner und Entwicklern.“
Und nicht mehr.
Die Antwort auf Komplexität ist Subtraktion, nicht Addition.
Nur durch Subtraktion entstehen Freiräume für Selbstorganisation. Alles andere ist ein Missverständnis des Scrum Guides.