Scrum in der Verwaltung - Teil 2: Grundprinzipien von Scrum

Stadt-Gespräche — Folge 24

In den Stadt-Gesprächen reden wir, vom städtischen Start-up ShiftDigital, mit Mitarbeiter*innen aus der Verwaltung über Digitalisierung, E-Government und New Work. In dieser Folge sprechen wir mit Ralf Engels darüber, welche Vorteile die agile Methode Scrum bei komplexen Projekten bringt und wie sie funktioniert. Am Ende dieses Artikels findest du eine Zusammenfassung der Scrum-Prinzipien.

Nina da Costa: Gehen wir einfach mal zusammen durch, was Scrum ist und welche Prinzipien es verfolgt. Erstmal: Warum benutzt man diese Methode überhaupt?

Ralf Engels: Um es kurz und mit meinen Worten zu sagen: Scrum ist im Wesentlichen dazu da, komplexe Projekte handhabbar zu machen. Ein klassisches Projektschema wie das Wasserfall-Prinzip — ich mache erst Arbeitspaket Eins, dann Zwei, dann Drei — funktioniert nicht mehr. Das liegt daran, dass diese einzelnen Arbeitspakete nicht in sich geschlossen sind: sie hängen alle eng zusammen und es gibt permanente Feedback-Schleifen. Dafür ist eine solche Methode die richtige.

“Es muss mir immer bewusst sein, dass das Team Vorrang hat, denn es zählt nicht mein Ergebnis, sondern was das Team insgesamt rausbringt.”

Nina: Kommen wir zu den Grundprinzipien von Scrum. Fangen wir mal mit Selbstorganisation an: alle in dem Team, das an einem Produkt, einem Projekt, einer Dienstleistung arbeitet, tun dies sehr selbstständig. Aber es gilt nicht “Ich gucke auf mein eigenes Blatt, und links und rechts interessiert mich nicht”, sondern das heißt auch: selbstständig im Sinne der Zusammenarbeit.

Ralf: Was da ganz wichtig ist: das Teamergebnis zählt. Ich erledige nicht meine Aufgabe und mache dann ich nichts mehr, sondern — das ist das Selbstorganisierte — gucke, welche Aufgaben noch offen sind, oder wo ich andere Teammitglieder noch unterstützen kann, um dazu beizutragen, dass das Teamziel erreicht wird. Wenn ich nichts beizutragen habe, kann ich aufräumen, optimieren, mich über andere Punkte abstimmen, oder auch mit ganz anderen Dingen beschäftigen — gerade dann, wenn ich auch Aufgaben außerhalb des Teams habe. Es muss mir aber immer bewusst sein, dass das Team Vorrang hat, denn es zählt nicht mein Ergebnis, sondern nur, was das Team insgesamt rausbringt. Das heißt auch: wenn einer mal schwächelt, spielt das keine Rolle. Die Ergebnisverantwortung liegt immer beim Team, deshalb kann nachher keiner sagen: “Der eine war zwei Tage krank, deswegen konnten wir das nicht schaffen.” Das ist keine Argumentation.

Nina: Das ist auch ein Auffangnetz für alle.

Ralf: Es ist ein Auffangnetz, und gleichzeitig deutlich weniger transparent, als man vielleicht am Anfang denkt.

“Ich werde nicht von meinem Vorgesetzten kontrolliert, sondern von meinem Team — und ich kontrolliere genauso jeden im Team.”

Nina: Inwiefern?

Ralf: Ich greife vielleicht vor, aber im Prinzip muss jeder im Daily — also im täglichen Meeting — berichten, ob er seine Aufgabe vom vorigen Tag erledigt hat, was für eine Aufgabe er für den kommenden Tag hat und ob es irgendwelche Schwierigkeiten gibt. Das ist Transparenz, und da könnte sehr schnell die Befürchtung aufkommen: “Es wird kontrolliert, ob ich meine Arbeit mache”. Und das ist so, aber ich werde nicht von meinem Vorgesetzten kontrolliert, sondern von dem Team, mit dem ich zusammenarbeite. Und ich kontrolliere genauso jeden im Team.

Nina: Ein weiteres Prinzip: das Team ist interdisziplinär — das Grundprinzip von “Raus aus den Silos”. Könntest du das kurz erklären?

Ralf: “Bau dir dein Team so auf, dass es die Aufgabe lösen kann.” Das ist ein ganz wichtiger Punkt: wir müssen raus aus den Silos und auch raus aus den Stellenbeschreibungen und Verantwortlichkeiten. Bei Scrum sind alle, die an einer Aufgabe arbeiten, gleichgestellt. Der “Product Owner” (Produktverantwortliche, Anm. d. Red.) hat keinen höheren Rang als irgendjemand im Entwicklungsteam. In dem Projekt sind alle auf einer Ebene, egal, ob man Abteilungsleiter, Amtsleiterin oder Oberbürgermeister ist. Das spielt überhaupt keine Rolle — alle sind gleichberechtigt.

“Der Experte im jeweiligen Bereich hat die Entscheidungskompetenz.”

Nina: Wenn man 30 gleichberechtigte Leute mit 20 verschiedenen Jobs und Expertisen hat: wer trifft dann die Entscheidungen?

Ralf: Wir haben dazu unsere Workshops genutzt, in denen wir zusammengekommen sind, um all das auszudiskutieren und erst das Verständnis, und nachher auch das Einverständnis von allen einzuholen. Ansonsten gilt grundsätzlich: der Experte in dem jeweiligen Bereich hat die Entscheidungskompetenz. Wenn der Experte sagt: “an dieser Stelle machen wir das”, dann gilt das; es sei denn, es gibt begründete Argumente dagegen. Dafür holen wir uns ja ein interdisziplinäres Team zusammen. Ich benötige in einem Team auch nicht zwingend zwei Experten für das gleiche Thema. Vielleicht brauche ich sie auch, weil viele oder komplexe Entscheidungen getroffen werden müssen. Wir hatten teilweise Teams mit drei, vier Experten aus einem Bereich. Das war zum Teil sehr hilfreich und hat unglaublich beschleunigt, weil man einfach sagen konnte: “Hier ist eine Aufgabe, die müssen wir tausendmal wiederholen. Jeder hat 250 — legt los”. An anderer Stelle, wo es darum ging, eine Entscheidung zu treffen…

Nina: Vier Experten diskutieren.

Ralf: Genau: vier Experten, vier Meinungen. Dieses ganze Verfahren löst eben nicht alle Probleme der Komplexität von Projekten und dem zwischenmenschlichen Zusammensein.

Nina: Das ist, glaube ich, das große Problem mit agilen Methoden: sie werden als eierlegende Wollmilchsau verkauft: “Sobald ihr agil arbeitet, gibt es keine Probleme mehr”. Aber das stimmt natürlich nicht.

Ralf (lacht): Ganz sicher nicht.

“Wir haben das Teilergebnis angeschaut und gemeinsam darüber gesprochen: müssen wir die Richtung korrigieren oder ist sie in Ordnung?”

Nina: Gehen wir weiter mit den Scrum-Prinzipien: die Vorgehensweise ist inkrementell, das heißt, alles passiert in kleinen Schritten. Und sie ist iterativ, das heißt, es passiert in sich wiederholenden Etappen. Kannst du das noch etwas besser erklären?

Ralf: Gern. Die Schwierigkeit in komplexen Projekten liegt ja darin, dass ich zu Beginn des Projektes nicht weiß, wo ich am Ende lande — ich kenne nicht alle Zwischenergebnisse schon vorher, sonst könnte ich ja nach dem klassischen Modell arbeiten. Da lag bei uns der größte Vorteil: wir haben in verschiedenen Teams gearbeitet und die Informationen alle zwei Wochen zusammengeholt. Da kamen genau diese Inkremente — wir haben nach zwei Wochen kein fertiges Produkt geliefert, sondern ein Teilergebnis. Dann haben wir das angeschaut und gemeinsam darüber gesprochen: müssen wir die Richtung korrigieren oder ist sie in Ordnung? Das war auch die Iteration, weil es häufig hieß: “Lass uns doch das noch berücksichtigen, und das, und das”, und dann haben wir gesagt: “Das ist zu viel, wir machen erst das, und in der nächsten Runde schauen wir weiter.” So konnten wir überhaupt erst dieses Tempo aufnehmen.

“Da wollen wir eigentlich hin: dass wir beim nächsten Mal nur noch das Datum ändern müssen.”

Nina: Anders geht es bei sehr hoher Komplexität auch eigentlich nicht.

Ralf: Genau. Es gibt so viele Abhängigkeiten unterschiedlicher Dinge voneinander, dass wir das ohne Iteration nicht beherrschen könnten. Wir wüssten gar nicht, wie wir das sortieren sollten oder wann wir was machen. Ich war in einem Team, in dem wir eine Software entwickelt haben, mit der die anderen Teams die gesammelten Informationen visualisieren, bewerten und weiterverarbeiten können. Wir haben geografische Informationssysteme genutzt, um zu schauen: wo liegen die Baumaßnahmen, die wir durchführen müssen, welche müssen wir in welchem Jahr durchführen, welche ist wie teuer, und so weiter. Und all diese Informationen kamen iterativ und inkrementell. Und jetzt, in dieser Endphase werden alle Informationen, die in den Köpfen, auf Papier, in Quellcode und Datenbanken drin sind, zusammengeführt. Und diese Phase ist besonders kritisch.

Nina: Und besonders chaotisch.

Ralf: Da ist auch ganz wichtig, dass wir in zwei Wochen einen gewissen Stand fertig haben müssen, es aber ein fortlaufendes System ist. Das heißt, wir können das Ganze danach wieder aufdröseln, aufräumen, sauber machen und weiterbenutzen. Jedes Jahr wird das System fortgeschrieben und geschaut: was haben wir umgesetzt, was ist dazwischen gekommen, was haben wir zusätzlich geschafft? Das ist ein lebendes Dokument, eine lebendige Datenbank. Wenn wir das so, wie wir jetzt arbeiten, fortführen, müssen wir in sechs Jahren nur noch auf einen Knopf drücken. Da wollen wir eigentlich hin: dass wir beim nächsten Mal nur noch das Datum ändern müssen.

Zusammenfassung der Grundprinzipien von Scrum:

1. Selbstorganisation: Teammitglieder arbeiten eigenständig an den Aufgaben und miteinander — alle sind gleichberechtigt
2. Interdisziplinarität: Das Team besteht aus all den verschiedenen Expert*innen, die benötigt werden, um die Aufgabe zu erledigen
3. Das Teamergebnis zählt: die Erreichung des Teamziels hat immer Vorrang; die Verantwortung liegt beim Team, nicht bei Einzelnen
4. Transparenz: Arbeit und Arbeitsstände sind für alle Teammitglieder einsehbar
5. Iterationen: die Entwicklung erfolgt in kurzen, sich wiederholenden Phasen, nach denen jedes Mal neues Feedback eingeholt wird
6. Inkremente: die Entwicklung erfolgt schrittweise, nicht am Stück, um schneller auf Veränderungen reagieren zu können

Du willst dich weiter über Scrum informieren? Dann empfehlen wir dir den offiziellen Scrum-Guide zum Lesen oder zum Anhören.

Du interessierst dich für die Verwaltung der Zukunft?

Dann abonniere jetzt unseren kostenlosen Newsletter Shift Weekly und erhalte jede Woche spannende Links rund um E-Government, Digitalisierung und New Work!