Was Fahrradfahren mit Scrum zu tun hat

„Stopp! Bevor wir hier in die Umsetzung gehen, müssen wir den Plan nochmal überdenken. Die Details stimmen noch nicht.“

Kennen Sie das? Vielen Scrum-Teams fällt es anfangs schwer, vom Erstellen detaillierter Pläne abzulassen, die dann ständig neu überarbeitet werden müssen. Der Versuch, vorab möglichst viel festzulegen, behindert Teams in der Umsetzung, stört ihre Selbstorganisation und verlangsamt die Lieferung. Woran liegt das und was kann ich als ScrumMaster dagegen tun?

Um diesem Phänomen entgegenzuwirken, greife ich gerne auf eine Analogie zurück, die ich aus der Soziokratischen KreisorganisationsMethode (SKM) kenne: die Fahrradtour.

Scrum ist wie Fahrradfahren

Stellen Sie sich vor, Sie planen eine Fahrradtour mit Freund:innen oder Ihrer Familie. Nicht alle sitzen gleich sicher im Sattel oder starten am selben Ausgangspunkt, aber: Sie alle möchten sich zu einer bestimmten Zeit an einem verabredeten Ort treffen. Wie gehen Sie nun vor?

Selbstverständlich nennen Sie allen Beteiligten das Ziel und die gewünschte Ankunftszeit. Möglicherweise geben Sie vor, dass ausschließlich ausgeschilderte Fahrradwege genutzt werden dürfen, um die Sicherheit aller Teilnehmer:innen zu gewährleisten, oder führen eine Helmpflicht ein. Abgesehen davon lassen Sie alle selbst die Route wählen, denn sie sind immerhin die Expert:innen für ihren jeweiligen Weg. So lassen Sie genug Spielraum für den Umgang mit möglichen Änderungen wie der Witterung und eventuellen Problemchen auf dem Weg (wie bspw. einem Platten). Natürlich ist Ihnen auch klar: Dass alle zum selben Zeitpunkt abfahren und ankommen werden, ist utopisch, aber basierend auf ihren bisherigen Erfahrungen können die einzelnen Gruppen wahrscheinlich ungefähr abschätzen, wie viel Zeit sie einplanen müssen, um pünktlich anzukommen.

Sicher ist …

Es wäre unsinnig, für alle die perfekte Route aufgrund der aktuellen Bedingungen zu berechnen oder gar basierend darauf ihre Lenker entsprechend zu fixieren. Spätestens nach ein paar Metern würden alle unweigerlich auf die Nase fallen, wenn sie nicht selbst lenken könnten. Möglicherweise hätten Sie ein Gefühl von Kontrolle und Sicherheit. Aber stellen Sie sich vor, alle anderen würden blind fahren und Sie würden nur die vorgefertigten Routenanweisungen per Telefon durchgeben, weil Sie nicht vor Ort sein können. Spätestens jetzt sehen Sie, dass von der Kontrollillusion große Gefahr ausgeht.

Wieso ist das so?

Während des Fahrens bekomme ich permanent Rückmeldung, ob ich fester treten muss, ob die Neigung stimmt, wie sich das Rad auf dem Untergrund verhält und kann (selbstverständlich ohne zuerst Rücksprache mit Ihnen als Organisator:in zu halten) entsprechend Anpassungen vornehmen. Zudem kann ich sofort auf kleinere Überraschungen reagieren, bspw. ein auf dem Fahrradweg parkendes Auto umfahren oder während eines Schauers kurz eine Regenjacke anlegen. Größere Abweichungen, wie bspw. eine Straßensperrung oder eine längere Pause, führen zu kurzen Abstimmungen, damit am Ende trotzdem alle zu einer ähnlichen Uhrzeit ankommen.

Übertragen auf ein Scrum-Team

Der Product Owner legt mit der eigenen Vision das Ziel fest. Möglicherweise gibt es Rahmenbedingungen (bspw. Budget, zu verwendende Technologien, rechtliche Vorgaben), die in der Umsetzung vorgegeben sind. Ähnlich wie die nächsten Routenanweisungen auf dem Fahrrad soll auch dem Scrum-Team klar sein, was als nächstes passieren soll. Dafür drückt jede User Story deutlich aus, was das Etappenziel ist. Durch den Sprintzyklus stellen die Teammitglieder sicher, dass sie schnell und regelmäßig Rückmeldung zu ihrer (Fahr- bzw.) Arbeitsweise bekommen und bei Bedarf den Plan anpassen können. Das heißt, sie schaffen Sicherheit in einem unsicheren Prozess, ohne sich durch zu viele Detailvorgaben selbst im Weg zu stehen.

Weiter entfernte Navigationsanweisungen dürfen ruhig etwas vager sein (z. B. nach Wien halten wir uns gen Süden), da die Teammitglieder sich ohnehin nicht jede Abzweigung merken können oder die Route sich nochmal ändert. Analog werden auch Epics, die sich noch in weiterer Zukunft befinden, nur grob beschrieben – wird am Ende etwas anderes priorisiert, wurde keine unnötige Arbeit in die Detaillierung gesteckt.

Abgesehen davon braucht das Team aber ausreichend Spielraum, um auf kleine und größere Änderungen zu reagieren. Wie störend zu viele Vorgaben sein können, ist im Arbeitskontext zwar nicht so offensichtlich wie auf der Fahrradtour, der Effekt ist aber ähnlich: Ein falsch parkendes Auto nicht ohne Rücksprache umfahren zu können, blockiert die Weiterfahrt ebenso, wie ein Annahmefehler in einem Entwicklungsplan ein Softwareentwicklungsteam blockiert, wenn es nicht vom ursprünglichen Plan abweichen darf, obwohl es sinnvoll wäre.

Der Lernzyklus aus der SKM

Die Fahrradanalogie habe ich, wie eingangs erwähnt, aus der Soziokratischen KreisorganisationsMethode (SKM) entlehnt. In der SKM wird der Deming-Cycle, auf dem auch der Scrum-Zyklus basiert, festgehalten als „dynamischer Kreisprozess aus Leiten-Tun-Messen“:

• Im „Leiten“ werden Rahmenbedingungen festgelegt, ein Plan erstellt und Messergebnisse bewertet,
• im „Tun“ wird dieser Plan ausgeführt
• und im „Messen“ wird zurückgemeldet, inwiefern dieser Plan tatsächlich umgesetzt werden konnte und welche Ergebnisse dabei herauskamen.

Probieren Sie gerne aus, mithilfe der Fahrradanalogie agiles Arbeiten in Ihre Teams zu transportieren. Ich bin gespannt auf Ihre Erfahrungen.

Titelbild: Coen van de Broek, Unsplash