Was haben folgende Aussagen gemeinsam?
„In Scrum wird nicht geplant!“
„Das Product Backlog ist das wichtigste Element des Scrum Rahmenwerks.“
„In Scrum fungiert der Scrum Master als der Projektmanager.“
Für mich sind sie ein Anzeichen, dass das Scrum Rahmenwerk noch nicht verstanden wurde.
Selbst auf Meet-ups oder Konferenzen, wo ich vermeintlich erfahrenen Agilisten begegnen sollte, höre ich leider häufig noch diese zweifelhaften Aussagen. In diesem Artikel will ich damit aufräumen.
„In Scrum wird nicht geplant!“
Regelmäßig höre ich Aussagen wie die Folgenden: „In Scrum wird nicht geplant!“, „Da in Scrum nicht geplant wird, ist Scrum nur etwas für kurze Projekte“ oder „Scrum Teams fehlt es an einer strategischen Ausrichtung, sie arbeiten nur ‚auf Sicht‘“.
Allerdings ist genau das Gegenteil die Wahrheit.
Jedes Event in Scrum dient der Planung:
Im Sprint Review plant das Scrum Team die strategische Ausrichtung der Arbeit. Als Grundlage dazu dienen das Inkrement und der Input der Stakeholder. Mit den neuen Erkenntnissen, die der Sprint gebracht hat, und dem Input der Stakeholder wird der Product Backlog angepasst. Der Product Backlog entspricht somit dem Plan, an welchen Problemen das Scrum Team in Zukunft arbeiten will.
Im Sprint Planning plant das Scrum Team die Arbeit für den aktuellen Sprint. Das Scrum Team überlegt gemeinsam, wie das Produkt im aktuellen Sprint seinen Wert und Nutzen steigern könnte, und definiert dabei ein lohnendes Ziel für den Sprint. Dieses Ziel dient den Entwicklern als Grundlage, welche Einträge des Product Backlogs sie für diesen Sprint auswählen sollen. Das Sprint-Ziel, die ausgewählten Einträge und ein vorläufiger Plan, welche Arbeiten nötig sind, um die Einträge abzuschließen, bildet den Plan für den Sprint.
Im Daily Scrum planen die Entwickler jeden Tag aufs Neue, an welchen Product-Backlog-Einträgen sie heute arbeiten wollen, um der Erreichung des Sprint-Ziels näher zu kommen.
In der Sprint Retrospektive plant das Scrum Team Wege zur Steigerung der Qualität des Produkts und zur Effektivität der Zusammenarbeit.
Die Spalte „Anpassung“ in der Übersicht zeigt noch einmal, dass jedes Event in Scrum der Planung zukünftiger Arbeit dient.
Zusammenfassend würde ich somit sagen, dass Scrum Teams ständig planen.
„Das Product Backlog ist das wichtigste Element des Scrum Rahmenwerks.“
Warum funktioniert Scrum?
Das Scrum Rahmenwerk ermöglicht es Scrum Teams, Entscheidungen auf Bekannten Informationen zu treffen. Das Scrum Team sammelt bei seiner Arbeit Erfahrungen über die Realität und diese dienen als Grundlage zur Entscheidungsfindung.
Diese Erfahrungen werden in den Scrum-Artefakten gesammelt. Die Artefakte in Scrum machen die Arbeit und die daraus entstehende Wertentwicklung beobachtbar. Damit das Scrum Team bestmöglich Entscheidungen treffen kann, müssen die Vergangenheit, die Gegenwart und die mögliche Zukunft so transparent wie möglich sein. Dies ermöglichen die drei Artefakte in Scrum:
Jedes Inkrement des Produkts macht die bis jetzt getane Arbeit des Scrum Teams transparent. Es repräsentiert somit die Vergangenheit.
Das Sprint Backlog des Teams macht die aktuelle Arbeit beobachtbar. Das Sprint Backlog repräsentiert somit die Gegenwart. Möchten wir sehen, woran das Scrum Team im Moment arbeitet, dann können wir dies am Sprint Backlog sehen.
Das Product Backlog repräsentiert die Zukunft. Es dient dem Scrum Team als einzige Quelle von Arbeiten, die zur Verbesserung des Produkts benötigt werden.
Aus meiner Sicht ist das Product Backlog das unwichtigste Artefakt in Scrum, wenn es darum geht, empirisches Arbeiten zu ermöglichen. Denn um erfolgreich Entscheidungen auf der Basis von Tatsachen zu treffen, muss in möglichst kurzen Abständen das Produkt transparent gemacht werden. Dies kann nur über die Auslieferung des Inkrements an die Nutzer geschehen.
Anders ausgedrückt: Nur Inkremente bieten die nötige Grundlage, um Erfahrungen über die Realität zu sammeln und somit wirklich empirisches Arbeiten zu ermöglichen.
„In Scrum fungiert der Scrum Master als der Projektmanager.“
Scrum benötigt keine Projektleiter!
Versteh mich jetzt nicht falsch, ich behaupte nicht, dass mit Scrum keine Projekte erfolgreich umgesetzt werden können. Aber eine Projekt-Denke, wie „Sprints sind kurze Projekte mit fest vorgegebenem Umfang, Abgabetermin und festem Budget“ führt bei komplexer Arbeit nicht zu den besten Resultaten.
Leider höre ich auch häufig diese Aussagen: „In unserem Projekt bin ich Projektleiter und Scrum Master in einem“ oder „Der Scrum Master übernimmt die Aufgaben eines Projektmanagers im Scrum Team.“ Das ist aus meiner Sicht ein Anzeichen dafür, dass das Scrum Rahmenwerk noch nicht richtig verstanden wurde.
Warum gibt es in Scrum keinen Projektmanager?
Scrum baut auf der kollektiven Intelligenz der Personen auf, die es anwenden. Die Zusammenarbeit von Fachleuten aus unterschiedlichen Bereichen ist bei komplexen Problemen unerlässlich. Eine Person, die dem Team detaillierte Anweisungen gibt, wie es arbeiten soll, ist hierfür hinderlich. Kreative und unkonventionelle Lösungen lassen sich nicht vorgeben, sondern entstehen erst, wenn die Fachleute frei von Hierarchien zusammenarbeiten. In Scrum ersetzen wir deshalb Hierarchien durch drei unterschiedliche Perspektiven, die bei der Entwicklung von Produkten mindestens einbezogen werden müssen:
Die Entwickler übernehmen die Verantwortung, dass bis zum Ende des Sprints eine neue und qualitativ hochwertige Version des Produkts zur Verfügung steht.
Der Product Owner übernimmt die Verantwortung, dass die Arbeit, welche die Entwickler erledigen, auch den meisten Wert stiftet.
Der Scrum Master übernimmt die Verantwortung dafür, dass das Team effektiv arbeitet. Er facilitiert den empirischen Prozess.
Wichtig: Nur weil es im Scrum Rahmenwerk keine Projektmanager gibt, bedeutet das nicht, dass Teams nicht managen. Im Gegenteil – jede der drei Verantwortlichkeiten in Scrum übernimmt Managementaufgaben:
Die Entwickler managen den Sprint Backlog.
Der Product Owner managt das Product Backlog.
Der Scrum Master managt die Elemente des Scrum Rahmenwerks.
Scrum ist ein minimales Rahmenwerk. Es besteht aus 3 Artefakten, 5 Events und 3 Verantwortlichkeiten. Zusammen sind diese 11 Elemente ausreichend, um in jeder Umgebung empirisch zu arbeiten. Weitere Elemente oder Rollen sind nicht erforderlich (und stehen wahrscheinlich der Lösung komplexer Probleme im Weg).